ARIN XXIV Public Policy Meeting Draft Transcript - 22 October 2009 [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. If everyone would come in and settle down. Welcome back, everyone. Hopefully you had a wonderful time exploring Dearborn last night. I’m John Curran, President and CEO of ARIN. I’d like to get today’s festivities kicked off. I’d like to say welcome back to our remote participants. We have some announcements. The most important announcement, the NRO Number Council selection was completed. Our winner, Louie Lee. Louie. Thank you.

Okay. Daily survey. We have a survey. Everyone should complete today’s survey. It will enter you into a prize drawing for tomorrow’s announcements. Since people entered yesterday, we’re going to do a drawing for the prize. I’m looking for the drawing. Here it comes. Prize today is a $120 carbon offset gift certificate, about one year’s offset for home energy use. I’m going to talk a little bit about carbon offsets tomorrow as well. ARIN has a fairly significant initiative talking about our green initiatives. So here comes our survey. Okay. And it’s by random number. Okay. I am going to ask someone to come up and they’re going to point at this piece of paper. So looking for a fairly innocent party. Owen. Come on up, Owen. Look at that – look at the innocence on his face. I have no problem having you come up because you’re not on the list. Come on up.

Unidentified Speaker: Can we make him think of something he’s innocent of first?

(Laughter.)

John Curran: Stand here. Close your eyes. Put your finger forward and point. Keep stepping forward a little more. Stop. Thank you. David Williamson, Tellme Networks.

(Applause.)

You will get your carbon offset gift certificate mailed to you. Thank you. Okay. Tonight, night at the museum. Join us for Henry Ford Museum. Tonight 6:30 to 10:30 for the ARIN social. Fun food and lots of cool stuff. It’s quite a place. We’ll be loading in the lobby at 6:15 and buses will come back – Scott?

Scott Bradner: It says food, fun and lots of cool stuff. Food, booze, fun and lots of stuff.

John Curran: I do believe there’s food, fun, booze and lots of cool stuff. Let me confirm. Yes.

Stacy Hughes: Will there be dancing?

John Curran: Will there be dancing? Yes, there will be dancing.

Stacy Hughes: Thank you.

John Curran: And we’ll have shuttle services back starting at 8:30 p.m. Transportation to and from are provided by our sponsor UnitedLayer. I’d like a round of applause for them. Okay. Again, get social. If you see something you like in the meeting and you want to keep people informed back home, you can follow us, post something on Twitter yourself or follow us on Twitter. Facebook, as well. And also YouTube. If someone surreptitiously posting videos via YouTube – I guess that’s fine. If I’m out there, I’m a fair target. We have videos up there. I don’t expect you folks to be posting any, but you might find the ones we have up interesting. Sponsors. Network connectivity provided by Arbor Networks and Merit Network. Thank you.

(Applause.)

And we have media partners, who have helped us to get the word out to the meeting, PowerSource Online and Telecom Finders. Thank you.

(Applause.)

As always, the rules of the meeting. I will moderate the discussion of Draft Policies so that everyone can have a chance to be heard. I want to you state your name and affiliation when you approach the mic. When you approach the mic, if you’re in favor or opposed to a policy, please make that clear if we’re discussing a Draft Policy. There’s a full set of rules in your program. Today’s agenda. We have a number of reports. We have the IPv6 IAB/IETF Activities Report. We have several RIR Updates. We have the NRO NC Report. We have the NRO Activities Report, the Policy Experience Report, and then the AC On-Docket Proposals Report. These are interspersed within the Draft Policy discussions, which we also have. And on today’s agenda we have a special presentation on WHOIS RESTful Web Service.

The policy discussions we have today, 2009-5, IPv6 for Multiple Discrete Networks; Global Policy on Allocation of IPv4 Blocks to Regional Internet Registries; and 2009-8, Equitable IPv4 Run-Out. All of these are in your program in the policy discussion booklet.

At the head table I have the Board of Trustees. I also have – well, I guess Bill, and who else do I have back there? Sorry, David. Yes. Marc. Just trying to see who else we have. Bill, David, Marc, Scott – Scott. Got ’em all. Sorry. And let’s get started. First item up is the IPv6 IAB/IETF Activities Report. That’s going to be given by Marla.

IPv6 IAB/IETF Activities Report

Marla Azinger: I’m Marla Azinger. I work for Frontier Communications and I am on the Advisory Council. I also can’t talk very well. The smoke, I’m really allergic to it and it’s pretty much attacked my whole body now. So I’m a little slow, so please excuse me. This presentation is not an official IETF report. There’s no official IETF liaison to ARIN or any RIR. It is, however, believed to be accurate. But if there’s any mistakes, they’re solely mine. And the presentation is not a detailed review of documents mentioned. I think it needs new batteries.

Routing area, active. This document draft describes a mechanism that provides fast reroute in an IP network through encapsulation to not-via addresses. And there is one IESG is processed in one document. I’m sorry, guys. I’m really not talking well.

IPv6 maintenance working group. They have five active documents, all of which are written with not just solutions but examples of where things can go wrong. That’s not a norm, but it’s really kind of nice to see in documentation.

One is new and fills a gap by specifying the IANA guidelines for allocating new values for the routing type field – Hey, you guys need to stop IMing me right now, please. – in the IPv6 router head. One document is in IESG processing.

V6 ops. There are five active documents. IPv6 CPE router recommendations is interesting because it’s a needed attempt to encourage vendors to get our end-users on implement that is IPv6 capable and a call for implementers to expedite availability of IPv6 CPE router products in the marketplace.

There’s IPv6 Rogue. IPv6 advertiser problem statement focuses on the unintended cause of rogue RAs. IPv6 RA-guard focuses on a suggested solution for that. IPv6 deployment in IX points provides a guide that includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks. It’s just kind of a what-they-suggest document that hasn’t existed.

There’s also a laundry list of related documents, but I only included one in the slide, the emerging service provider scenarios for IPv6 deployment drafts, because I thought some folks might be interested in reading this once it describes scenarios that are emerging among Internet service providers for deployment of IPv6. They are based on practical experiences so far, as well as current plans and requirements, but they are not intended as binding recommendations. And there are eight expired documents including NAT64. SHIM 6. There’s a little action in SHIM 6 right now, and there’s only one active document. Thank you. Behave.

There are seven active documents, two of which may be of interest to those looking into making IPv6 actually happen on their networks or their companies. There’s IPv6 addressing of IPv4/IPv6 translators. It’s interesting if you want to know about algorithmic translation. And this doc covers how IPv6 to IPv4 happens using only statically configured information.

DNS64 is a mechanism for synthesizing quad A records. This document specifies DNS64 and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. NAT64 is a mechanism for translating the IPv6 packets to IPv4 packets, and vice versa. This document specifies NAT64 and gives suggestions on how they should be deployed. IESG is processing two of behaves documents right now.

SIDR. Currently there are around 12 active documents looking at various technical aspects that need to be addressed in order to create a good plan for proper route authority.

There have been suggestions that RIRs handle it and IANA be the end authority. However, some feel that if that happens the ITU will end up taking over, and there are clearly many “what-if” scenarios flying around and conspiracy theories flying around the halls on that topic.

Path validation was also discussed and the suggestion to start adding it into the RPSEC documents under development right now. It was also acknowledged that if this were to be done, then the charter of that group would need to be changed to include path validation, and that’s despite being unitopic in another working group.

And there was an unofficial TA policy proposal to condone the ISP level to not follow allocation hierarchy. This brought forward a heated debate and more theorizing that this would open the door for ITU takeover and countries to become TA. Nothing official as of yet has been done with this unofficial proposal that was mentioned.

Softwire. Not much new in active documents, but they managed to get four more documents published as RFCs. DNSOPs. Not much new here on accepted active documents, however there was a proposal to introduce documentation on meshing with DNS returns based on internal network issues. This proposal started a very heated debate and large discussion on ethics and the Internet when entities decide to change DNS returns for monetary reasons and how changing DNS returns in general violates the policy of DNSSEC.

DNS extensions. They are saved as nine active documents and one new RFC has been published. OPSEC. There’s one active document that some may find interesting. It provides a security assessment based on the results of a project carried out by the UK Center for the Protection of National Infrastructure. And there is one new published RFC in that group.

GROW. GROW is getting busy again and has nine active documents. Several of these documents are on their original version still. So input is needed. And if that is an area of interest to you, it would be a good time to start participating on the GROW group.

LISP. This new working group had its first meeting in Stockholm. They actually had more than one. They now have five active documents. If you’re interested in participating in creation of an alternate architecture, this is a good place to start participating.

The next IETF is in Hiroshima, November 8th through the 13th. And here’s the IETF BoF wiki has information on it and then there’s official BoF links you can go to. And then the next slide. This is just a list of references that any of you can go to to find more information on documents and working groups. And that’s it. Any questions?

(Applause.)

Thank you for putting up with my slow speech.

John Curran: Thank you, Marla. Okay. Next up is Paul Wilson giving the APNIC Update.

RIR Update - APNIC

Paul Wilson: Thanks. Thanks, John. Like Marla, I’m not speaking too well at the moment either, having brought a head cold with me from the other side of the Pacific. But I don’t think it’s H1N1. That would be a nice thing to bring you at the start of your flu season, wouldn’t it. I’m not too close to the mic, don’t worry. Okay. This is an update of things from APNIC, the regional Internet registry for the Asia-Pacific. And I need to find a way of – left to right. Okay. Services, policies, priorities and next meetings. I’ve probably got – I’ve probably got 15 minutes’ worth here, but, John, give me a bell if I start to go over. This is a chart of the major resource delegation activities at APNIC just showing how our trends are going, firstly in IPv4 allocations in total /8s. The 2009 figure, of course, is up to the end of the third quarter. So if you imagine that bar extended by another 33 percent, you’d see that I think the trend is not of an ongoing upward acceleration here. I think we’re seeing some slowdown.

Likewise, ASNs, which in my experience I think tend to reflect more accurately economic climate issues, are also looking like they’re down. IPv6 delegations are probably still on the climb, which is a good thing to see. I’ll mention that that IPv6 chart is individual delegations rather than /32s. The point there being that there’s such a difference between what we’ve seen in smaller and larger IPv6 allocations that the figures are a little strange if you start looking at individual /32s or addresses.

Our service levels, we’ve just recently exceeded 2,000 members. It’s a relatively small number of members given the extent of our – and intensity of our activities. But it reflects the fact that we’ve got a few national Internet registries in the APNIC region which account for at least another thousand additional ISPs that are receiving resources from us. I’ll mention for those who are interested in national registries. We don’t make allocations to national registries. National registries act as agents which approve allocations, subject to our review if necessary. And address space allocations come from the APNIC pool in exactly the same way as allocations come from other RIR pools. We are accelerating in terms of membership growth. Thanks, Jason. So July 2009 – in fact, the last few months have been our largest months for membership growth, which is an interesting thing, again, given the economic climate. We’ve had a big increase in help desk inquiries. We’re doing 1400-plus per month these days, which is 50 percent higher than last year.

The number of allocations is growing quite slowly and, as I said before, it looks like we’re just probably just going to exceed or about equal last year’s allocations. So up by about 5 percent in terms of the number allocations per month a year ago. Am I pointing to the right place? Okay. Under policies. We had at the last APNIC meeting, which was the 28th APNIC open policy meeting held in Beijing – we had four policies that reached consensus. Under our process, they are still subject to a final call, but that’s closing soon.

The first of those was a repeat of the IPv4 address transfers policy, which has been under discussion and proposal for quite some time in the APNIC region. It was approved by consensus. The important factor there being that in this iteration of the policy, the receipt of any transfers is subject to approval by APNIC according to current policies.

The next one is what was called the simplification of the allocation of IPv6 to members with existing IPv4 addresses. And that’s simply to recognize the fact that infrastructure needs have already been demonstrated through IPv4 allocations and IPv6 allocations can be made accordingly more easily.

Proposal 74 is the one that we’ve seen, the global policy on IANA’s allocation of ISN blocks. And 75 was the – for the recovery of AS numbers which are unused. AS numbers allocated by APNIC, which are unused in the region. And that reflects a policy that we’ve had under active implementation for some time for the recovery of unused IPv4 addresses.

We had no consensus on three policies in the last meeting. One was a supplementary policy on related transfer historical addresses. We actually allow historical addresses to be transferred without justification at this time. That policy has been in place for quite a few years now. The proposal here was to impose policy-based justification requirements on the historical addresses allocated in the APNIC region, and that region gave consensus at the meeting.

The next was a policy to reserve a /10 out of APNIC’s last /8 specifically for IPv4 to IPv6 transition. We have already a policy regarding that last /8; that that address space would be allocated in minimum allocations, size blocks, at a maximum of one allocation per existing APNIC member or per new APNIC member into the future. This policy, I think, wasn’t badly opposed. I think it wasn’t defeated. It’s gone back to the list for further modification.

And as I mentioned in the meeting yesterday, we’ve had a policy, which also reached no consensus, requiring further aggregation or increasing the aggregation requirements on IPv6 address blocks so that you would be required to aggregate into a single announcement all IPv6 address space received from APNIC. And that’s not currently a requirement of our policy. And that was not approved.

Okay. Moving on to our organization priorities. APNIC has a process every two years of conducting an – independently conducting a member and stakeholder survey throughout our region. We use that to assess where the resources of the organization, as in the financial resources, should be allocated to different activities and priorities. And from that survey we derived – that survey was last completed at the beginning of this year. We have 10 resource allocation priorities which are listed here. I’m just going to talk to each of these and illustrate some of the activities that we’ve got underway for your interest and information. We had first on the list of priorities that came from that member and stakeholder survey were the APNIC research and development activities, and those are underway quite actively in a few different areas, some of them listed here.

The RPKI is one of the biggest, of course, and that’s something we’ve been working actively on with the other RIRs several years now. We’re doing a fair bit of work on the DNS service dynamics as the reverse DNS services are – as they grow and are amended. Also, that will relate to the implementation of DNSSEC, which is another big priority for the coming two or three quarters to complete the implementation of DNSSEC on all of our zones.

Anycast deployment is also a subject of R&D at the moment. Another one of the priorities also listed under here was an expansion of our network monitoring and reporting activities. So we’ve deployed or are in the process of deploying 12 modes into the Test Traffic Measurement Network, which is operated by RIPE NCC, and they’re going to be distributed around the Asia-Pacific region, mostly in existing root server locations.

And we also were pretty heavily involved with the DITL – D-I-T-L, Day in the Life of the Internet – project and contributed a half a terabyte of DNS packet flow data into those results.

Moving on, another top priority according to our members and stakeholders is education in the region, supporting engineering, education in general, and also expanding the scope and coverage of our training.So we’ve got a pretty active ongoing training team in the organization. Obviously that team is a small group, can’t do that much in terms of really addressing the training needs. So one of the priorities that’s really being pushed forward now is to develop the institutional links that we could use with training and educational institutions to take APNIC course material and the knowledge embodied in those and distribute them more widely. We still find that there’s incorrect information being conveyed through training and educational institutions quite regularly in the region. That doesn’t help any of us. We’ve got an online training lab, which is remotely accessible. So we do, for instance, routing and security training on site in different parts of the region. And rather than taking physical hardware with us, we – providing we’ve got a decent Internet connection – actually connect the trainees to routers and servers, which are located in the APNIC offices, and that’s something that’s been very successful. We’re doing security training with Team Cymru, and that pretty highly developed. Also working with AUSCert on security training. We’ve got both e-learning and self-paced learning as part of our delivery mechanisms for our training.

IPv6 is another big priority. Again, it comes from members and stakeholders through the survey, supporting deployment and the community’s efforts to adopt IPv6. So we’ve got an IPv6 program with dedicated staff at APNIC. We’ve got an online wiki like most of the RIRs have these days, I think.

We’re developing – taking pretty systematic approach to developing IPv6 messages and materials, outreach and information. We’re doing a lot of appearances at different IPv6 meetings around the region. And we’re seeing a lot of interest in IPv6 coming up through different existing organizations. We had a very successful workshop in – at the Mexico APEC TEL meeting a couple weeks ago. It was attended by John and Richard from ARIN and numerous others from the community. That was described in the days after that meeting as one of the best, if not the best, workshops that participants had seen at APEC TEL. We really made a good impression there and it’s likely that those – that IPv6 activities in APEC TEL are going to increase. They’ve, for instance, taken a very strong and public interest in broadband. And the message for them is that if they want, as they’ve said, to deploy – to see broadband deployed widely in APNIC economies in the next ten years – in the next five years, sorry, then they’re not going to be able to achieve that without seeing IPv6 deployed at the same time. It’s just not going to happen. So that’s a good line to be encouraging awareness of IPv6 in that particular group. But there are others as well. There’s always CD and other numerous forums where the IPv6 message is being promoted at the moment.

On services, we continue to improve resource or request and allocation processes. MyAPNIC is the services portal that we’ve developed and continually improve for delivery of all APNIC services these days. These days, again, with just better integration of membership signup and resource requests to make sure that we cut through some of the bureaucratic stuff that APNIC, I think, has traditionally been associated with.

We’re also developing – and this was another priority under the survey – automatic data exchange. So using Web services – and I think we’re going to be hearing more about that type of technology here at this meeting – as providing secure channels, sort of modern technology, let’s say. We’re moving into the 21st century here from the kind of e-mail templates and everything that looked a bit ’70s to me. But that’s been going on for some time. We’re well past the ’70s by now, I’m glad to say. And this is also linking pretty critically into our DNSSEC activities, of course.

Other things. The resource certification and support for routing security was another big priority. So, again, as I mentioned, we’re working hard on our RPKI stuff, both at the operational level in terms of service provision and within the IETF.

And we’ve been actively involved with deployment of root servers throughout the APNIC region for quite some time now. I think in cooperation with ISC we were involved with one of the first sort of independent deployments of an anycast root server back in Korea, back going on for 10 years ago now. The deployments are underway in various places in the region. We’re focusing more on the far-flung regions now, the far-flung areas now, rather than the big sites like the South Korea node, for instance. And we’re also using those root server locations for other purposes, such as the deployment of the TTM nodes, which I mentioned.

Okay. Finishing up now. The next meeting we have will be in Kuala. As is traditional for our first meeting each year, it will be held with APRICOT, APRICOT 2010 that is, which is the main operators conference in the AP region. We’ve got all the remote participation, fellowships and other support activities which go alongside that, and you can find information online about that one. Everyone is more than welcome to attend that meeting and the next two afterwards, which are APNIC 30, which has recently been selected to be in Bangkok, Thailand, in August 2010, and APNIC 31 will be with APRICOT again in Hong Kong. And that will be for the first time a joint meeting not only with APRICOT but with APAN, which is the Asian Pacific Advanced Network, the academic Internet2-type network, which is very active through the region. And that’s February 2011.

So thank you for your time. If there’s any questions, happy to answer them now or later. Thanks.

John Curran: Any questions for Paul? No? Thank you.

(Applause.)

John Curran: Okay. Next up, the NRO Number Council Report. And it should be Mr. Martin Hannigan.

NRO NC Report

Martin Hannigan: Good morning. I’m Martin Hannigan, Akamai. As you can tell, I wore my best suit for the presentation. This will be quick and to the point. So members of the NRO NC: Myself, Louis Lee from Equinix, and Jason Schiller from Verizon, UUNET.

What is it and what do they do? Well, good question. Numbers Resource Organization Advisory Council. We’re basically a check and balance in the global policy system. We have three key responsibilities: Process global policy, appoint two board members to the ICANN Board of Directors, and function administratively; i.e., procedures, et cetera. If we need them, we write them. You guys sign off on them and we do them.

So new stuff since the last time we talked. Appointed an ICANN board member from the pan and into the fire, Raymond Plzak. Congratulations.

Working on some global policy. We’re monitoring Draft 2009-6, Internet Assigned Numbers Authority Policy for the Allocation of ASN Blocks to Regional Internet Registries. We’ve been talking about this here.

Monitoring Draft 2009-3, Global Policy, Allocation of IPv4 Blocks to Regional Internet Registries. We’re going to talk about this here today, I believe. We’re also going to begin our process to appoint a new ICANN board member. Raimundo Beca from the LACNIC region has termed out.

Errata. RIPE has reelected Dave Wilson to the NRO NC. APNIC has reelected Dr. Kenny Huang. Jason –

Unidentified Speaker: Errata?

Martin Hannigan: Well, I guess. Jason had a baby, Sam, who is IPv6 enabled, and I kid you not –

(Applause.)

Jason is over there. And we will see you at ARIN XXV. Thank you.

John Curran: Questions for Martin? Okay. Thank you, Martin.

(Applause.)

A Tool for Visualizing Allocations and Routes

John Curran: We’re actually running very far ahead of schedule, and I want to try to keep the policy presentations on the clock. I actually was approached yesterday by someone who wanted to show off something, a little tool that they developed. I don’t know if Lixia is here. Yes, Lixia. Lixia has developed a tool for visualizing allocations and routes. And I was wondering, Lixia, if I could ask you to come up and spend 15 minutes doing a quick demo. She’s looking for testers who can give her feedback on how it looks and how it works. So we’re going to try to do this live.

Lixia Zhang: And I’m not looking for testers (indiscernible) the PC run the whole thing. I mean, if 10 people send out simultaneously, I worry you are going to crash the machine. But whoever wants to play with it, we are looking for feedback. I can honestly tell you, at this moment, it’s a demoware. We’re thinking about giving –

It’s not showing up yet.

John Curran: The Internet?

Lixia Zhang: I might have to close it and open it and open it again. If I close it…

John Curran: Here. Okay. Yeah. Close it and open.

Lixia Zhang: If I close it, this machine has a problem. When I close it, you lose the connection and have to restart everything.

Sorry for wasting your valuable time.

John Curran: Not a problem.

Lixia Zhang: (Indiscernible) but basically sorry for wasting your valuable time. I think I shall give all the credit to Cathy Aronson. This is my second ARIN meeting. The first time it was 2002 when ARIN tried to change the minimum allocation policy from /19 to /20. And Cathy, who knew we’ve been playing with BGP thanks to VMware and RIPE for providing the data. So Cathy’s question was if we change the policy, would that make the document table I guess a little bigger. My instant reply was, don’t worry about that. As far as we can tell, people just chops, no matter how big a block you allocate. But, nevertheless, I think we track the data and make presentation then.

So there’s a renewed interest to have a better understanding of that data. And this time I got lucky, got a good student. So I didn’t build this tool, honestly. It was the student called Lucas Wong. He made this whole thing. This is little guy who didn’t understand anything about ARIN, about BGP. I just dumped the whole thing on him and said, Apply (indiscernible). You know, I’ll see you later. He show me. He say, Hey, look at this, whether this works. I got a senior student now. He’s a post doc called Ricardo. The creature, Cyclops. It’s another great tool. If you haven’t heard of that, I will do a 30-second advertisement. Cyclops actually looks through the entire global Internet, looks at which AS connected to which other AS, who announce which prefixes and send you alert if someone else announce your prefix. Just look at cyclops.cs.ucla.edu. You can set it up. Type in your AS number. It shows you what Cyclops actually sees by all the prefix announced by you.

John Curran: Okay.

Lixia Zhang: You got it to work?

John Curran: Now we’re back in business.

Lixia Zhang: Great. Arrangement. Okay.

John Curran: Wow, little bit big. You might not want to mirror display; might want to just put it up on the other display.

Lixia Zhang: If I know how to do –

John Curran: You just drag it to the right place, Lixia.

Lixia Zhang: Okay.

John Curran: Use that one at the side. Where is your program?

Lixia Zhang: (Indiscernible) just way too big.

John Curran: It’s just way too big. Yeah, you might as well mirror it. Okay. So you can at least size it here. You’re going to have to resize it.

Lixia Zhang: Otherwise I think we may as well just have to show you like a corner of the whole thing, and you can come to me –

John Curran: Yes, whatever.

Lixia Zhang: – so we don’t waste more time with it. So the thing you cannot see – you only see like, I don’t know, 15 percent of that – is actually the entire IPv4 address space. Each blocks here actually represent /8, as you can – as I go over, you can see that’s /8, every block. And if I could make it down, you can actually see the entire thing. Okay. And what you may be puzzled is with a filled block and what are the colors around some of the blocks. And there’s a legend that I can explain to you. Oops. Going to the wrong place. So the light colors are reserved, dark colors are allocated as multicast. I’ll explain to you. So that’s a white square, but with a light (indiscernible) before your RIRs get created. Multicast. And so here’s the thing that is – the red ones without filling, that’s IANA to ARIN. The short one, that’s your ARIN, have allocated to wherever you’re allocated to, where actually show you all the details. That’s the color-coding stuff. Now, with that you can look at some things. So let’s grab – these two things are very important. This shows you RIR allocations. So look at 24. That’s really 24 /8. So that says that IANA allocated to you guys. If I click on this one, you can see that’s filled up entirely because you guys allocate – made the last allocations. So therefore you don’t really know what happens going on there.

Oh, by the way, why do you have this little blue line, little black line there? That’s because there’s a few blocks on that part of your block actually now managed by (indiscernible) and I think now LACNIC for some historical reasons that I don’t understand. You can just click on block that expand it. We can expand it indefinitely. Well, to whatever the size is, if it makes sense. So now you can see this whole thing is a /12 for each block. Now I can see more clearly that the blue line actually falls into this. This is 24.128. And if you’re interested in this, it’s further expanded. So now the granularity is /16. The one thing you cannot see here, which let me see if I have to drag this down. I really don’t know how to size this thing. It’s actually all the detailed allocation information.

So that shows you that for the first block, for the current covered region, that shows that – this first one is how much, and when you’re allocated, by whom, to which organizations, countries, cities. The city nominate the head culture of the organization. And then you can drill down as bigger as you want to see it. Now you click on it. Again, now the /20 for each block. This is one thing. But, remember, originally Cathy told us we should try to figure out for the allocations, what get actually announced. And that’s more interesting. So that is current by –

John Curran: Keep going. Go up.

Lixia Zhang: Go up. This is a complicated thing. I apologize. Something interesting just to show demos, but I realize now I don’t know how to. So when you click on what gets seen on the BGP, that’s actually normal business. You can see interesting. Then you pick a very interesting system. 18 /8s that MIT wire used to be.

The thing is that – you cannot see the whole thing, but essentially you can see the red line on the top. It’s one red square. It’s one allocation. And below, there’s – yellow line is one, yellow square, it’s one announcement. MIT is a model citizen that get one allocation, they make one announcement. But I don’t mean to say anything bad about the IPOP, because I really love IPOP. I’m using it and I have lots of friends. If you look at the IPOP, one allocation done many years ago. I can show you when it gets allocated. If we just scroll down you’ll see my beautiful table underneath it. So it’s ARIN allocated to IPOP back in 1990, (indiscernible) Cupertino. But what you notice is little thing underneath. Right? What is it? That’s the perfect announcement as we can see global-wide from BGP. How many they have, number is 92. Where it comes in 92? You cannot see the whole picture, but I can tell you announce one something /8. They announced two /9s. This is where the middle brick comes down and then announced a bunch of other things. This is something like /20s, 22s. Maybe this is even down to 24s.

So what are the stacks? Stacks means that, you know, for example, this is a /9. This is actually a partial block of /8, and this of course is a partial, partial block of that /9, and this it will be the partial, partial block of that /9 and this would be further. So if you want to see the details, just click on and they can expand and see that exactly which range they are now stopped and we’re currently working on how can we encode and whatnot, train for AI – I mean UI. Unfortunately we don’t really know. You say how’s the best way to encode the scheme? To understand, you can see where this prefix gets announced up, you know, by which AS in which location. We actually have some – we have that information, we just don’t know how to show it in a very concise and understandable way. As much as I wish in time, but whoever interested, please come to me and I’ll show you the full picture.

John Curran: Lixia will be here for some of today, right.

Lixia Zhang: I will be here until 12:00.

John Curran: Okay. So if you happen to get a chance at the break or you can always contact her and give her feedback. The tool is online. You saw the URL.

Lixia Zhang: Please don’t come –

John Curran: Don’t all log in at once. Add some number of random hours and log in and take a look at it. Thank you, Lixia.

(Applause.)

We are still ahead of schedule. And amazing given the logistics of getting that done. But I don’t want to start the Draft Policy 2009-5 ahead of time. What do we have next on the agenda? Is there something we can pull up? How about we want to start in on the – if LACNIC is here, we could do that. If Ricardo is here. Thank you. Why don’t we do the RIR Update from LACNIC, if that’s good, Ricardo.

RIR Update - LACNIC

Ricardo Patara: My name is Ricardo. I work for LACNIC as the technical manager. I’m in charge of some of the engineering IT and registration service. I will try to give you some information about what we are doing in LACNIC.

Some summary. We are still growing in number of resources being allocated. Membership is also growing. We’ve just reached a thousand members some – a couple of months ago. And also as we are growing in tasks, in members, we also are growing in staff. We are 22 at the moment, not so big, but something good for us. This is a graph showing how is the members distributed according to the categories. We have some categories based on the amount of IP address they hold. The largest category is the small members, is the light-green part, but we also have a good amount of members in the medium and end-user category. But so far we have 1,033 members. And something interesting to note is that we have two NIRs in our region, in Brazil and Mexico. And the members of the NIRs are also considered members of LACNIC. So this explain a little bit some of the growth we can see from 2006, 2007, something like that.

Some information about the resources being allocated. The idea here is not to show the form of address space being allocated, but the number of allocations being made regarding to IPv4, IPv6, and ASN. IPv4, we can see it’s not growing so much. If you compared the number of allocations, but in volume of address space being allocated, we can see some growth.

Something about the policy development. We have a new policy development process. It was established last year. And we have this new process called expedite process. Einar mentioned something about the ASN, the global ASN policy from IANA to RIRs being discussed in LACNIC as this expedited process. The idea is to have – as we have only one meeting per year, there might be some issues that need to be solved before the next, the following meeting, so we’ll have this expedited process. The idea is to have outdated discussion and consensus on the mailing list. We have 60 days for the policy discussion, the mailing list after that the Chair called for a consensus. We have 14 days to reach the consensus. And if the policy is approved, it will be implemented, but we have requirement to present this policy on the following meeting. So the community can be informed about the process and how it was implemented. We have also two co-chairs, one in – from Mexico and one from Uruguay. The one from Uruguay was elected during the last meeting in May.

Some discussions being – well, some proposals that were discussed during the last meeting in May, these ones were approved, called for last call and no big issues during the last-call process, and it was ratified by the board and it’s going to be implemented shortly. We have this global policy for IPv4 from IANA to RIRs. It was approved in our region, in other things like IPv6 allocations to ISPs, and if ISP have already IPv4, they can receive IPv6 more easily. So the idea is to promote IPv6, another interesting thing. And the last one on last call is the one I mentioned for ASNs from IANA to RIRs. In the expedite process, the 60-days for discussion has already passed. It’s in last call now.

Some information about the last LACNIC meeting was in Panama. We had 300 persons attend from 40 different economies. We had a lot of tutorials. And I saw some interesting presentations, technical presentation about projects we are going – we are developing, like the SIMON project. This idea is to monitor how is the Internet connected from the end-user perspective. It’s a very nice project. You can go to our main Web page and have some more information about it.

We also have – we tried to go to the Caribbean region to have some meeting there for the ISPs in the region. We had one in July in Trinidad & Tobago, which was a very good meeting. Also we had 70 persons from the region. We had some presentation about LACNIC, the policy proposals and other projects we are conducting. It was a very successful meeting.

We also have – are doing a lot of outreach regarding IPv6. So far we’re able to go to 11 different countries to talk about IPv6, give some information about how is it processed to access, to receive IPv6 allocation, but we also give some training about IPv6 technical training about IPv6, how to configure the router, how to configure the desktops and things like that. It’s been a very nice and successful activity.

We have this – what we call FRIDA program. The idea is to give some money to ICT projects. It’s also very successful in our region. We receive a lot of requests for this kind of thing. The last call for projects, the call for projects this year finished last October in the beginning of October, and soon we will publish in the Web page, the projects selected for funding.

We just started something new interesting in our region to give award for outstanding achievement. So it’s a way to recognize people that played a very important role in the Internet development in our region. We just started this year, and this lady, she got the award. She’s from Uruguay. She’s the head of Central Computer Service in the university there. And she’s one of the first persons. She connected the university in Uruguay to the Internet. She has a lot of history. She’s a very important person in Uruguay. That’s why she got this award.

Some activities. We had this government working group. The idea is to have the government and the representatives working together with LACNIC receiving some information about what we are doing and also to listen to their expectations, to their issues. We conducted the second meeting in Rio de Janeiro, and we also had this preparatory meeting for IGF during the same week. It was successful. We had like 110 people attend the meeting.

And also in regards to the public affairs, we are participating in some regulatory meetings like CITEL, trying to – the same thing: listen to their issues, present some of the things we are doing, and try to address those issues in the IGFs and other meetings around the world.

And we also have this project to deploy anycast root, anycast copies of the F-root, in this case. We just installed the – the last one started was in Sint Maarten during a meeting we had there, which was in July. It was very good meeting there.

Finally, some projects we are conducting. We are very busy with these projects, like RPKI. Like every other RIR, we are working on these projects. The idea is to have certificates to – the idea is to issue certificates to IP every time we make an IP allocation. We’re doing this – the idea is to have something ready by the end of the year, so people can start playing with it and trying and debugging.

We also are reviewing our DNS platform. And idea, planning to have DNSSEC deployed. We just started to play with some of the domains we have in the .org, so we get some experience.

And I guess that’s it. If you have any questions.

John Curran: The floor is open for questions. Any questions? Just looking. No. Thank you very much.

(Applause.)

Ricardo Patara: Thank you.

Draft Policy 2009-5: IPv6 Multiple Discrete Networks

John Curran: Okay. It’s now time for us to resume the policy portion of the meeting. We’re going to pick up with Draft Policy 2009-5, Multiple – IPv6 Multiple Discrete networks. So the proposal introduction was in March 18th, 2009. That was Proposal 84. Became a draft policy on the 21st of July this year. Similar proposals. There are no similar proposals in any of the other regions related to this. The AC shepherds are Heather Schiller and Owen DeLong. Summary. Would allow IPv6 initial and subsequent requests for discrete networks, /32s for ISPs and/48s for end-users. Liability risk, none. Staff comments: “In the past some organizations have been denied or were forced to open multiple accounts to accomplish their goals.” This might be a better way for them to accomplish what they’re trying to do. Resource impact, minimal. A fairly straightforward change.

Comments. 28 posts by 12 people. Three in favor, none against. “This policy definitely would resolve my issue. The long and short of it means that if there’s only – if that’s the only workaround that my deployment will be delayed until at least Dearborn… Not exactly making IPv6 available to the masses.”

Okay. That’s the introduction. I’d now like to have Heather come up and give the AC presentation.

Heather Schiller: Good morning. So this policy was proposed to resolve a problem, the inability to obtain separate net blocks for organizations that had several discrete and entirely separate networks. There is a similar policy in IPv4 to accommodate this. That policy alters the utilization requirements for an organization to obtain a separate net block to be used for another part of their – for a separate network that they also manage. And this policy just creates a similar mechanism to obtain IPv6 for something other than utilization when you have a second network that you run. And the text for this policy is exactly the same as the IPv4 text, with one change. And this is where the utilization requirements are different. And so in the IPv4 policy, there’s something about the amount of address space you have to use in your existing assignments in order to be able to qualify for a separate net block for other parts or other networks that you manage. And this policy, you just have to show that you have a separate network requirement. And do we have 6.5.2? I didn’t include it in my slide. Do we have 6.5.2 that we could pull up?

John Curran: It would take a moment.

Heather Schiller: Okay. I didn’t realize that I should have put that up there, too, so you could see what the criteria is for existing utilization.

John Curran: This one has it in the program. You have the NRPM in your program? Collector’s edition, guaranteed to change.

Heather Schiller: I think that’s it. Questions?

John Curran: The floor is open. Yes. Center front.

Kevin Loch: Hi. Kevin Loch from Carpathia Hosting. This is the comment time for this?

John Curran: Yes.

Kevin Loch: Speaking from someone who runs multiple discrete networks both in IPv4 and IPv6, I do fully support this policy.

John Curran: Okay. Good to know. Microphones are open. Center front.

Kevin Oberman: Kevin Oberman, ESnet. Assuming the first part of 2009-7 was passed, I think that would completely obviate the need for this policy change. If – no? Okay. I’ll let the distinguished gentleman behind me tell me why that’s not the case.

David Williamson: David Williamson, Tellme Networks. At least in the case of end-users, if you get a single initial /48 and multiple discrete networks, it’s very hard to justify on utilization alone that you can get additional space since you’re unlikely to reach an HD ratio that’s reasonable with the single /48 anytime quickly. And if you have multiple discrete networks with perhaps multiple ASs, it’s very hard without this policy to find any way to get additional space, which limits your ability to deploy IPv6. That’s kind of a show-stopper and makes this entire policy a no-brainer. If it’s not obvious, I completely support it as written.

John Curran: Okay. Microphones are open. Center front.

Owen DeLong: Owen DeLong, Hurricane Electric and ARIN Advisory Council. In my role at Hurricane Electric, I have visibility into how some people are deploying IPv6. We have a couple of IPv6 customers at this point. And we have a number of customers who have expressed strong benefit from this policy, one of which is a rather well-known and rather large virtual and physical video content delivery company, and they really would like to see this policy in place.

John Curran: You support the policy?

Owen DeLong: Yes.

John Curran: Okay.

Owen DeLong: Completely.

John Curran: Center – center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I support the policy. However, the one thing I’d like to get on the record or in the open is there seems to be an impression that this applies to a relatively small number of people, but it is very important to them, which I think is the case.

I’m wondering if we could get a sort of statistic of some number of how many people use multiple discrete networks in v4, whether that’s number of allocations or whether that’s 1 percent of all requests or whatever.

John Curran: You want people –

Leo Bicknell: But I know –

John Curran: Raise your –

Leo Bicknell: – compared to total number of registrations. I understand people use it, but is that one out of every 100 requests? One out of 10,000 requests?

John Curran: Okay. I don’t think ARIN has that sort of information in a statistical model, because that’s something that we would need to record for every incoming request. So, Leslie, do you want to respond?

Leslie Nobile: Actually, we do track this. We track each type of policy that someone qualifies under. So if it’s multiple discrete, it’s goes into some of our files, but it’s something we actually have to go back and count manually. It’s not auto accessible. I can get the data; I just can’t get it now.

John Curran: And I guess the question comes up: Would your support of the policy vary based on the answer to that data?

Leo Bicknell: Likely not. However –

John Curran: You just like keeping us busy.

Leo Bicknell: No, were the statistic to come back that 50 percent of the people requesting space were using this policy, then I might consider changing my support. I think that’s extremely unlikely. But with no visibility into the data…

John Curran: Understood.

Leo Bicknell: If we can get a rough order of magnitude quickly, that would be I think setting a lot of people at ease.

John Curran: A rough order of magnitude would be available by asking this floor to show hands for who uses it. Would you like that?

Leo Bicknell: I don’t think this floor is representative of everyone who gets address space.

John Curran: You asked rough order of magnitude; that’s why I offered that.

Leo Bicknell: I don’t think this floor provides that in this case.

John Curran: Okay. Next, Cathy.

Cathy Aronson: Hi. Cathy Aronson, ARIN AC. As one of the people that helped work on the existing IPv4 for multiple discrete network policy, I would actually like to respond to Kevin’s question about why removing the /32 aggregate requirement doesn’t solve this problem. I worked on a network that had multiple discrete networks, and we had two different divisions with two different business models. And if I had to justify, one was almost completely utilized and the other one was almost not utilized. And if I had to hold up one to get address space for the other, I would have gone out of business. So even if you split up your /32 and your upstreams are willing to accept two different announcements from two different ASs for two different blocks, if you have to go back to ARIN and justify utilization based on that and you don’t have enough to get enough for the one that’s running out, you’re hosed.

So that’s why this came to be. Anyways, I don’t know, Andrew is in the room; he could speak more to it because he was the instigator of it.

John Curran: Wait, Cathy, given that, are you a supporter of this policy?

Cathy Aronson: Yes, totally in support of the policy.

John Curran: Okay. Center front microphone.

Andrew Dul: Andrew Dul. I’m the author of the original IPv4 proposal. I support the IPv6 proposal. I know of a number of people who have used the IPv4 proposal. I know it has also made ARIN’s life a lot easier in not having to tell people, well, we can’t do that, you don’t fit in the model, blah, blah, blah, make up other stories. So I really think that this is important because it is about the way that companies do business today. And ARIN is in the business of fostering the Internet and we need to foster v6, and one of the things that we need to do is we need to make our policies mold with the way that entities do business today.And this is one of the ways that entities do business, by having multiple discrete networks that meet different needs and different requirements depending on how big the organization is. It just makes sense to sometimes divide up your network, and I – with regard to the removing the /32 single announcement restriction, I don’t believe that that solves this issue for the main reason that Cathy highlighted.

The other issue is that the simple example is if you have three networks and one of them is at 100 percent and you just added an allocation to the other two, your overall utilization is still very low. So you cannot grow that one and one-third section. So that’s what prompted our original writing of this policy. Thank you.

John Curran: Thank you. Microphones remain open. Center front mic.

Kevin Oberman: Kevin Oberman, ESnet. After Cathy’s excellent example and follow-up comments, I just want to make clear that I do now support this proposal. I had not thought about that very obvious issue.

John Curran: Got it. Okay. Center front.

Jason Schiller: Jason Schiller, Verizon/UUNET. And even though this does create more routes at the routing table, I am in favor of this policy.

(Applause.)

John Curran: Jason No-Route Schiller, could you explain?

(Laughter.)

Jason Schiller: So we have had need for an IPv4 multiple discrete policy and we’ve used it. I can understand how people might have a need for treating address space separately and discretely.

For example, if they have multiple stub networks. I don’t think it will lead to a large increase in the routing table growth. So therefore I think it’s a good policy.

John Curran: Got it.

Jason Schiller: I would like to point out one minor difference between the IPv4 and the IPv6 flavor.

John Curran: Okay.

Jason Schiller: In the IPv4 flavor, there is a requirement where, when you go back for more space, they look at the overall utilization of all of the discrete networks of the ORG. I’m not sure that this should or should not apply to the IPv6 flavor, mostly because I think on day one people are going to typically get greatly oversized allocations.

But you might want to do something that’s in between where if I ask for three multiple discrete networks, you give me three /32s and I come back in a year and I say, oh, I need a fourth. You might want to at least check to make sure that my three are in use.

John Curran: Understood. If anyone – microphones remain open. I want to call out those people who oppose the policy. Could you charge the microphones right now and get up there? Okay. So remote participant.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I’d like one clarification from staff. Is it staff’s opinion that this does apply to end-users as well as ISPs?

John Curran: Yes.

David Farmer: Cool. I’m seeing nods. So I guess the answer is yes. Thank you. And I do support it.

John Curran: Very good. Whoever is opposed to the policy, I can’t see you. Can you please make yourself more evident. If you’d like to speak out against this policy, the microphones. Yes.

Scott Leibrand: I have a remote comment from Joe Maimon. Let me read it before I actually read it to make sure I understand it. Okay. Yeah. This is perfectly clear.

“The policy as written appears to take steps of opening the floodgates, and, as such, I support it with the caveat if the restriction on single aggregate advertisement is removed, technical justification why that would not suit for application under this policy should at that point be added.”

So I – this is now Scott speaking. I think that is a request for staff to make that a part of the application process.

John Curran: Acknowledged. Okay. Any other comments? I’m closing the microphones. Microphones are closed. All right. Thank you, Heather.

(Applause.)

Now it’s that point in the program where we get your feedback to supply to the AC. So we’re going to get the tabulation engine out. I see readiness. Okay.

On the issue of IPv6 Multiple Discrete Networks, I’m going to call for a show of hands. I’m first going to call all those in favor of the policy proposal of the Draft Policy, and then I’m going to ask for all those opposed to the Draft Policy. Okay. Ready. All those in favor of Draft Policy IPv6 Multiple Discrete Networks, raise your hand now.

(Show of hands.)

The first stretch of the morning. Nice and high. Okay. On the matter of IPv6 Multiple Discrete Networks, all those opposed to the proposal, raise your hand. Higher. I can’t see you. Thank you. Numbers are coming up now.

Okay. On the matter Of Draft Policy 2009-5, number of people in the room and remote participants total 146. Those in favor, 79; those against, zero.

This information will be provided to the Advisory Council for their consideration.

Open Consultations

John Curran: Okay. We’re still nicely ahead of schedule, a place I’d like to stay. Do we have the revised slide ready? Okay. Why don’t I go with the original slides. One of the items we have is we’re going to call to your attention that we have open consultations.

ARIN has a Suggestion and Consultation Process, and as part of that we’ve put a number of them out before this meeting, and these are things that you folks should be interested in, because they’re how the organization gets guidance on how we run operationally. We have a quick summary of these, which is coming up momentarily. There we go.

Open consultations. Okay. So the Consultation and Suggestion Process, the ARIN ACSP, provides a formal mechanism for the community to suggest changes or additions or suspension of ARIN services or practices.It’s our suggestion box, if you have something you would like to have formally considered. Obviously you can suggest something to any of the staff. Come up and say, John, I think you need more cookies. Or, John, this remote should be thrown out. And if you suggest that, we’ll take it seriously.

But sometimes people have formal suggestions they want to air publicly: We think ARIN should be doing sparse allocation for IPv6. Okay. If that’s something that you – that you want to make sure is mentioned and everyone hears, you can bring it to the floor of this meeting and that will suffice, but you can also bring it to the Consultation and Suggestion Process, and that way it’s publicly shown that someone suggested it and that way you know you’ll get a formal response.

We also use it. So to the extent that my wonderful staff – I actually do have a wonderful staff at ARIN. To the extent they come up with ideas changing how ARIN does things, sometimes I just say, Do it, and sometimes I go, You know what, we’ll run that past the community; we’ll put that out because they may have a view on how we do something.

So I’m going to talk about a number of – these are ones that have been staff initiated, internal to ARIN, and they’re out there as the consultations.

So first one is – we have three of them outstanding. One of them is changes to ARIN resource revocation, one is changes to the RSS feed, and one is retiring ARIN e-mail templates.

First one: Consultation focuses on whether ARIN should reduce the amount of time an organization has to pay overdue fees to six months, at which point no payment has been made the resources would be permanently revoked. At present, if you don’t pay ARIN, we remind you a lot, but we actually don’t release the resources until 12 months later, because we’re concerned that sometimes you just have a bad billing address or the invoice gets lost or something. And the implications of reassigning someone’s address block for non-payment is not something you want to do lightly. What we’re proposing is that at the six-month mark we would tell you it’s been revoked, and then we would take that and we would put that – actually announce that to the community in one of the feeds that is actually part of another consultation. And that way people know this is going to be freed, it’s no longer part of the organization. And that way we could have it in hold-down for six months before we actually reassign it to someone. And I think that’s pretty important, because we want to have a clear process and we want to have enough time. If we wait a year, we don’t have enough time to leave the block unused before we reannounce it. So that’s out there. Comments are welcomed. They can be on arin-discuss. Also, of course, you can find a member of the staff, myself, Bob Stratton, Mark, happy to hear about this, Leslie.

Okay. Next one. Changes to the ARIN RSS feed. This is whether or not ARIN should add a daily recovered address space to the daily RSS feed. We currently talk about allocations. We don’t talk about recoveries and whether we should enhance the current RSS feed and format by making it available on XML. There’s some pros and cons to this. We’ve had people say, I really want that data, it would be useful to me for my research, statistics, cleaning up my own databases, my block lists, whatever. We’ve had a couple of people say, You’re going to announce these and that is effectively an announcement to hijack; go get this block because it’s no longer being used. So we’re interested in community feedback on this. We don’t want to act precipitously. We want to make sure we get, again, comments back either directly to the staff or on ARIN Discuss as you wish.

And then retiring e-mail templates. We actually sort of already discussed this one. I told Mark to put it out for comments. And yesterday Andy got up here and talked a little bit about it. So I don’t think we need to cover it. It is out there and we’ve seen quite a bit of discussion.

I just want to remind people again we have three of these outstanding. To the extent you haven’t weighed in, please feel free to put your comments on arin-discuss. That’s it. Thank you.

Okay. We are now at the point in time when it’s getting ready for our morning break.

Aaron Hughes: John?

John Curran: Yes. Questions? Wear a microphone. Yes.

Aaron Hughes: Just for the sake of sanity and lack of confusion, can you please change the retire e-mail templates to retire e-mail POC templates?

John Curran: Yes, it shall be done.

Aaron Hughes: Thank you.

John Curran: Okay. It’s time to take a little break. Get up. Again, we have the information center open and you can learn about ARIN there, see the materials we use to brief people. Our registration services and election help desks are open. Our billing help desk is always available by appointment. I expect to see people here back promptly at 11:00. So you have 30 minutes. Enjoy.

(Break 10:26.)

NRO Activities Report

John Curran: If everyone is going to be seated, we’ll get started. I’m looking to see if we have our presenter ready. He looks ready. He looks excited. Okay. All right. We’re going to pick up the afternoon – sorry, after break here with the NRO Activities Report by Axel, and then we have a presentation of the RIPE NCC Update from Axel. So…

Axel Pawlik: Thank you, John. Oh, yes, Adiel. I’m not Adiel; I’m Axel. Adiel couldn’t make it and sends his regards and wants to come next time, but it’s me for today. I think you must have seen most of this already, so I’ll quickly move through this and then we can always get our plans for our flights back home and be done.

All right. What’s the NRO. The NRO is the RIRs working together. We have basically re-established the ASO and the ICANN framework in October of 2004. So you know that apparently already. We have current office holders. It’s Adiel is the Chair, me as the Secretary, and Raul as the Treasurer. And every year, of course, that circulates around. So I would Chair next year, Raul will be Secretary, and, hmm, Treasurer – I don’t know. We’ll have to check.

We have a couple of coordination groups within the NRO basically to help us as much as possible to organize our coordination work. There is the Engineering Coordination Group with Andrei from RIPE NCC chairing it. There’s the CCG and the new Public Affairs Coordination Group. The first is the Communications Coordination Group. And both are chaired by Paul Rendek.

As you know, the RIRs are splitting their expenses according to a complicated scheme that’s based on number of allocations and overall money coming in and flowing out. That’s the percentages here. That is a formula that we use to pay for all the costs that the NRO-related activities bring. Part of that is the NRO contribution to ICANN. For a couple of years we have been stable in our contributions to ICANN. We have re-signed and resubmitted a letter or exchange of letters actually between ICANN and ourselves to say we are happy with the way things are going, we want to contribute like we did last year. Of course, we do go to ICANN meetings regularly. We have a couple of regular meetings there.

Probably the most important one here is – speaking for myself is consultation with the Governmental Advisory Committee. We do that quite regularly. Not at every ICANN meeting, but most of them. Basically presenting the status of the life of IPv4 and where we are with IPv6 and what we are doing about it. And that basically is taken very seriously and is supported, and they’re quite happy with us doing this.

Okay. A future meeting. There is, yeah, well, one ICANN meeting happening next week, so I’ll go home and wash my clothing and go off to Seoul to be there. Another interesting meeting. Once a year it’s the IGF, Internet Governance Forum. All the RIRs together go there and present our cause. For the next IGF in Sharm El Sheikh, we do have a major workshop lined up basically to help us again vent the issues that we see to report again on IPv4, IPv6 and similar things.

And of course one of those things that is always very hot on the stove, on the burner is the ITU and their ideas of how they can fix the world. And, as you know, possibly right now there is an ITU Council meeting happening that is discussing, among other things, of course, the plans of ITU to become an Internet registry. Very interesting. So we are behind the scenes, very active in talking to our member – our members. Our members, also, but about our – I was about to say member states, but that’s the ITU. I’m not confused, really, here – to talk to the governments within our regions to help us here and to defend our cause.

OECD. Well, you’ve probably heard about that before. We have forged quite good contacts with OECD. There’s the Internet Technical Advisory Committee within the OECD now following last year’s June big meeting in Seoul. So we’re well represented there.

Overall, there’s a number of things that we’re working together on. We had a retreat. I think that’s the most pertinent here. Retreat in June following quite a long retreatless time. We have the next one scheduled I think for February, sometime early next year, basically to take some time off and really spend time discussing strategies. Of course, we do have regular monthly tailored conferences as the CEOs together with the chairs of our coordinating committees. They run very regularly and prove quite helpful. Outcome from the retreat was the creation of the new coordination group, the Public Affairs Coordination Group. Basically the idea is to have people who are well versed in dealing with governments and to help us poor techies understand that strange world over there. That works quite well.

And we have in the past circulated also some technical infrastructure through the RIRs as the various jobs, the various positions within the NRO rotate, technical stuff rotated as well. It’s not necessarily the most efficient way of doing things, so we decided not to do all of that anymore. For better coordination, the coordination group chairs will be hosted by the same RIR that will be from the same RIR as the EC chair. That basically is it. If you have any questions, I’m happy to answer them.

John Curran: Any questions for Axel? Wonderful.

(Applause.)

RIR Update - RIPE NCC

Axel Pawlik: I’m Axel. I’m the director for the RIPE NCC. That’s the RIR that sits in Amsterdam in the golden sunlight every day. I hear it’s really dark and nasty over there. So same as here. So it doesn’t really make a difference. We’re sitting inside. I miss my big windows out of the office on to the canal and stuff. But on the other hand…

Good. Some vital statistics. End of August we had 6,388 members. Or thereabouts. It’s still growing. We do see a decrease of the members – of the future members that apply and then actually become members. So that used to be much higher than before, much higher before, and now that is dwindling down a little bit. But still there’s net growth of members; that’s a good thing.

Significant number there. We also have a thousand members, more than a thousand members, and that’s in Russia alone. So that is a very significant part of our membership. And I don’t know what they’re doing there and how many ISPs are being brought about, but I think it has something to do with the very distributed way of dealing, then, with major city areas or smaller city areas also.

Budget for this year. RIPE NCC is about 15 million Euros; staff is 110, 111, 112. Depends on where we’re actually are.

Our board is stable for a very long time, which is a nice thing. And our chairman is here. Actually he’s the guy in this funny greenish-turquoise shirt over there. And the overall – we are quite proud that while we increase in net staff members at the RIPE NCC, our member count goes up much steeper. So overall we improve efficiency, which we should be doing. We recently had a RIPE meeting you might have heard about that. We had a general meeting there as well where our members and our board and ourselves – oops – decide on the way forward for the coming year.

For that we prepare a draft activity plan and a budget. That is something that the members get before they meet. But they don’t decide on that. That’s the responsibility of our board. However, the members decide on the income side of it, of the charging scheme.

So we plan for next year somewhat not-so-small increase in budget. That has to do with the increased outreach but also with our policy that we’re implementing right now, 2007-1. Basically that’s the fixed – that’s the contracts per PI assignments. That’s something that we have to deal with and we’re dealing with. And we have a slide on that as well. There’s quite a need for some FTEs there.

We also have been told by our members that we should do some sort of remote voting and we should simplify the election processes so it doesn’t take that long. We have done that. We’ve prepared articles, change to the articles, and those have been approved. The funny thing here with the voting is that I said no, I don’t really want to do the e-voting right now. I think it’s a good thing, but let’s do just postal ballot. That should work as well. Postal system all over the place and that should work. No, it doesn’t. A Dutch association is not allowed to do remote voting with a postal ballot. Funny, that. They do allow e-voting. Of course, the idea behind this is members of an association should be able to react on the spot basically to what’s going on in a general meeting. And e-voting would do that to some degree. But also there are no e-voting weeks before the general meeting. I think that’s strange. Doesn’t make sense. Anyway, we implement e-voting and then our members would be happy.

Other things we do. We do run the K-root server set, and we have deployed another one in Africa. We are currently also talking to LACNIC to bring some to the South American continent, and we continue with this as we go along.

Information services. Paul has mentioned earlier that we are partnering with APNIC on the TTM deployment there, which is great. RIS back-end, well, that’s basically making it more efficient and faster. BGP visualization tool. Difficult word. That BGPviz, it’s available there now again. And we have thought for some time about a way to make all those really nice services and tools that we have available in some way that is understandable and people maybe don’t need to see a set of real tools with funny names, but a sort of portal-like thing. And we have the very first version of that online and it’s available through ripe.net.

Customer services. That’s the PI-assignment thing where we’re supposed to get our dirty hands on individual PI-assignments and make sure we know who uses those resources. A couple of phases there. Interestingly enough, we have had – I’ve just heard that the numbers haven’t changed dramatically since end of August there. Quite a number of registries have actually participated in this. Quite a number of resources have their status set as being responsible, having a member responsible for them. The idea is those PI users, PI holders should have a contract, a lightweight contract with the member of the RIPE NCC that has assigned those resources to them. If they don’t find a friendly member, they can come to the RIPE NCC and have a direct contract with us, which would be more expensive. But, in any case, that’s how it goes. There’s a time line to the end of December to deliver all those contracts, and I hear that just over 1,100 have been sent to the NCC. So there’s quite a lot to be done there. And that’s only the easy part. The complicated part is, of course, chasing people and especially chasing people for assignments that are really, really old. And that’s where we need those extra resources.

Training. As you know, we do lots of training and we are talking to lots of members this way. There’s also important membership interaction for the RIPE NCC. But we have been told to also – we’ve been asked many times: Do you do anything in IPv6 training? We used to say not really training, is now other people, commercial training organization’s job. Although we have been told to do this and we are trying, we are treading very carefully, trying not to intersect our training areas with areas where some of our members or commercial organizations might be doing business. So we have done this. We have developed a cost, which we have for the first time given in July in Moscow where we had a regional meeting. This thing seems to be very popular, and of course it allows us to say that, yes, we are doing IPv6 training, too.

We have the IPv6ActNow website, and some of that stuff is there so you have data testimonials and movies there. And, well, we do what we can.

Again, e-learning. Having face-to-face courses is great, but it’s a limitation. We only have so many trainers, and there’s only so much travel they can do, so we do e-learning as well.

Science group. The focus of our science group is still on the quality and consistency of our registration data and basically focusing there on historical registration, which is a long-time project that is now bringing the first fruit really. And there was a presentation at the RIPE meeting also. You can look it up on the RIPE NCC website. So there is some help, and some of the things are between the RIRs where we look at some address blocks in different ways, and Geoff is always pointing his fingers at me and poking me in the ribs and others for this, so Geoff is with APNIC.

Then we have a number of new tools. The resource explainer, Rex. Basically giving lots of information about specific address books, for instance, for anytime in the past. Like what’s the history of this address book? Has it been used by shady individuals or shady – for shady activities or not. Is it clean, not clean, and other things.

Then, as I said, the information services tools are being bundled under a portal-like thing we call it Netsense. Basically the status of the Internet. The Internet is broken today. That’s what my wife always tells me. She calls: Did you do anything? The Internet doesn’t work. No, the Internet works perfectly. So she can look at that in the future. No, the Internet doesn’t work for her, so she can’t. I don’t know. So have a look at that. That’s nice stuff.

And the INRDB, the – what you call the ultimate number resource database, is also now available. And I said earlier on RIPE Labs – and nobody shouted at me – RIPE Labs is a new development. Basically we have been looking at each other at the NCC. Well, we are running out of IPv4. Oh, yes, what do we do after that? We continue allocations with IPv6, but not that much.

We used to be the network coordination center for services for the NCC and we said we wanted to go back to that, and that is the result of quite a bit of interaction with our board, also strategic thinking, where we’ll be in five years’ time. So we decided to reestablish ourselves as the network coordination center. And while we really continue to be the RIR for the region as well, there are other activities that we’ll be doing. So do we want to push this, how do we do this.

Robert Kisteleki came up with a great idea: Why don’t we do something like RIPE Labs where we can present stuff that we are doing that in the past we have felt is not quite up to scratch yet. Like I said – what was it? Netsense. Netsense is now out in version 0.1. It works mostly, but it can be a little bit slow and some things don’t work yet. For instance, IPv6 – sorry, that’s not the thing. The Rex resource explainer, IPv6 doesn’t work for that one yet. But we will, of course, cover that. But by now within the RIPE Labs environment we can present that stuff, say, This is something we are thinking of, this is something that we have rudimentarily implemented and what do you think about it? Supposed to discuss it, then – that’s the community – and tell us that, oh, don’t do this, that is boring, we don’t want to see this, or this is really helpful, this is a really great tool and please continue development of that. So basically what the RIPE Labs thing is is a form, a presentation layer to provider community. This is not meant to be a RIPE NCC stuff, or RIPE NCC tool. It’s for all the community. It’s why we call it RIPE Labs, not RIPE NCC Labs. And it’s supposed to also go beyond the RIPE region.

If you have a nice tool or something that you think we should see, all your colleagues should see, you’re welcome to bring it there as well.

This thing was launched at the October RIPE meeting. We think it’s essential for the future of the RIPE NCC. Do have a look at it. I think it’s quite a nice thing. You see all the other tools there that I mentioned, the resource explainer and Netsense and INRDB. It’s all there.

External relations and communications. For the NRO, as I said, we are working together in many things, but primarily – now “primarily” is maybe too strong, but to a very large degree in outreach, and so external relations. So as Paul Rendek is doing that at the RIPE NCC, well, you take this – your chair to to the GAC, chairing the PCG as well, you do 50 percent of your work time for the NRO, and now he works I think 200 percent, but that’s his problem.

Also we do secretarial support for the ASO this year. Well, the year is nearly over, so we are happy to pass it on for the next year. But it was quite hitting our resources, taking over some of the maintenance of the websites, doing regular minutes and all that stuff.

And strong support for the IPv6 survey. Yes. Now, was that at the RIPE meeting in Berlin? Got back from the European Commission, stood there and said we want to measure how IPv6 takeup is going, and said, yes, good luck with that. Actually, they have presented a questionnaire, a survey. We have helped them with that. We have pushed it in the RIPE, in the community, and we got over 600 responses for that. So they are quite happy; we are quite happy. And there’s some interesting results there. That whole survey was deliberately done similar to what ARIN had done before, so we tried to make it comparable. And also APNIC has done a similar survey now.

Outreach. As I said, we have regional meetings. We have regional meetings in Moscow and regularly so far. In Russia, I should say, really. And we also have regular regional meetings in the Middle Eastern region. We also do roundtables for governments and regulators. We had one on the 21st of September. It was quite popular. On the 22nd of September for the second time we had a law enforcement workshop, Law Enforcement Agencies workshop. Basically police officers from all service regions and beyond come together and try to understand what we are doing. Sometimes that works quite well. Sometimes doesn’t work so well, because…

You might have seen it; you might not have seen it: We are in the news currently, that’s RIPE NCC, for being in bed with the Russian business network and we are criminals or – I fully expect us trying to cross the border on the way out and being detained. Somebody got a little bit carried away in a public presentation saying those people there in Amsterdam, they’re assigning knowingly, I think you said more or less, resources to the bad guys. Now, we don’t do that. We don’t deal with the Russian business network at all.

We deal with our members. And new members, applications we get from a number of people. We, of course, look for the registration papers as companies. Our region is quite varied. Certainly languages. Varied staff as well. You can read quite a lot of that stuff. And company papers look reasonable. So those people become a member. If later on they turn out to be the bad guys, then of course we try to check them out again and reclaim resources. That was a little bit confusing in that presentation. So don’t be surprised when you read anything bad about us. We are the good guys still, I think. And of course I meet the guy next week in Seoul at the ICANN meeting. I’ll kick him in the shin.

Okay. We had a RIPE meeting a couple of weeks ago, two weeks ago, and this one was quite nice. Actually it was well attended. It was a lovely city. And good discussions. We had the German Army coming up and explaining why they are not the standard ISP and why they need lots of IPv6 resources. So there is increasing reach to people who would not regularly be with us. Unfortunately, at the same time, the same week, ITU decided to have their big Telecom World exhibition, or fair, in Geneva. So quite a number of RIR staff went to Geneva instead of Lisbon, and some people from the community, some staff members are also shuttled back and forth a couple of days. That was quite confusing. So we have to be at those events as well and have to put up our signs and say this is what we are doing, talk to us, we’re happy to inform you.

Upcoming meetings. Regional meeting, we have regional meeting in Beirut, and that is next week. Unfortunately next week also we have an ICANN meeting to attend in Seoul, so I won’t be in Beirut, unfortunately. I would really like to go there. And then there is RIPE 60 coming up. RIPE is going to be a pensioner really soon. 60 sounds like quite a number. That’s in May, of course, next year. And it will be in Prague. They have lovely beers there. And you’re more than welcome to attend. I hope to see you in great numbers. And if you can’t make it to Prague, after that I think we go to Rome. That is also a nice city. I don’t know about beer there, but they have wine, I think. Thank you.

John Curran: Any questions? Can you go back one slide? Is that 28th, 29th, September 2010? Or is it really in October?

Axel Pawlik: September 2009. That’s next week.

John Curran: But this is October.

Axel Pawlik: September. October. Yes, you’re right. It’s October already.

(Laughter.)

John Curran: Thank you. See? Okay. Thanks for that. Any other questions?

Axel Pawlik: You said we should give our opinions and our ideas for improvements?

John Curran: Sure.

Alex Pawlik: Now I’m quite warm, but down there I was rather cold. Can we at the next ARIN meeting have a row across at the back so the people who need to exercise a little bit to warm up?

John Curran: Big spotlights in the back to –

Axel Pawlik: Oh, that’s boring.

John Curran: Got it, Axel. Thanks.

(Applause.)

Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries

John Curran: Picking up on the policy track, we’re right on time. The next policy up for consideration is Draft Policy 2009-3, which is a Global Proposal, regarding Allocation of IPv4 Blocks to Regional Internet Registries. Originally a proposal on the 13th of January, 2009. Went to Bridgetown, Barbados, and went to ARIN XXIII. Draft Policy with staff and legal assessment is: Needs more work. Oh. Says the policy needed to be reworked. You’ll see the revised update. Current version is 14th September 2009. This is a global policy. There’s a similar one in other regions. In fact, it’s a similar one in every other region except ours, as it turns out. In AFRINIC it’s under board review; APNIC, it’s been adopted; LACNIC, it’s been adopted; RIPE NCC, it’s in discussion. Needless to say, because it’s a global policy, there’s a great question of whether or not it’s useful to have a policy that’s similar but not the same in one region as opposed to the other four. This actually has come up a number of times in other meetings. It’s possible that there’s a piece of this policy that could be adopted and still be useful as a global policy.

I’d like people not to get hung up on whether or not the words have to match exactly. Obviously if we could come to an exact alignment with the other RIRs, that would be wonderful. But even if we can’t, we want to make the policy that this region thinks is appropriate, and we’ll figure out and work with, of course, the ASO to try to figure out what to be done with this. We may have a new precedent in how we deal with global policies as a result. In terms of the comments and review, we have – whoops. Sorry.

The background on the proposal. The original global proposal requires return of address space to the IANA. So as address space is returned to an RIR, it would in turn return it to the IANA. That is the version moving forward at AFRINIC, APNIC, LACNIC and under discussion at RIPE. The ARIN version at the PPM in San Antonio required the return of address space to the IANA of legacy space and other space return was optional, to be determined by subsequent ARIN policy. After San Antonio the AC returned 2009-3 to their docket for more work. The current version says RIRs may return space to IANA, the space that’s designated for return by local RIR policy. It’s no longer an explicit requirement. This policy also contains a group of – a piece of text that addresses how IANA assigns to RIRs – its allocation policy. Each RIR may request a predetermined one-tenth of the IANA free pool every six months. So it’s a policy that talks about mandatory return of space to the RIR going to the IANA, which ARIN has changed, and then the second half of the policy, which is unchanged, addresses how IANA issues space to RIRs.

In terms of staff assessment, this version is not fatally flawed. Obviously you can read the comments to see the comments on the prior versions that required mandatory return. Staff comments. There’s a possibility of fractured /8s and some really interesting reverse DNS implications. That needs to be considered and balanced in this. And resource implementation, there would be a bit of implementation requirements to be done, which would take some time to implement. But not in surmountable; moderate level of work. The full assessment is available online at arin.net/policy/proposals/2009_3.html. It’s also in your discussion guide.

PPML discussion. 54 posts by 15 people. One in favor, five against. Extract of the comments: “We really ought to move forward. Participating in the establishment of a formal mechanism for redistributing addresses between regions is an act of good faith that we need to derail the politics here.““I oppose any policy that allows an RIR to return space to IANA in any unit smaller than IANA originally allocated it to an RIR or directly assigned it to an end-user.““The problem may – with “may” in the absence of “may not” is that the entire clause is no longer policy but a suggestion. There are better venues for suggestions than policy.”

So that completes the presentation of Allocation of IPv4 Blocks to Regional Internet Registries. I’ll have the group come up and present. Scott.

Scott Leibrand: So why are we here? Because we have a current set of global policies that define how IANA gives out space to the RIRs. Right now there is no policy for how IANA would give out space after the last five /8s are given out upon exhaustion. There is also no established policy for RIRs to exchange space amongst themselves. So what does this do? It provides that mechanism and creates a new global pool of recovered addresses that can be allocated where they’re needed, without transferring space. Obviously, if there’s more need than there is supply, there has to be some way of determining that. And that’s where the rationing comes in with the one-tenth.

As mentioned, we’ve had this up on the docket before. And we discussed it. There were a number of concerns. I believe the mandatory return was by far the biggest concern. There are some others that I’ll discuss as well. I attempted to address some of that with the compromise of legacy-only, but that only partially addressed the problem and wasn’t adequate. So we’re back. So what did we change? We revised it such that recovered space would be returned only if it is designated for return under local policies or procedures. That basically means we as a group could set a policy that says these are the blocks that should be returned, these are the ones that shouldn’t, or we could leave it to ARIN staff to return space according to their procedures.

I believe currently they have a procedure for returning /8s to the IANA that are recovered, but that may or may not be the definite policy. That may or may not change. That’s flexibility that they have. We did not change the part about the policy that defines how space returned to IANA would be redistributed. That’s still got the same one-tenth formula every six months that was in there before, and we haven’t changed that.

This is the proposal. You guys have this in your packet, so you probably can’t read it all here, but the parts that I put in bold are the parts that have changed from the original proposal given to us by the authors. There is the ‘designates space for return to IANA’ part, and specifying that what is actually returned is that designated space. There’s a minor clarification that you can keep returning space after exhaustion happens. There’s something at the bottom there that we added in San Antonio. No longer needs to be there defining legacy address space. So that’s going to come out. And the second page is the mechanism for doing that. As you can see here, we didn’t change anything.

So what about those concerns? Staff has a concern about reverse DNS implications, fractured /8s. To my mind, that is something that is currently already dealt with in a number of places in the table. The original early registration transfer stuff, basically what it comes down to is you can’t delegate a /8 anymore. Now you have to delegate all the /16s. Yes, it’s an issue. I don’t believe it’s insurmountable. There’s more general concern about should we be fracturing /8s, giving them to different RIRs and generally making things a little bit less well-contained. There’s GeoIP considerations. There’s certain things that somewhat depend on the current situation. And if space is returned to IANA and redistributed, those things will have to be changed. Again, I don’t think any of that is insurmountable. Yes, things will change.

This current policy as written here in the ARIN region would make it optional to return space. In addition to that, there are transfer policies here and in several other regions that may mean that space doesn’t actually even get returned to the RIR much less back to the IANA. So there’s a possibility that this won’t get much use. So people ask why bother, why should we add all this complexity if nothing is ever going to happen? I think the real reason for that is we might be able to say that there won’t be a ton of space given back but there will probably be some. And if we don’t have a mechanism, we don’t have a mechanism. There’s probably other concerns as well that I haven’t captured. I’d love to hear them in the discussion.

So should we move it forward and why? To my mind, the biggest reason for moving this policy forward is to avoid having space stuck in limbo at the IANA. It’s going to look really bad and it’s going to be bad for the Internet if there is space returned and IANA is sitting there unable to allocate it to the RIRs and then on to end-users.

There is a definite possibility that maybe not right after exhaustion but at some point there will be a surplus in at least one region of returned space that is no longer needed and no longer has value on any transfer market. If and when that happens, we kind of need to have a way to get that where it’s needed, if there’s still a need in other regions. This policy provides one way to do that. There’s the more general concept that all the other RIRs want to do this. We want to work with them. We want to demonstrate to other stakeholders, governance people, IT people – I don’t know who all else is involved – governments, that we are demonstrating good stewardship, that we are making sure that things are taken care of, that we’re not messing things up to a degree that someone should come in and take over. And we should be providing flexibility for ARIN and the other RIRs to do what’s needed in the future. This framework would set up a way to do that, but it would also give ARIN the flexibility to return space as was appropriate and/or future conditions which my crystal ball is not sufficient to define. So that’s the gist of it.

John, do you want to start off –

John Curran: The floor is open. The discussion of Policy Proposal 2009-3. There’s a lot of microphones. A lot of people. It should be fine. Center front microphone.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I guess I’ll break the ice on this one. I think the concepts involved here are of paramount importance. I think for a number of reasons it’s very important that we have a mechanism to get space from RIRs back to IANA should there be a surplus, because it is likely that one region will no longer need IPv4 much sooner than another region will. I also think it’s paramount that we have a way for IANA to give that space out, because stranding it will look very, very bad.

Unfortunately, both the original policy and the policy as amended I think go about this in pretty much the worst possible way. Clearly the policy here, since it is different than the other regions, creates a whole host of problems for the NRO, and I think that alone is enough to kill the policy as changed in my mind. The original policy, though, has equal problems. And I want to call attention to two areas. The first is it combines the policy for IANA to give out space to RIRs, which is truly a global policy issue and needs to be passed through all five RIRs.

With the problem of an RIR returning space to IANA, each of the five RIRs could independently decide on their own policies to do that. And there need not be any global coordination in their rules for that. And so I think it has become unnecessarily complicated by including that to try and get them all to agree on something they don’t actually have to agree on. The second thing that I think is desperately missing from this proposal is I believe there was an omission in the original IANA documents that, as far as I know, there is no requirement from IANA that RIRs use needs-based allocation to distribute the addresses. And that has come up with transfer policies in many regions, and I’ve had many disagreements with people as to whether it’s there, whether it’s implied, whether it’s not implied, enforceable, not enforceable. I think that should be addressed with clear text that no one can argue about and is unequivocally enforceable.

So I think all of this just needs to be thrown out. We need a new global policy to distribute space. The five RIRs each need to take up on their own how to return space, and that would be much simpler and easier to pass.

John Curran: So, as written, you would be opposed to this policy?

Leo Bicknell: I oppose the policy as proposed here and the original policy that we talked about.

John Curran: Okay. Microphones are open. Center front.

Owen DeLong: So I mostly agree with Leo, except that I think creating problems for the NRO by passing a different – Owen DeLong, Hurricane Electric, ARIN Advisory Council. Creating problems for the NRO isn’t such a problem. I think that this policy actually addresses most of Leo’s expressed concerns by making it up to the individual RIRs to return space as they see fit, and so I think that the clearest path forward for a policy to resolve that issue and create the bifurcation that Leo says is needed is to put this policy proposal into the process with the NRO and let the other regions either adopt this or something close to it so that there is something the NRO can hang their hat on and say there’s global consensus.

Clearly it is a bad idea for us to consent to the policy as written originally, because it does not allow us to make our own policy on how stuff gets returned, and I think that’s very necessary, especially in light of the lack of needs-based policy in some other regions and the impact that that could have on ARIN if we return space into a system that grants it to regions that don’t have a needs-based policy.

John Curran: Microphones remain open. Far microphone.

Martin Hannigan: Martin Hannigan, Akamai Technologies. I think everyone knows my opinion on this.

Thank you for your hard work, Scott. I truly appreciate you trying to get this thing through, and I believe you actually believe this is a good thing, so thank you. I am opposed to this policy. I do continue to think that it’s lipstick on a pig, plus one for Leo, for the most part. I think that one of the weakest links here is inter-RIR – well, not inter-RIR, but RIR transfer policy. I think Paul Wilson talked about the APNIC transfer policy and demonstrated that it’s a little more lax than some of the others, which it appears that they’re dealing with. I think a better approach to this would have been a global transfer policy to set some standards, and then perhaps we could work on something like this from there.

I think that it’s a problem that it applies only to legacy space. Some of the other RIRs are going to have inventory long after the rest of us aren’t. And perhaps we should consider all IPv4 address space that might be excess. And finally I think the distribution method needs improvement. We still have the problem of fulfillment disparity, where at some point where there’s, for example, 10 percent allocation to RIRs, some RIRs may get 100 percent of fulfillment of their members’ needs and others will get a fraction of that. Thank you.

John Curran: Remote.

Stacy Hughes: We have a remote participant. Joe Maimon from CHL. If ARIN is the only one who adopts this policy but with the optional return, won’t all the other RIRs cry foul? Why should any RIR want to return space if they don’t have to?

John Curran: So I’ll try to answer that. The fact that the policy says ARIN may return space and doesn’t mandate it doesn’t mean that ARIN won’t be returning space. In fact, I think if you look at – for example, if you go to look at the blocks that have been returned historically, a lot of the space that’s been returned has been from the ARIN region. But it is true there’s no – past performance is not an indicator of future performance. It just says that historically in this region we’ve returned address space. Obviously if this policy is passed, one of the things we’d need from the members is guidance if you want that to continue and under what circumstances. I don’t know if anyone else wants to speak to the question that we got from the remote member regarding why other RIRs would be interested in returning space if this policy was passed.

Scott Leibrand: Scott Leibrand again. I believe that there are two things that the global community wants to accomplish here: one is to set up a mechanism by which space can be redistributed, and the other is to provide some sort of guarantee or pressure on all the other RIRs to make sure they consider global needs, not just local needs, when deciding whether to return space. And that originally was simply a mandatory “everyone must return space and it gets divided evenly.”

I’m not sure, and maybe some of the folks from other regions or the NRO can comment on to what other regions think of this. But my impression is that at least some of the other regions would rather have the structure setup and an optional return than nothing at all. I believe that for myself that that’s the best possible outcome, given the thing we don’t want to set our own policy in stone in a way we can’t change it. So I think that this would be a step in the right direction. I think it’s a small step. I don’t think it hurts us to do it. I think that’s the biggest argument for doing it.

As far as the global process goes, I think we’ve already talked about that a little bit. But when we pass this – when we pass – if we pass this as it’s written, the other regions will have to decide whether to pass the modified version. And that will – if they all do go to the NRO so we can do it, that would be up to the other registries.

John Curran: We’ll take Paul Wilson front and center.

Paul Wilson: Paul Wilson from APNIC. I either misunderstood something Martin said before or he misunderstood something I said in my presentation. The transfer policy that’s been approved still subject to final call at APNIC requires that the recipient justify address space that they wish to receive in compliance with APNIC allocation policies.

So I think – if I understand the term “needs-based,” I think we qualify with ARIN’s expressed expectation that other RIRs adopt a definition of needs-based policy or policy – needs-based policy in compliance with an ARIN expectation.

John Curran: Okay. Cathy, go ahead.

Cathy Aronson: Paul, but after run-out, your policy does not include needs-based, or did it change? I think he’s talking about after run-out.

Paul Wilson: You’re correct, after run-out the policy is different.

John Curran: Okay. So, Martin.

Martin Hannigan: You referenced the ICANN blog, John, and some of the return that’s already happened without this policy. So if I understand that correctly, that would be 46 /8, 49 /8 and 50 /8.

And I think one of the interesting things about this policy is that it references chosen strategy, and I think that that’s what it implies is that it doesn’t – we don’t necessarily need a policy to do that. So it was kind of curious that that was referenced, and I just wanted to point that out. Thank you.

John Curran: Anyone who wishes to speak in favor of this policy or opposed to this policy, take the microphones. There’s a small chance I’ll let you folks go early to lunch, but it’s very small. Come speak about your policy proposal.

Scott Leibrand: I think one of the things that we need to get more input on, speaking as someone on the Advisory Council that’s going to have to vote on what the community consenus isfor this, is do we believe that this is something that we ought to do in order to participate in the global process in a way that allows it to continue, or do we feel that the other considerations against the proposal are something that outweigh that and that we should just go ahead and vote this down.

I don’t believe that there is a way that we can modify this proposal – at least I haven’t heard it. If someone has one, I’d like them to suggest it – in a way to make it better. So the question is between passing this as-is or not adopting it at all, in which case the whole global policy doesn’t get adopted. So I’d like to hear people’s opinions as to whether there’s a third way or whether they have an opinion between those two.

John Curran: Lixia at the far mic.

Lixia Zhang: I don’t think John is going to let us go to lunch early, so might as well take 30 seconds. Honestly, I didn’t read the policy. This is a spontaneous reaction from a different view. Because we do routing, we look at everything. There’s one fact that people may not have been aware of; that is, routing actually could make use of the fact of which /8 is allocated to which RIR for potential routing aggregations. We are still doing the measurement. I don’t have hard data to show you now. But we see evidence that, for example, a /8 allocated to APNIC, independent from how many pieces that gets chopped, there’s allocations, and after you allocate to X, X is going to further fragment. But, nevertheless, from North America to Asia, there’s only a few Xs, and that can be used to help with the routing scalability.

John Curran: Okay. Given that, would you be in favor of this proposal?

Lixia Zhang: You see a sliced /8 –I do not how much longer you’re talking about. I mean, /9, yeah, that’s okay, but you come down to /20. And now if, you know, there’s a /20 in Asia, another /20 in Africa, another /20 in Europe, that doesn’t help routing.

John Curran: Because the size of the pool that the IANA has will vary over time and the allocation units are one-tenth of that pool, there will be times when those allocation units could be quite small. It would be hard to tell. Thank you.

Lixia Zhang: So I’m not in favor, say it this way.

John Curran: Center front. Paul.

Paul Wilson: Returning to the mic again in response to Cathy there. I think, Cathy, what you’ve pointed out is a disconnect between two separate policies: one which has been approved subject to final call at APNIC, which is the transfer policy, and this one, which is still under the global process.

If you look, as I just have done, at the wording and the intent of the policy, I think what’s unclear there is the meaning of run-out and that whether or not run-out has actually been achieved, if this policy were to be adopted. So if this policy were adopted, then IANA would presumably have a pool, which will have – which may have address space in it. And while that’s the case, then run-out hasn’t been achieved. But I think that’s definitely an ambiguous issue between those two policies, the definition and the timing of run-out in the case that this global policy were to be approved.

Cathy Aronson: Right. But it’s a real concern that address space would go back under a policy which you don’t have a needs-based – at that point, where you no longer have a needs-based allocation policy, and then that would just get handed out to people who would perhaps immediately sell it.

Paul Wilson: Sorry if I’m not being clear – if there’s address space at IANA that’s being redistributed by this mechanism, then the – by the definition or the intent of definition of run-out, it hasn’t happened yet.

Cathy Aronson: So my question for you, then, is if you determine that the IANA has run out and you stop using a needs-based and then somebody gives back a /8, does that mean you immediately switch back?

Paul Wilson: This is precisely what needs to be defined. And under the intent of this policy, I’d say that if this – my own assumption would be that if this policy is approved, then we actually don’t have run-out, then we don’t reach that point of run-out in terms of the APNIC transfer policy. But that would need to be clarified.

John Curran: All depends on how that ends up being interpreted.

Cathy Aronson: That would be super helpful.

John Curran: People at the mics, center rear.

John Schnizlein: John Schnizlein. Policy adoption has implications beyond the actual allocation of address space. The perception that the RIR system of separate regions with bottom-up consensus policy building is incapable of fairly sharing resources that are in a common pool across the globe, that perception is used in arguments that I think are detrimental to the future of RIRs. Especially because it is, as Scott mentioned – one of the points has been made that there may not be much of this space to return anyway. It may be that there’s more damage done to the structure of the RIR system by worrying about the possibility that some space might move away from ARIN than is done by having any amount of space move.

John Curran: Okay. Far left microphone.

Martin Hannigan: Martin Hannigan, Akamai. Few brief points. Thank you for your explanation, Paul. I think at any point at any given time, without transfer policy being global, for example, any RIR can change their policy. So we could ratify, approve this and send it up, get it through, and the following day some RIR could make a change that had that been the state at this time we would never have done this. Second, I’m aware of the perceptions that John talks about. I think he’s referencing the ITU. I agree, we should cooperate. And I think cooperating globally is in our interests. But I think there are also reasons to expect that everybody plays on the same playing field. We’re going to need address space, and I’m speaking commercially. We’re going to need address space, both IPv4 and v6, for a long time. And I personally am concerned about the cost of that. And I think that all these different – some of the complications of this issue are going to either make it feasible to continue to operate the Internet or going to make it extremely expensive and ineffective.

John Curran: Center front. I’ll close the microphones shortly. If you wish to speak in favor or opposed to this proposal, get in queue now.

Jason Schiller: Jason Schiller, Verizon/UUNET, NRO NC. I wanted to address Paul’s question about process. Because I thought I understood it and I want to make sure I understand it, because now I’m not so sure. It seems to me that this policy, 2009-3, and the other flavors of it in other regions establish setting up an additional pool called the recovery IPv4 pool, and if and when addresses get returned to IANA they go into the recovered IPv4 pool.

It seems to me, according to 10.4, the existing policy phase of how IANA normally gives out space is done through the IANA pool. So it would seem to me if addresses get returned, prior to what we all think of as depletion, those returned addresses will not go into the IANA pool; they will go into a recovered IPv4 pool and they cannot be touched until the existing policy phase comes to a conclusion that the IANA pool becomes empty. Then we end the existing policy phase and move into the exhaustion phase where we immediately give one /8 to every RIR and the existing policy phase has concluded.

John Curran: Right.

Jason Schiller: So I’m not sure I understand the concerns that Paul was –

John Curran: What was being asked is whether or not APNIC’s policy prohibits subsequent assignment to someone who has received a transfer. This is as a result of APNIC 50, I believe, 050 Policy. So it’s actually the trigger condition in APNIC 50 on when it is that someone who has received a transfer can also – or participated in a transfer can no longer receive additional address space. That’s phrased as the exhaustion of APNIC’s IPv4 space. That’s an interpretive question. It says “until the commencement of use of the final /8.” If APNIC gets its final /8 and puts it on salt, that could be a long time. So it’s an interpretive question, depending on how they read this policy and the actual operating procedures of the APNIC.

Jason Schiller: So it’s not IANA depletion; it’s APNIC –

John Curran: It’s not IANA depletion; it’s the policy APNIC 050.

Jason Schiller: Thank you for that clarification.

John Curran: C.J.

Cathy Aronson: You need me, right?

John Curran: Yep.

Cathy Aronson: Okay. We have a remote participant. It’s really hard with this microphone. It’s Joe Maimon again from CHL. He says: I believe without mandatory return the policy is likely to have little potential harm but it also maybe useless under scarcity pressure. On the chance that voluntary return would continue, I support the policy. I would also support a policy that required return – return of returned space that exceeded the RIR 6- or 12-month supply needs. As per Martin’s concern, perhaps a distribution of returned space should factor in the RIR consumption needs. And the response to public perception, the fact that legacy plus unavailable is almost 50 percent of the pie is a fairly significant one.

John Curran: I’m closing the microphones. I’m going to give everyone their last chance to sprint to them. They’re closing in ten, nine, eight, seven, six, five, four, three, two, one. The microphones are now closed. Let’s handle the people in queue and responses to them. Go ahead, center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC.I’m just wondering if anyone involved in authoring this can elucidate on why these go into the recovered pool instead of the IANA free pool. Were we trying to create a bunch of kiddie pools? Can we just have one big adult pool? Is there a reason to have them in a separate pool?

John Curran: So I’ll actually jump in here. My name’s not on this proposal, but I was part of a drafting team which was part of drafting this that all the RIRs got together and did. And there’s a very specific allocation algorithm on how to divide evenly up the address space that’s returned. It has predictable consequences when regions have uneven draw. If two regions are drawing a lot of address space and three are drawing much slower and you’re dividing them in even chunks and passing them out in even units every six months, then there’s very predictable things that happen. So the fact of the matter is that it was designed to have a very particular effect, switching us to an even distribution over time for returned address space. There’s no way to assure that it works that way if it’s not returned to a specific pool and divided into even-sized chunks. Does that answer the question?

Okay. Center front.

Jason Schiller: Jason Schiller, NRO NC. I would urge this community that if we vote down this policy we be very clear about what we don’t like about it; that you find an AC member; that you tell them what your concerns are so that they can document that so that other regions can understand our concerns and potentially write a policy that addresses it.

John Curran: Good point. Do you want to respond?

David Farmer: Jason, by “vote down,” do you mean as written, or the original policy? Or could you clarify that just a little bit?

Jason Schiller: Yes, both.

John Curran: If there’s no policy on the docket that addresses this, then we probably need to explain to the rest of the regions, the other regions why that’s the case. Okay. That concludes our discussion. Thank you, Scott.

(Applause.)

Oh, boy. The temptation is to send you all to lunch, but we actually have to provide guidance to the AC on this policy. So we’re going to ask for a show of hands on the matter of Draft Policy 2009-3, a Global Policy. So I’m going to ask for everyone in favor and then I’m going to ask for everyone opposed. This is for everyone in the room and our remote participants. I see our tabulation machine is ready. On the matter of Draft Policy 2009-3, Allocation of IPv4 Blocks to Regional Internet Registries, a Global Proposal, if you’re in favor, raise your hand now.

(Show of hands.)

Nice and high. Nice and high. I’ll give you an hour-long break after this. Nice and high. Almost there. Raise your hands. Nice and high. Okay. Thank you. On the matter of Draft Policy 2009-3, Allocation of IPv4 Blocks to Regional Internet Registries, a Global Proposal, if you’re opposed, raise your hand now.

(Show of hands.)

Hold those hands nice and high. One hand per person. Okay. Thank you. We’re getting the remote count and tabulating them. It will be up here momentarily. I’ll tell everyone, regardless of how you voted, whether you voted, there are people who are AC members walking around. They’ll actually be at lunch. You should take an opportunity to come up and discuss this policy with them to share your insights and views, because they have a difficult job to do.

On the matter of 2009-3, a Global Proposal, number of people in the room and remote, 146. In favor, 21; against, 26.

Thank you. This will be provided to the Advisory Council for their consideration. Okay. And on this I will now move us to – it’s time for lunch. And it is an hour and a half. I was afraid we were going to be here forever. We’re actually going to be at lunch until 1:30. It’s actually a little shorter; I’m stealing some time. It’s upstairs on the second floor. Bistro. Take your valuables with you. There is no security. And I’ll see you back here in one hour and 22 minutes.

(Noon recess 12:11.)

WHOIS RESTful Web Service

John Curran: Ding. Welcome back. If everyone will get seated, we’ll get started. Hope you all enjoyed the pleasant break and lunch. We’re going to come back from our break and start off with a presentation from Andy Newton talking about our RESTful WHOIS Web Service. Andy, take it away.

Andy Newton: Good afternoon. I’m here to talk about the pilot we have called the WHOIS-RWS which is a RESTful service for WHOIS service. Probably one of the questions you might want to ask is what is REST. We’ve had people talk about REST or RESTful services. It’s a buzzword, but it’s an industry buzzword that bubbled up from the ground up. It’s kind of something that programmers have decided is a good idea, not marketing departments.So it is a buzzword. I’ll admit that. What it actually is, is it means representational state transfer. And this goes back to the dissertation from Roy Fielding, who’s one of the authors of the HTTP spec. But as applied to Web services, there’s really only two central principles around it. That is that you take the HTTP methods or verbs in the protocol and you apply them as create, read, update and delete operations on data. Standard stuff you would do with databases. The other thing is that URLs tend to address resources. So you have basically what we call addressable URLs. It’s very popular amongst people putting together services to have computers talk to each other. You’ll see Yahoo!, Google, Amazon all doing these kind of services, and they make these APIs publicly available. Amazon S3 is a really good example of this. Their big storage engine in the cloud is a RESTful service.

A little more apropos to this meeting, we are asking people to do Twittering, the clients that you might have to talk to Twitter. That’s a RESTful API there, too. So of course we didn’t just do this because it was an industry buzzword and we thought it was – we wanted to be buzzword compliant. In reality, the reason we did this was because we have a major refactoring effort going on behind the scenes back at the office, and that major refactoring effort actually touches just about every one of our systems in the back office. And what we’re doing there is we’re changing the data model to more appropriately accommodate DNS to do things for DNSSEC and proper LAME checking. So we looked around. We knew we had to do this work. We looked around to figure out how to actually deal with the WHOIS services, and one of the things we quickly discovered was that all of this work we had done for ARIN Online was actually easily adaptable to a RESTful Web Service. The software stack we had chosen for that made it easy to create a RESTful Web Service. So that’s what we decided to do. And when you have a RESTful Web Service, when you see the examples I’m going to give you, it’s far more usable than the NICNAME WHOIS port 43 service that we have, especially when you’re talking about computer programs that are trying to digest this information.

So how do you apply REST to WHOIS data? Again, I said one of the principles behind REST is you have addressable URLs. So essentially we give a URL – specific URLs to each POC, ORG, NET, ASN, basically all the first-class data members in the ARIN data model. And this provides a very easy, simple, programmatic API into the WHOIS data. Compared to what we’ve run on port 43, you end up with a lot better inputs, a lot more – much better ability to specifically target the data you might be after, and then you have a lot more meaningful array of outputs. And the other benefit is because it’s a Web Service, you get to reuse a lot of HTTP infrastructure that’s quite common in a lot of places.

I don’t want to go on about REST itself, but if you want to know more about the actual – how RESTful Web Services work in the wild, not very specific to just our implementation, O’Reilly Media has a really good book on this by Leonard Richardson and Sam Ruby. You don’t have to be a programmer to read this book and digest what’s going on there. It’s a quick read and makes the whole subject fairly understandable. It is a technical book, but you don’t have to be a hardcore programmer to grasp the concepts.

The demo is currently available. You can go to whoisrws-demo.arin.net with your Web browser. There’s documentation you can download there. There’s a Web form; you can try it out. That’s also the host actually hosting the RESTful interface. So what have we deployed here? The parts of the service we have, if you look over the box on the left, the upper left there, is the actual RESTful Web Service itself. The demo actually encompasses a little bit more than just a RESTful Web Service. But the RESTful Web Service talks to our database, the database for the server cluster, and then that is synched on a periodic basis with the actual registration database at ARIN. The box in the middle there is a NICNAME / WHOIS Port 43 Proxy that we have written. And essentially what it does it allows a WHOIS client to talk to the RESTful Web Service and get back data much like you would see with the current WHOIS protocol and WHOIS service we provide. We also have a Web form interface. In fact, if you took your browser, went to that URL I just gave you, that’s probably what you’re seeing. And what that does is that kind of emulates the search box or the text box Web interface that we have for WHOIS on our main website. But the results come back in actual XML and they get formatted using an XML style sheet. That interface, we’re going to continue to actually improve upon that and try to offer more meaningful Web form so people can say, oh, I want an IP address versus I’m looking for an ORG, that kind of stuff. If you notice that in that picture ARIN didn’t provide any clients whatsoever, and I think someone on one of the mailing lists suggested that we would. That really isn’t our focus. We might in the future, but that really isn’t our focus for the service. And the reason we wanted a RESTful Web Service is because the clients are actually readily available on your desktop. I’m sure everyone has a Web browser. So you already have a client on your desktop that can do this. And then there are also command line clients. That’s the other benefit of the RESTful Web Service. You can take a command line client and implement it into any kind of scripting you want to do.

So for the Web browsers, most modern Web browsers will do what’s called an XSL transform. XSL is just a style sheet. It’s very common. And it will take the XML output from our RESTful Web Service and transform it to however you want it to look. It can really be anything you want. It can be comma-separated values, if you want to put it into a spreadsheet, or whatever you want to do. But for Web browser you typically take XML and format it into HTML. We don’t exactly do the last step yet which is to actually include a link to our style sheet, and the reason we haven’t done that is because it required software upgrade that just hasn’t happened yet in our standard development lifecycle yet. It’s probably actually happening right now, as I speak, back at the office. But soon we’ll have that in there. If you have Firefox, Firefox will take raw XML and just do basically the pretty printing for you. It will output the XML and indent it and make it all look semi meaningful to a human being. And, of course, all the Web browsers, if you go to the website, all the Web browsers will be able to deal with the service, the Web form, where you can just put in something in the text box, similar to what you do today with our WHOIS text box on our main Web page.

Command line clients. You will find these on a lot of machines. If you have a Mac or a Linux box out there, you probably already have a slew of command line clients. If you have Windows, they’re easy to get. You can get the Cygwin utilities or specific ports for some of these programs. Two of the most popular basic HTTP programs which you can use for any type of RESTful Web Service are curl and wget. They’re very useful.Our service emits XML, so there’s some other utilities you can use, like xmllint or xsltproc. Xmllint is a pretty good tool for formatting and validating XML. And then xsltproc actually will take XML from a service and does an XSL transform on it. I’ll show examples of both of those.

Of course you can also use your NICNAME / WHOIS client. As I said, we have a port 43 proxy. You can just take any standard NICNAME WHOIS client and point it at using the host option, point it at whoisrws-demo.arin.net. And put in a search term like you’re used to doing and you’ll get output that looks very similar to what we have today. Of course you have to keep in mind that’s not a RESTful service; that’s just really a proxy into it. So you don’t get a lot of the benefits of the RESTful service. Here is an example of xmllint, as I said. Simple command line, you just say xmllint and then you hand it the URL. I gave it a format option so it would preprint the XML as it was spit back out at me and – so it’s semi-readable; otherwise it’s just a bunch – it’s all run together. But you’ll notice this – the URL I gave it, the very end of it says /poc/KOSTE-ARIN. This is the addressable URL for Mark Kosters’ POC. So /poc/poc handle, boom, you’ve got the data related to that resource. So addressable – again, addressable URLs are one of the central themes behind RESTful Web Services.

So I just went over the URL for Mark Kosters’ POC. You can do the same thing for ORGs. So you can say /org/ARIN, and that will get you the ORG information for ARIN. So it would be /org/ whatever ORG handle you want. Then you have URLs, addressable URLs that are relative to different resources. So the third URL down that you have, /org/ARIN/asns. And so what that will give you is all the ASNs related to the organization ARIN.And you keep following that pattern. We have POCs. And it works more than just ASNs. Do that against POCs and networks and so forth. We document all that in the API manual that you can download off the website.

You can do searches as well via this interface. We offer the same searches. You can do over port 43 today. So an example of searching for an ORG by name, you would actually use – the searches use this thing called a matrix URL. That’s the type of pattern you use there. But basically you just say /orgs/name=ARIN. And you’re looking for any organization whose name is ARIN. If you want to do a substream, you can put a star on there. Keep in mind if you’re using a Unix terminal or Unix shell, you need to escape that star. But one thing you can do here with these URLs that you can’t really do with a port 43 client is you can mix and match search terms. So the last URL down there. Basically I’ve given two search terms. First is equal to Mark – you know, says: /pocs/first=Mark;last=Kosters. And what I’m doing there, I’m asking for any POC where the first name is Mark and the last name is Kosters. Of course you have to do IP addresses. We would be in a world of hurt if we didn’t actually support IP addresses via this interface, since 91 percent of all our WHOIS queries are IP addresses. But it’s basically the same concept. You say /ip/v4 and the IP address. And you’ve got the network registration or the network block for that IP address. One thing we don’t do via port 43 that we do do with the RESTful Web Service is we support CIDR queries. So you can actually –

(Applause.)

Thank you. You can actually say /cidr/v4 and then put in your CIDR notation. We also support IPv6. So you can do it that way. Then you have relative CIDR queries, less or more specific. And we’re still working on some of the semantics for that. And we would appreciate any suggestions that people have. We also support doing it from IP start and IP end address as well, not just CIDR notation.

I showed you the outputs. The outputs are in XML before. We also support the JSON format, the JSON serialization format. And that’s a popular format for people doing AJAX-style Web 2.0-type websites. Very popular with people writing clients for mobile phones, that type of stuff. It basically originates from the JavaScript programming language. I mentioned the Twitter RESTful API. That doesn’t – as far as I know doesn’t use XML; it uses JSON.

But we do think XML is probably – while we support both, XML is one of our main targets for our community, basically because you can run XSL transforms against them and take that data – with very little scripting and take that data, transform it into something you need and ingest it into something like Excel or whatever provisioning system you may have. So let me – and we do provide some XSL stylesheets, which are available on the website. And those – you can use those right from our website and it will actually format the XML to look just like traditional WHOIS. Here is an example of doing that using xsltproc, which is, again, another command line client. You probably have it on your machine, especially if you have a Mac or a Unix-like box. So here we take a detailed – I mean an XSL template that we called detailed-template. Here we have an XSL template and we ask xsltproc to take that template and apply it to the URL for Mark Kosters. And instead of getting XML thrown back at the user, what you get is you get human readable output or much more human readable output that looks very much like what we see over port 43 today.

So beyond that, beyond what you can do already with the service, there’s a couple of things that we could start thinking about with such a service. And one of them is caching. We actually do reverse proxy caching on our end to help mitigate load. That’s one of our plans. We do do it, but when we go to full production, it’s a key to our plan there. But the combination of using http and having addressable URLs along with this RESTful Web Service actually makes caching very viable in this case.

So imagine, if you will, you have a security analyzer that’s taking in some sort of attack or a spam run against a network operator, and that security analyzer’s – or multiple security analyzers are constantly hitting our service asking, you know, I’ve got something from this IP address; who owns that thing. They would benefit from standing up a local Web proxy that would only – that would cache that information once so the next time a security analyzer on another node or whatever asks for that information, it comes back a lot faster. Again, it’s kind of useful, especially when you keep in mind 91 percent of all of RWhois queries are people asking for information about a single IP address.

We could do referrals. Today we have RWhois referrals on ORG records, which kind of filter down to some of the resources. But with this, and if you go to the RESTful Web Service, you’ll see we have referrals pointing back to the actual records when you do the searches. But we also in the future add referrals to the downstream to whoever holds that information. So for that particular network we can say if you want information on that particular network at that particular person’s service, go over here. And you can put that on every record if we wanted to.

So that’s something to think about. HTTP has built-in authentication. That’s another thing we can think about. Basically if you have authentication you can have tiered authorization to the data. That would allow the community to start thinking about policies centered around tiered access to the data, versus what we have today with port 43, which is kind of an all-or-nothing-type thing. And then there’s also versioning, and this is kind of important. The port 43 service, its original intent wasn’t really meant for computers to absorb that information, but we all know people have written parsers for it. And anytime we go change that output to add something or to do something inevitably is going to break someone’s parser.

So what you can do here is we go change the data model in the back end, and we want to provide a compatible version for people who have not upgraded their systems. We can actually – we can actually do versioning where if you don’t specify what version, you always get the latest. But if you’ve written something very specific to the data model we’ve published, you can get that. If we’ve made it available.

It’s not a silver bullet. Won’t get us out of every situation where we upgrade the data model, but it certainly goes a long way to help. As I said, there’s documentation. There’s a PDF on the website. It lists a lot of examples. We have the object types in there, and all the different relationships. We have a mailing list where we encourage people to give us feedback. Even if this isn’t something that you would be doing, if you ask people back at the office who deal with provisioning systems or whatever, you might want to point them at this, ask them to join the mailing list, give us feedback, what kind of queries you’d want to see or if you think we’ve done something wrong. Certainly that information would be very helpful to us.

And one more thing which this is not RESTful, but going along the lines of all that reuse of ARIN Online code, we were able to introduce a new data replication system. And what this does is unlike the current port 43 service that basically gets generated, the data gets refreshed once a day, the new service, this RESTful service, will actually get refreshed every ten minutes. So that will allow basically what people call near real-time updates.

We could actually get even faster than that as we start to deprecate some of the older technology in our system. I don’t want to go into what that is, but there’s a possibility for us to actually make that even – make those updates even faster. So feedback.

John Curran: Microphones are open. Please come up and approach the mics.

Matt Petach: Quick question. Matt Petach, Yahoo!. You showed on the RWhois page where you could do referrals. Is that doing referrals through the traditional RWhois port? Or is that doing a referral to a RESTful RWhois implementation running at the ISP?

Andy Newton: Well, it’s not RWhois. That is a RESTful Web Service returning that reference. And here I show it formatted as if you would do it like with XSL or the client is doing some sort of format on the data. In reality we’d be returning that in the serialized format, like XML or JSON.

Matt Petach: Would you be making the code available, then, to ISPs who are currently running traditional RWhois servers so they can move into this model?

Andy Newton: Are we going to make code available for – I’m not parsing that.

John Curran: Let me rephrase, Matt; I know what you’re asking. This is a referral coming from a RESTful server pointing to another RESTful server. That presumes somewhere there’s another RESTful server, which means somewhere there’s some code running. How does an ISP set up a RESTful WHOIS server?

Andy Newton: We don’t really have to provide code, because these are addressable URLs. You could actually create just flat files representing these URLs on any commodity Web server you would want to do this. Also, keep in mind I put this as “the future enabled.” We don’t actually do this today. We don’t have those referrals pointing down yet. That’s something that – our first – our primary motivation here is to actually get all the functionality that we currently have into the service. So this is something to think about.

Matt Petach: Looks great. I’ll keep my fingers crossed for next October. Thank you.

John Curran: Mark, do you want to respond to that?

Mark Kosters: We’d like to hear feedback on this. If this is something that seems to be, hey, this is a much better thing than WHOIS and RWhois, let’s go to this model, then I think we should talk about commissioning some sort of open source software project, bundle all these things together.

John Curran: Okay. R.S.

Rob Seastrom: Rob Seastrom, Afilias and ARIN AC. This is good and really cool. I’m going to be a little old school here and focus on the cachability thing, because I think it’s going to be useful to people who run blacklists and stuff.It’s not just the addressable URL that makes it cacheable; it’s also stuff like max-age and If-Modified-Since. And does it currently support IMS?

Andy Newton: IMS?

Rob Seastrom: If-Modified-Since.

Andy Newton: Oh, oh, oh. So you’re talking about headers, the caching headers.

Rob Seastrom: Yeah. The ability to see if the data has changed, which sounds to me like possibly a nontrivial thing you graft on underneath.

Andy Newton: That can get complicated really fast, so we punted and didn’t do anything. I will point out that you can assign your own local policy to that kind of stuff. So we set up on our end as an exercise and also to help mitigate load just an Apache Web server running mod_proxy – or mod_mem_cache and mod _proxy. And we were able to run our own policies on how long that data gets cached.

For us to go in and put other cache headers in, we’d have to look at the implications of how often the data is being refreshed and so forth to be able to tell you whether it’s different or new or anything like that. I think, in my opinion, and I’d certainly welcome feedback on this, people really ought to think about their own local policy first. That’s why we didn’t put the cache headers in.

Rob Seastrom: I’m saying it makes things easier for people if you want to encourage caching, which is something you probably do.

Andy Newton: I don’t know what – I don’t know what people who have a lot more experience with this, but the caching itself, we looked at that. And, like I said, it can get complicated pretty fast. So we basically did nothing and assumed there would be local policy to control that.

Rob Seastrom: Thanks.

John Curran: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, Advisory Council. A couple of comments on this. There was a lot of talk on the iChat channel looking for – or AIM Conference, or whatever you want to call it, looking for text output instead of just PDF and doc. There were some negative comments about the fact that you’d chosen to provide it in a proprietary format, but not as many as there were comments that said that we want text. There are a lot of tools that depend on the port 43 functionality and will take not insubstantial amounts of changes to get that done to move over to this RESTful service. CIDR queries on RESTful good. Lack of CIDR queries on port 43, still bad.

Andy Newton: Let me address that. The PDF and doc format is really an artifact of how we wrote the documentation first internally. And basically we have a tool called Confluence which exports it out. It’s a wiki. That’s what we used to create that documentation. Going forward we’ll find some other way of doing it. It is kind of difficult to find a format that’s appealing to everybody more than one type of format such as PDF or HTML or whatnot. We might try to find something else for that.

John Curran: With respect to port 43, no one is standing up here saying we’re getting rid of WHOIS. This is not that presentation. I will save that for Andy or Mark a few years down the road, five, ten, whatever, but that’s not this presentation.

Owen DeLong: Just to clarify what I said. I didn’t accuse you of getting rid of WHOIS; I accused you of failing to bring CIDR functionality to WHOIS.

Andy Newton: I’ll address that, too. The current service doesn’t provide that, and the reason is – we looked at it, and the parsing that goes on currently today on port 43 is nontrivial, to say the least, because what happens on port 43 is you can enter a query and it actually hits a whole bunch of things, sometimes not just what you’re asking for, which is actually one of the benefits of the RESTful Web Service. It was very simple for us to add this into the RESTful Web Service because we don’t have to deal with parsing logic at that point. That’s why we haven’t ported that over.

Owen DeLong: Not to draw this out, but talk to the other RIRs; ARIN is the only Internet registry that doesn’t support CIDR queries on port 43.

John Curran: Yes.

Paul Andersen: Ted Mittelstaedt, Internet Partners, Inc., writes: Comments in response to the query regarding making RESTful WHOIS code available. Please keep in mind that currently the policy manual only permits ISPs to substitute running their own RWhois server instead of filling in individuals SWIPs into the ARIN WHOIS server. The NRPM needs to be changed to add a RESTful HTTP server as permitted alternative to SWIPs before any of the RESTful code that ARIN is writing would be usable by ISPs.

John Curran: Good observation. Center front microphone.

David Williamson: David Williamson, Tellme Networks. Thank you for CIDR queries finally; it’s very much appreciated.

There’s been comments about output formats and you mentioned briefly trying to find the one output format for everybody was hard. I don’t think one output is a good idea. I think any easily created output format would be great. I’d love to have a text version, I’d love to have an XML version, PDF, doc, whatever. If it’s easy to create and not a lot of overhead to store, make it.

Andy Newton: And are you talking about the output –

John Curran: Are you referring to documentation or code output?

David: Code output.

Andy Newton: So we chose XML and JSON specifically because the stack supports that out of the box. We did, honestly, no extra coding to get JSON once we had the XML support. Text is a little more difficult to do because you have different formatting rules. However, it’s easy with an XSL stylesheet, and we provide those things to transform XML into text or CSV or whatever you want. The problem with us supporting multiple formats as we go down the road, it’s nice, but that means every time we find a bug in one place we have to go fix it in multiple places. It’s not code that’s – it leads to a lot of maintenance issues.

David Williamson: Sure. I’m just encouraging as resources are available more output format is good, and text is probably the first one I would prioritize.

John Curran: Okay. Microphones remain open. Far right mic.

Steve Woodrow: Steve Woodrow, MIT. So first off, thank you, especially for the CIDR blocks. And my second question was: Is this service going to be rate limited at all? And, if so, are there going to be different rates for good guys versus bad guys?

Andy Newton: We don’t have rate limiting turned on. At the moment we do have query or result limits turned on, and the reason we did it was just because we wanted to put that in the code and make sure it worked. The current WHOIS service does do some query result limiting, not to the extent that the RESTful Web Service is doing it.

We’re actually looking at that trying to figure out where it’s appropriate and where it’s not appropriate. There are places where result limiting isn’t appropriate. And so we need to go back and verify what we’ve done is actually the right thing we should do there. As far as rate limiting goes, we don’t have any of that going on today, and we don’t have any way yet to determine who is good and who is bad.

Mark Kosters: If I could add on to that, this is a pilot service. By that I mean this is not production-ready quality code. It will at times go down. So if this is something that the community really likes, and we’re throwing this out to the community to say is this useful, then we’ll work on making it production-quality service and those sort of issues would be addressed.

John Curran: Okay. Center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. My sanity and zero key are both curious if you support colon-colon notation in IPv6 addresses in this.

Andy Newton: I would have to check, but I believe we do. We actually just reused the library that both comes with the software stack and the add-on utilities that we wrote for ARIN Online, which I believe do support colon-colon. But if it doesn’t, please let us know.

John Curran: Any other questions? Seeing no other questions. Thank you, Andy.

(Applause.)

Draft Policy 2009-8: Equitable IPv4 Run-Out

John Curran: Going back into our policy section of the meeting, we have Draft Policy 2009-8: Equitable IPv4 Run-Out. Okay. History of this policy proposal: Original proposal from Policy Proposals 93 and 94 from the 8th of June this year. It was made into Draft Policy on the 31st of August. Similar topics are adopted in LACNIC and under discussion in all the regions. AC shepherds are Leo Bicknell and David Farmer. Summary: Slows distribution of IPv4 space. The goal here is to change policies for ISPs who have been members more than one year. These ISPs can currently request a 12-month supply. When IANA depletes to 20 /8s, those ISPs can request a six-month supply of address space. That’s their new limit. When the IANA free pool hits ten /8s, the supply period is reduced to three months. So this causes people to get less address space and make more frequent requests. When ARIN gets its final /8, the maximum prefix size for all requests would be one-fourth of ARIN’s free pool, rounded down to the nearest CIDR prefix. Once we’re on the last /8, it would be one quarter of whatever our free pool is. Legal assessment: ARIN has the legal duty and authority to establish more restrictive rules to ration the issuance of IPv4 resources as the scarcity of such resources increases. However, such rules must make clear rational sense given current circumstances and may be tested by litigation by disappointed parties at a time when they come fully into effect, not when adopted.Therefore, the proposed policy here will need to be carefully reviewed and, if passed, carefully implemented, for example, to prevent any side effect that would inadvertently favor one set of ISPs over another.

Staff comments or concerns: “The maximum prefix size as calculated might not be available as a single prefix.” “Timing issue. You could see a /18 on ARIN’s site and request same. But it might be a /19 by the time the request is processed.” So even if you know what the free pool and the allocation size is, it could change very rapidly.

Resource impact: Minimal. PPML discussion. Four posts by two people. None in favor. None against. Earlier discussion of this, 76 posts by 17 people when these proposals were first submitted. “Will minimum prefix size be reduced over time? Someone who gets a /22 for their 12-month needs, what do they get for three months?” Suggestion to merge policy – the proposal texts and wordsmithing requirements. So that’s the policy introduction, and then I’ll turn it over to Dave Farmer to give the AC presentation for it.

David Farmer: So Leo and I are the shepherds on this, as was said. I’ll start out with what the goals are. As it says, equitable distribution of the remaining IPv4 resources. The idea, okay, what do you mean by equitable. Basically to ensure multiple organizations have an opportunity to receive resources. That no one big, you know, they all go at once or anything like that. Try to keep as many people getting resources as we can. Reduce disparity of IPv4 resources availability between competitive entities. The idea here is that if you’re an ISP and your competitor got a year’s worth five minutes before you came and the pool was empty when you came and you get zero, that’s a huge disparity in the competition and will probably create issues. Those issues will cause people to ask ARIN to take account for itself. And we’re going to need to demonstrate due diligence when that happens. That will be in the courts. I’m sure politicians will be asking questions. I’m sure the press will. And the general public probably, too, when they hear the press say: Oh, the Internet’s come to an end. So reduce the chance that IPv4 run-out leads to instability in the Internet and an artificial competitive advantage. That same thing that we were talking about. You can’t eliminate them. This is going to happen. But we can try to minimize the impacts.

Basically another way to put this: We want to avoid a Friday night massacre. Remember what happened with Lehman Brothers. All of a sudden on Monday morning we heard that on Friday something really bad happened and, well, we want to avoid that. We don’t want somebody coming with a large allocation request on Friday and all of a sudden we all wake up on Monday and find out ARIN has no more addresses. This is not intended to extend the life of IPv4 resources. I don’t think this extends them at all. If ARIN has a large amount of IPv4 resources, you can still get a large amount of resources. If they don’t have a lot, you’re not going to get a lot. But how is that any different? Okay. Policy statement. It’s really kind of two parts. The first half as was shown before reduces the length of supply from 12 months down to six and then three based on whether it was 20 or 10 unallocated – excuse me – /8s in the pool with IANA. The second half creates a maximum allocation size when ARIN receives its last /8 that’s one quarter of the free pool. There’s a maximum of one maximum allocation every three months per OrgID. There’s a bunch of details in how that’s worded so that people don’t game it that I thanked staff for helping me with.

So the cons. In the second half the maximum allocation size will decrease over time and accelerate toward the end. This is kind of what staff was talking about. I suggested in the rationale that it be published. But in a way this isn’t any different than if we leave the policy the way it is. It’s going to get smaller and smaller and smaller, and if you request something big, you may or may not get it. At least you have some data to help you judge your thing now, what you think the odds are. The current text may have the triggers too soon. We’ll talk about that in a little bit more, in another slide here. This is going to cause some additional deaggregation because we’re not giving out a year’s worth at a time. It may cause some additional work for particularly the larger resource consumers. They’re going to have to come back multiple times. But if things decrease, if the pool rapidly goes away, they might not. If it goes away in three months, there’s not going to be anything for them to come back for anyway. So it will likely cause a little bit more. But there’s a lot of uncertainty here, and we’re trying to deal with some of that. So, as I said, we might want to tweak the triggers a little bit. I’d kind of like John to ask maybe this as a change if people are – I’ll let him figure out how to ask the question. But it’s looking like – from looking over John’s shoulder on the projections – that the current triggers might be actually triggering things a little bit sooner than we really want them to.

So this is a proposed possible change, basically to change – instead of at 10 unallocated /8s, instead of dropping down to three, then drop down to six then and not do drop down to three until we get – ARIN gets its last /8. And so that would move us a little closer. This is also in – I also heard some comments from other folks that they were a little concerned with this first part being triggered on the IANA pool and ARIN has very little control over the IANA pool and probably isn’t the biggest driver on exhaustion of the IANA pool either, so should we be tying our policy to this was the question. And I think this deals with it a little bit. It’s kind of hard not to – if somebody’s got a better trigger, I’d love it. But it’s the only trigger that we’ve got. One small editorial note. Staff recommended that we change the “twelve month” title for the – of the part that we’re manipulating to “subscriber members after one year,” which sounded good to me and threw it in.

After reading through it all, there’s another part that we’re not actually changing but had a similar title that’s right next to it and we’re considering changing its title. I think this is much more consistent, and it actually adds quite a bit of clarity to what – I never quite understood what the “twelve month” and “three month” title in this section was trying to get at. So I believe this helps. And unless somebody objects wildly, I think the AC will just throw this in. And that’s it.

John Curran: The floor is open for questions, comments. Please remember to identify yourself, say whether you’re in support of the policy or against the policy, and your comment. Far left microphone.

Mart tin Hannigan: Martin Hannigan, Akamai. I wildly object, and here’s why: As we saw in some other policies, the distribution method here needs improvement. We still have the problem of fulfillment disparity. Others will fill 100 percent of their existing needs based on their size, and the larger ones will fill a much smaller need. I think that that’s patently unfair, and I would support this if the fix – well, let me suggest the fix instead of just being opposed. So I’m opposed as written. I think the fix would be to somehow incorporate percentages instead of actual allocation sizes. So, for example, if I come to the well and I have a need, I can fulfill 10 percent of my need and my competitor or my colleague can fill 10 percent of his need as well. Thank you.

John Curran: Center front microphone.

Igor Gashinsky: Igor with Yahoo. How does this affect the transfer policy?

David Farmer: It explicitly does not. It’s probably an omission of mine on the slides. Both of these explicitly exempt – this has nothing to do with the transfer policy. It only has to do with resources allocated from ARIN’s free pool.

Igor Gashinsky: So the justification for the transfer policy will not be affected by that?

David Farmer: Justification doesn’t change. Nothing changes. This is just how much you can get out of the ARIN free pool when those things happen, and you can still get – you can still justify for a year. It’s just when these go into effect, you can’t get a year out of the ARIN free pool.

John Curran: Center rear mic.

Stacy Hughes: I oppose this policy. I oppose any policy that would seek to throttle back either allocation window or allocation size. We cannot behave as five-year-olds at the park – five more minutes, five more minutes. The party is over.

David Farmer: Don’t run away. I want to respond to that.

I don’t believe this is five more minutes. I believe this is recognizing that the party is going to be over and we need to have the rules of equity change as we get to the end. Because the lawyers and everybody else is going to say, hey, but wait a minute. And so ARIN has to – we have to be able to tell people what we did about it. And it’s not trying to conserve resources. I don’t see how this conserves resources at all.

John Curran: You’re effectively saying the party’s over but we have to divide the last sixpack; you just can’t take it out to your car.

David Farmer: Yeah.

John Curran: Right microphone. Sorry. Do you want to respond?

Stacy Hughes: I would like to respond. If a large ISP comes for the last /8 and they need it and can justify it, they should have it.

David Farmer: What about the large ISP that comes five minutes after them?

Stacy Hughes: Bummer. Buy it.

John Curran: Far right microphone.

John Schnizlein: John Schnizlein. Having watched the evolution and the competing approaches within ARIN and in other RIRs, I want to congratulate you on having cleaved the baby cleanly. So I support your attempt to avoid bad hurts right at the bitter end. I think the second half, which comes into effect only when the address space is exclusively in your control, in ARIN’s control, is a reasonable exponential breaking on the runaway train before it hits the brick wall. I appreciate that you’ve raised the point of cutting back the earlier phase from two stages, one of which would happen pretty soon now since if we’re at 26 /8s, we’ll reach 20 pretty quickly, but we don’t know quite when. I think cutting it back is a good idea. I would question whether it’s necessary at all. It may be that having that early slowing provokes exactly the kind of concern you just heard, and I think it does so unnecessarily.

John Curran: Would you be in favor of the proposal as it is?

John Schnizlein: Yes. It’s better than nothing as it is. I would prefer that it only contain the second half. The one quarter is as big a bite as you can take when that’s all the pizza there’s left in the room.

John Curran: Got it. Okay.

David Farmer: I discussed this a bit with Leo. Leo, you can defend that better than I can, if you don’t mind. Go ahead, Leo.

Leo Bicknell: Certainly the place we started approaching this was the case that if there is no wind-down policy at all, there will be ISPs large and small who get address space literally on the last day and the guy who sent his e-mail in after lunch because he was busy doesn’t get any. And our policy would make that a 12-month disparity. Because we’re giving them a year’s supply. The thing that we recognize, though, is if you just received your last 12 months, and I’m assuming it was justified in good faith with how we do things, you might also be then incentivized to be somewhat more restrictive, somewhat more picky in which customers you give them to or how. And 12 months of supply may actually, because of that, be more like 18 months or 24 months of supply. So potentially you have a situation, if we just let things hit the brick wall, which generally I’ve been a fan of, of two ISPs of similar size serving the same customer base, where one has space for 18 to 24 months after another one, due essentially to the totally random factor of when you send an e-mail. And so we were trying to find the least-intrusive policy way to reduce that window. And that generated the two ideas that we put on PPML: the original discussion and then eventually this.

The one other minor point I wanted to add, because it didn’t come up in the presentation: ARIN already has a policy, which number I forget, that when the last /8 is given to ARIN, a /10 of it is set aside which is one-fourth. So there is, in fact, only three quarter-sized chunks, which is the maximum you can get to fight over. So potentially, even with this policy, three ISPs could take that last /8 a quarter chunk at a time.

John Curran: Okay. Someone at the head table. R.S.

Rob Seastrom: Rob Seastrom, Afilias and ARIN Council. Could you flip back to the court of public opinion and what we’re going to say when they – yes. So the flip side of this is that one of the unintended side effects of anything like this, and I’m not sure how we can fix it, is that it will be perceived particularly in the press as having done something to fix or make the run-out go better or more smoothly or, oh, there’s a future in IPv4 addressing. And I think that’s a bad thing. And it dilutes our message that we need to – if your business requires IP addresses to run and a stream of new ones to run, then your future is in IPv6, not in IPv4. And while that is not enough on its own, taken alone, for me to decide that I’m going to just oppose this policy proposal on principle, it gives me serious pause. And I don’t know – I’m not sure that any level of disclaimer or, no, we’re not doing this is going to fix this in terms of public perception.

John Curran: I’d like to respond. I will say ARIN actually has a PR firm retained. We use them on occasion. And we generally don’t do press releases or Q&A or interviews along with policy adoption. Life is short. That would get kind of busy. On the other hand, for something like this, we could specifically preempt and do the briefing in advance and even take those people who might cover it and tell them in advance what the right answer is. And, generally, if you put a program like that in place, you can limit. Limit. Not control, but you can limit the misunderstanding.

Rob Seastrom: So do I have your commitment you’ll do that if we pass this?

John Curran: Yes.

Rob Seastrom: Thank you.

John Curran: So, we’ve got far right microphone. I’ll go with center, then far right, then far left and center.

Mark Willson: Mark Willson, Uncommon Technology. I guess as it’s currently written I’m against the policy. Two comments. Number one is the final trigger, the very last allocation. Instead of waiting for the random when we send in e-mails and how that kind of buffers out, maybe we should take kind of a poker approach where you look at what the last year’s allocations were for people and divide up the last of the IPs with one shot: everybody gets a percentage of the pool based on those numbers so that everybody has a little bit of IP address to deal with instead of running in flat. Second comment is that what will probably happen after the IPs run out is we’re going to see a little industry consolidation. Basically companies that are running short of IPs will basically go after companies that seem to have an excess of IPs, especially on the smaller end of the market.Companies will deliberately go out and pick up smaller ISPs to get their blocks, if that becomes an asset and IPv6 hasn’t entered into the picture significantly. That’s it.

John Curran: Thank you. As written, you’d be against this policy?

Mark Willson: Yes.

John Curran: Far right.

Chris Morrow: Chris Morrow, Google. I have a concern – first of all, I don’t support the policy, to get it out of the way in the beginning. I’m concerned about some of the wording. IP addressing has never been about equity; it’s been about need. So the word “equity” doesn’t really figure in at all to this conversation as near as I can tell. And, secondly, there’s always going to be somebody who comes in like after the last block is given out. So are you trying to protect against that? There’s always going to be someone who loses.

David Farmer: There’s always going to be someone that loses. And, like I said, we can’t – the wall is coming. The idea here is trying to not hit the wall at supersonic speed, I guess.

Chris Morrow: Too late.

David Farmer: I don’t think we’re going to hit the wall at – I think we can not hit the wall at supersonic speed.

John Curran: Remote participants, go ahead.

Paul Andersen: Comment from Ted Mittelstaedt, Internet Partners, Inc.: We are in favor of this policy, although we actually feel this policy is not going to significantly affect things at our end. And here is why. The organizations who are smart won’t be at the Friday night party. They will have moved on to IPv6. The large organizations who are stupid because they haven’t transitioned to IPv6 by then will be gaming the system anyway and generating bogus need to justify a huge allocation request won’t be beyond their ability. Organizations that need, for example, a /17 will just generate up a request for a /15. People need to keep in mind that the Friday night party will be a gigantic mess of procrastinators, desperate to ring the last very bit of usability out of the IPv4 infrastructure, none of whom has any horse sense and probably almost all of whom will be out of business six months later. In short, this policy is harmless and its biggest value is to scrape the lawyers and politicians off our back with justification that we are actually doing something about the crisis who think that IPv6 isn’t the answer.

John Curran: Okay. Got it. Far left side.

Matt Pounsett: Matt Pounsett, Afilias. I’m in agreement with some of these people saying this is not being the way to go. I’m against this policy. I think the due diligence here is not trying to soften the blow. Due diligence is getting people to move on. I think that’s the real way to soften the blow here. Whether it’s intentional or not, this policy will give the impression that we’re trying to make IPv4 last longer, because, well, that’s actually what it does. The whole second section of handing out one quarter to the remaining ARIN free pool means that we are essentially extending the life of the ARIN free pool to infinity. We’ll be essentially handing out /30s the way it’s written.

David Farmer: I didn’t give the details, but at minimum allocation, once the pool is down to the minimum allocation, the maximum allocation meets minimum allocation, we give out the minimum allocation.

Matt Pounsett: The policy text doesn’t say that.

David Farmer: Yes, it does.

Matt Pounsett: No, I just went and read it, and the policy text that’s up on the website does not indicate a minimum allocation.

John Curran: We’ll take a look at that. And, as written, you are against the policy; you don’t think it’s worth it?

Matt Pounsett: That’s right. I think it does more harm than good.

John Curran: Rear microphone center.

Scott Leibrand: Scott Leibrand, Internap ARIN AC. I support the policy. I believe the concern that we shouldn’t be giving the impression that we’re fixing things kind of means that we shouldn’t fix things, and that doesn’t quite make any sense to me. I think that the concern that we are unfairly impacting the person that only gets one-fourth of what’s left instead of all of what’s left is – that doesn’t hold water with me either. It seems like if you’re that far down that it’s not a big deal to only get one-fourth of what’s left. I mean, that’s one-fourth of what’s left. So I think we’re in a situation here that what we’re doing is trying to heed off perceived unfairness.

To Chris’s comment about this being all about need, it won’t be all about need because there will be more need than there will be supply. And that’s why we are taking this action, transfer market and lots of things, is to address the concern that, well, what do we do when there’s more need than there is supply. If we don’t define that, current policy holds. And I believe that current policy, as David said, is going to result in lots of other people thinking we should do something about this. If ARIN has already decided what we ought to do about it, we should make that decision and head off the other people trying to take it over.

John Curran: Okay. Remote participant.

Paul Andersen: Joe Maimon from CHL writes: I support this policy. I think that a scenario described where all scarce resources are cleaned out by one or a few big players could be the final black eye for the RIR system in the eyes of many. It may even create a prime time news sound bite. I do not believe this policy is the be-all and end-all, but I do not believe that policies should address potential gaming. ARIN staff is responsible always for detecting and preventing gaming.

John Curran: Center front.

Cathy Aronson: Cathy Aronson, ARIN AC. I don’t entirely think this is incredibly likely, but what if the wall moves? Okay. So – or we hit it and then someone gives back a big block of address space, then there’s no – none of these policies have any – we were talking about it earlier – any sort of mechanism for if all of a sudden there’s more address space.

David Farmer: This policy, if all of a sudden ten /8s came back, this doesn’t deal with that situation. But that’s so incredibly unlikely. At least in the time frame we’re talking about here. In the rationale and the way the text is written, if ARIN gets back a sufficiently large amount of address space that would change the quarter – and it’s a quarter of what’s there when you go to make the allocation. So if a /8 came back, all of a sudden the minimum – the maximum allocation size would jump up again.

John Curran: Cathy, based on the fact that it doesn’t handle the many /8s coming back, would you be against the policy proposal?

Cathy Aronson: You know, I’m not entirely sure. I mean, the AC likes to hear the community input, and I’m asking this question in order to get that. So I’m not –

John Curran: Got it. Rear microphone.

Chris Grundemann: Chris Grundemann. I support this policy. I want to address a couple of things. One, I think Martin left, but to his point about the competitor being able to get a different percentage of their need compared to him, the whole step-down was exactly to avoid that. That’s why it’s time-based. So right now you’re getting a 12-month supply, then it steps down to a six-month supply, then three-month supply. So you’re getting 100 percent of your six-month needs, and so is everybody else. That’s very equitable. And then once there’s only one /8 left, then it drops in and you start getting where a smaller organization is going to get more of their need than a big organization.

But I think that actually promotes the adoption of IPv6 especially by the big players who are the guys who probably should be doing it or are doing it because they have the money and talent to do it now and get ahead of the game with IPv6. So I think this policy actually sends a message that IPv4, you’re going to be able to get less and less and less of it even before it’s gone, so you need to look at something else now. I think it sends the opposite message everyone thinks. There’s the same number of addresses, no matter how you hand them out. The same number of users are going to get online no matter how you hand them out and they’re going to be used up just as fast no matter how you hand them out.

It’s just a matter of how many organizations get them and how the needs are met across the community, and I think this makes it much more equitable. Especially the other consideration is new entrants. This allows a small startup ISP to come into the game and get some IPv4 right up to the end, whereas if a big guy takes a /8, that doesn’t happen.

John Curran: Thank you. Far left microphone.

Robert Duncan: Robert Duncan, Merit Network. A couple of observations. We’re not pointing out that this is really more of a CYA for ARIN. Because this policy is only going to affect the terminally stupid, right? Anyone whose business depends on IP addresses already sees this and isn’t going to let their business be affected by this. If they come so late that, gee, we didn’t think about IP addresses for our five-year business plan, they’re terminally stupid. The other thing to equate this to as far as the courts, politics, press, that sort of thing, there’s certainly precedence in the fishing industry, say, for seeing resources being depleted, something being applied to control it, everyone gets uniformly legislated against it. It’s not that much of an issue. And I do believe that it really does have to account for an interaction with the 09-3, for instance. If address space comes back, it better be stipulated in this policy what’s going to happen with the address space that comes back and not just say, oh, well, of course we’ll do the right thing.

John Curran: Given that, as it’s written, would you still support it as it is right now?

Robert Duncan: Yes, I would.

John Curran: Okay. Thank you. I’m going to be closing the microphones shortly. If you want to speak on the proposal, approach a microphone. Far right microphone.

Alex Castelo: Alex Castelo, CableOne. I’d like to request in our vote that possibly a show of hands also be made for support of the – to gauge interest or support of the policy with the adjusted triggers.

John Curran: Understood. Microphones are going to close shortly. Leo.

Leo Bicknell: Certainly if someone has a comment on the trigger – that was one of the things I was going to say. I want to be sure we discuss the alternate triggers of ten and at the last /8, because that was big in the hall and hasn’t been discussed and I know it needs to be asked.

The other question I wanted to ask was a follow-up to an earlier commenter, which is why I’m back up here. He described the scenario – I forget who; sorry I forgot your name – where an ISP who received resources very late in the game, you know, the last day, whatever you want it to be, might become an acquisition target for someone who was not so fortunate. And indeed I think that scenario is plausible. And it was one of the main reasons why we started looking at ways that ARIN policy would not encourage that. And the commenter seemed to suggest that was a bad thing, at least that’s the impression I got, but was also against the policy, which I find slightly confusing. So I’d like a little more feedback on that sort of area if that commenter or others would like to say something about it.

John Curran: Okay. Specifically on what question do you want feedback on?

Leo Bicknell: How allowing someone to be an acquisition target for their IPs is sort of a good thing.

John Curran: Do you want to respond?

Chris Grundemann: I’m not saying it’s a good thing; I’m just saying it will happen, that’s all. It’s neither good nor bad.

Leo Bicknell: This policy should reduce both the likelihood of that occurring and the magnitude of that occurring, should it not? Because that entity will end up with a much smaller amount of IP space. Instead of a 12-month supply they’ll get a three-month supply.

Chris Grundemann: True. I was actually more considering normally when you’re in a small business, you’re in the startup mode or you haven’t been around for a particularly long period of time, one of the easiest ways to increase your bottom line and your flexibility is to buy up competitors and you buy up – especially buy clients and you don’t pay for the overhead. You can throw away the overhead and so it’s a good thing. What you’re going to see is consolidation, where you take a whole bunch of small ISPs, which are ones that are pretty much, you know, garage kind of operations, and they just start slamming together because they can’t get critical mass at the size they are.

David Farmer: The intent here is that that’s going to happen. That’s always happened, always will happen. What we want to try to avoid is IPv4 run-out somehow tripling or quadrupling those things happening and creating an artificial level of that stuff happening. Because that will cause a market disruption and people will be yelling at us. More than even just the fact that we’re running out of addresses.

Chris Grundemann: You’re going to have some of that anyway just because the rarefied IP addresses become a value in the formula.

John Curran: The question is, I guess, the statement is hopefully this policy reduces the possibility of someone sitting out there getting address block and becoming –

David Farmer: Solely for that purpose.

John Curran: Solely for that purpose by being the last one through the door.

Chris Grundemann: Could be. You have pretty much one shot at it, so trying to pick perfect timing.

John Curran: I’m going to be closing the microphones. If you want to speak on this, please approach a microphone immediately. Remote participant.

Paul Andersen: One comment from Ted Mittelstaedt of Internet Partners, Inc.: Regarding what if the wall moves, it must be absolutely understood that once IPv6 is in gear there will be an oversupply of IPv4. IPv4 will be returned by the truckload. It is just that it will be worthless. So hypothetical situations like wall moving are going to be addressed by future policy proposal modifications. IPv4 will likely never completely go away from the Internet, just like thinnet Ethernet still exists here and there, and at some point the NRPM will have to be modified to allow for a maintenance mode of IPv4.

And Joe Maimon has asked for a show of hands whether anything should be done at all or absolutely nothing should be changed.

John Curran: Thank you. Far left.

Dave Barger: Dave Barger with AT&T. I’m opposed to this policy not because we’re AT&T and we’ve automated our ARIN ISP request and we can send e-mails really quickly, but I’m opposed just because of the perception of this, and it’s already been touched on a few times, where if a policy like this is put into place, essentially we’re almost sending a message to the world that we’re extending the life of IPv4 and it’s extending out to we don’t know when. And getting back to a couple of comments I made yesterday, looking at Geoff Huston’s statistics, for example, what are those going to look like? I mean, if they say 2012 right now, are they going to jump out to 2013 just because there is this small amount of resources still available but it is available. And the concern I have and the problem I have, quite frankly, within my company is we have drawn a line in the sand for IPv6 readiness. And we are constantly being pushed by the financial people, the planners, the people controlling the purse strings and the budgets saying can we push this out another six months or another year, because we’re already spending $150 million and so on and so forth.

So, to me, this gives those people an opportunity to continue to push and say can we move our projects out, and we need to be sending a message I think that says this stuff is going to run out and it’s going to run out soon so we need to stay on plan to get our IPv6 done.

John Curran: Got it. Thank you. I’m closing the microphones. Microphones are closed.

David Farmer: Yeah, there’s a perception problem. But there’s going to be an equally bad, if not worse, perception problem when we’ve run out and the perception is we did nothing, we didn’t even make sure it was handed out fairly. There’s some really nasty consequences – there’s some really nasty possibilities here, and the current policy says if you’re a big consumer you can take the last big chunk. There are going to be a bunch of people that that catches completely by surprise. Should it? No, but it will. And they will cry foul and they will be hauling Mr. Curran in front of Congress.

John Curran: That happens either way.

David Farmer: Yeah, but at least we can say on that day we did something.

John Curran: Microphones are closed. Back rear microphone.

Scott Leibrand: Two comments. First off, in regard to Leo’s question –

John Curran: Who?

Scott Leibrand: Scott Leibrand, sorry, Internap, ARIN AC. In response to Leo’s question regarding should we change the thresholds, one thing to keep in mind is that the first threshold takes us back where we were a year ago having a six-month allocation window. It wasn’t that bad a year ago. The only reason we changed it is to be the same as everybody else. That was kind of silly. But if we have a good reason for changing it, changing it back is not going to be a big deal. If we want to wait, that’s okay, too. I’m not too concerned either way, but I don’t think that should be a reason for anyone to oppose this. I’ve heard lots of better reasons in this room.

With regard to the comment that anyone who is still at the party is an idiot for not having done IPv6, I’m suspecting that most of the people making requests for IPv4 space at the end will be doing IPv6, will be doing dual stack, will have actual customers on IPv6, will be ready. But we all recognize that until everyone else gets IPv6 in all of their network, everything is dual stack, you’ll still have to have IPv4 to connect. So there’s going to be a need for IPv4 well past exhaustion. That’s going to be mostly met by a transfer policy. So what’s really going to be the question here is can I get addresses for free from ARIN, do I have to pay for them, how does ARIN divvy up the last of the free addresses that are actually worth money.

John Curran: Got it. And rear microphone. Final comment.

Chris Grundemann: Two comments, one just as kind of clarity.

John Curran: Name.

Chris Grundemann: Chris Grundemann. I don’t know if everybody reads every message on the PPML, but the 20 and 10 /8s in IANA was – we came upon that because that’s – it seems to be about ten /8s handed out a year historically. Now that may speed up, but the idea was to space these two things out by a year so that at 20 you go six months, a year later at 10 you go to three months. And, also, I don’t know if you’re just addressing the perception that we’re extending IPv4 or if anyone actually thinks this will extend IPv4, because I’m quite certain it will not. If the need outstrips the supply, they will be used up. Regardless of who uses them. This just ensures that more organizations get to use them. That’s all. It’s not going to extend it. Maybe a week. I mean, just because you have to process more requests. But it’s not going to slow it down at all.

John Curran: Okay. Anyone want to respond on that last point about whether this actually extends? I think people know perception is hard to manage and it’s quite possible that the perception is it will extend, but will it actually extend by having people do two three-month requests instead of one six-month request.

Martin Hannigan: Martin Hannigan, Akamai.I agree it’s not going to do anything in terms of extension. And all it may do is create an unfair situation where needs are just disparately addressed. And my only concern is that if I’m going to have to battle people for address space at the end that it’s fair. And when I say 10 percent, I really mean 100 percent, because I know no one is going to go for 10 percent. But, yeah, I agree. It’s not going to extend anything.

Scott Bradner: I think if you go – if somebody goes to the well and the well is dry for them, they’ve run out, even if – or if they go actually needing 10 and they only get two, they’ve run out. I don’t think that this changes in effect what the run-out time is. It may mean that somebody may be able to dither a little bit longer, but in reality it doesn’t change anything.

John Curran: Owen, you want to respond on that point?

Owen DeLong: Owen DeLong, Hurricane Electric. I think that what this policy does, good, bad or indifferent – I’m not completely convinced in any particular direction as of yet – that it goes from a situation where one large request can empty the well at virtually any time to a situation where it takes many smaller requests to empty the well and, therefore, it depends on your perception of fair as to whether denying the large request for the sake of a bunch of smaller-sized requests from other requesters or even same-sized requests from other requesters getting smaller pieces of what little is left at the end of the crumb pile is better or whether whoever dives for that last crumb first should get it.

John Curran: We’re on the topic of whether or not this will extend the life.

Owen DeLong: It won’t extend the life.

John Curran: Thank you. You want to respond on that as well Matt?

Matt Pounsett: Matt Pounsett from Afilias. Like Owen said, it changes things from one big request can blow things away to when that one big request comes in they only get a part of it and, therefore, it’s not all gone. So in that sense, yeah, it does extend it, but not by enough to be significant. I think the real issue is that it creates the perception that things are going to last a little longer and that that’s the real danger.

John Curran: Okay. Thank you. Could you go back two slides? Let’s talk about the trigger conditions. Forward. Sorry. There we go. Okay.

For those people who will vote yes for this proposal only with its existing trigger conditions or only with the modified trigger adjustment, if you’re so sensitive to the trigger adjustment that you will only vote for this proposal with it written the way it is or with it modified and that’s the only way you’re going to vote, you can’t live with both trigger conditions, you only are in favor if one specific trigger condition is necessary, please stand up and find a microphone. If your support of the proposal is contingent upon the particular trigger condition, please come up and find a microphone. Are you in favor or against the proposal as written?

John Schnizlein: Opposed.

John Curran: And you’d be in favor of it if the trigger condition is changed to this?

John Schnizlein: You said “this.” It’s not correct –

David Farmer: This one here is not as written. This is a possible alternate.

John Curran: You only support the policy proposal if it would be changed to what’s on the screen now.

John Schnizlein: Yes, I think the two steps unnecessarily provokes that distorted impression of trying to slow down the train.

John Curran: So if it’s not changed to this, you are not in favor of the proposal.

John Schnizlein: Yes.

John Curran: Thank you. Anyone else, approach the microphones if you would like to speak on whether or not your vote would change based on the trigger condition. Yes, far left microphone.

Dave Barger: Dave Barger, AT&T.

John Curran: You’re against the proposal if it was changed to this.

Dave Barger: Right. When I got up a minute ago, I was against the proposal. And I’m against the proposal, but taking the second bullet up there, just taking that alone, I see no problem, and when we get to a certain level, say ten /8s, changing the policy from getting an allocation on a 12-month cycle down to a six-month cycle. Maybe that would be enough to allow ARIN to send some message out to the community that we’re doing something to change the rules, but at the same time it doesn’t get us down into the excruciating detail of running into the last /22 that’s available and all that kind of thing. But just base it on a six-month supply.

John Curran: You would be in favor with the modified trigger adjustment?

Dave Barger: With just that trigger adjustment, yes.

John Curran: Okay. Got it. Thank you. Anyone else want to speak who would change their vote based on the trigger adjustment?

Matt Pounsett: Matt Pounsett, Afilias. I might actually support this if only the triggers section was there, if we completely got rid of the whole second section of trying to hand out a quarter of the supply.

If we just – if it was just something like this, that’s essentially everyone getting 100 percent of their request just for shorter and shorter periods of time, that might be okay.

John Curran: Understood. But let me ask the question very specifically. If all we do is take the proposal and change the triggers according to this and leave that second part of the proposal as is –

Matt Pounsett: I’d still be opposed to it.

John Curran: Okay. Thank you. You can sit down. Marty, rear back.

Martin Hannigan: Marty Hannigan, Akamai Technologies. I oppose this. I agree with Matt. I oppose the policy regardless.

John Curran: That’s what I want to know. You can sit down. Dave, go ahead.

Dave Barger: Can you repeat what you just said to Matt a minute ago. Say that again, because I think I’m going to change my mind.

John Curran: Okay. Are you in favor of the proposal as written?

Dave Barger: I am not in favor of the proposal as written, no.

John Curran: If it’s changed according to this page that’s up on the screen, would you vote yes for it?

Dave Barger: So if it’s changed using these trigger points and all of the other verbiage that’s in there as well, then I am still opposed to it.

John Curran: Thank you.

Dave Barger: But I am in favor of it using the second bullet there.

John Curran: I’m not asking that, but thank you. It is useful information. We’re actually going to get to it, but we actually have to finish one question at a time. So is there anyone who will only vote for this proposal with the original trigger conditions? Thank you.

So people who are in favor of this are in favor of this with either the modified trigger condition or both trigger conditions. Wonderful. Okay. So I guess the only question is: There’s some number of people who believe that the – the one-quarter limit, when we get down to final /8, the one quarter-limit is not necessary or needlessly complex.

Bill Woodcock: Or wrong.

John Curran: Right. Or wrong. If you would like to speak against the one-quarter limit – i.e., the rest of the policy proposal – please approach the mics. Some people don’t like that one-quarter limit. We just had them up here. I know I found one. So I know Matt’s against it. Remote participant and then Dave. Go ahead.

Dan Alexander: Dan Alexander, ARIN AC. In regards to the triggers, even in general, there’s this approach of, well, we have to do something to show that we’re doing something so that ARIN doesn’t give the impression that they just let everyone hit the wall. But we keep seeming to forget that everyone in this room and the community is the ones making the rules; ARIN as an organization is not. So if we all choose let’s hit the wall, then we’re going to hit the wall. Somebody’s always going to be pissed off. There’s no way of escaping that one.

John Curran: Dave, do you want to speak about your reasons against the one-quarter limit?

Dave Barger: Again, Dave Barger, AT&T. I just think that we’re getting too granular at that point, and if ARIN does want to send some sort of a message, I think by publishing a policy that says we’re going to cut back to a six-month-maximum allocation, when we get to a certain level, I think that’s good. But if we start getting more granular than that and getting into a three-month supply and then a one-quarter allocation or some percentage-based allocation, again, that starts sending the message – I think that’s where the perception part is really going to kick in and take over. I think it’s going to send a message to those, again, controlling purse strings and all that that, hey, ARIN is out there milking this and trying to extend this, and the perception is that it will be extended, so therefore we can drag our feet on this little IPv6 project.

John Curran: Got it. You want to speak against the 25-percent limit, go ahead. Microphones are closed. Owen, do you want to speak against the 25- percent limit? Thank you.

Owen DeLong: Yes, we’re going to hit the wall. The 25-percent limit doesn’t change that. It just changes how many people fight over the last crumbs. And I think it changes it to no real benefit to the community.

John Curran: What’s the downside of having it there?

Owen DeLong: The downside of having it there is it increases the number of different prefixes we hand out of the last crumbs without providing substantial benefit to the community.

John Curran: Okay. So does anyone want to speak out in favor of why the 25-percent limit is necessary? People who want to speak about why that 25-percent limit when we get to one /8, if this is really essential, come to the microphones and explain why it’s essential. Far right mic.

John Schnizlein: John Schnizlein. It’s not about anybody who gets any address blocks during the final run-out; it’s about the organization that shows up just afterwards. And their anger, their outrage is going to be smaller if you haven’t set up a situation of winner takes all for the last round. If modifying their outrage is of benefit to the community because at least to the extent that that outrage doesn’t get sympathy in any of those communities that Dave had on the slide, that reduces the threat to this community.

John Curran: Okay. Someone else want to talk about that final 25-percent limit when we get to the /8? Either way: pro or con.

Chris Grundemann: Chris Grundemann. I actually don’t think it’s essential, but I do like it just because that last /8 is the dregs. I mean, that’s the very last bit of IPv4. And with this I think it actually sets up the perception that you’re not going to be able to come in and get lucky and get a big allocation at the very end. If you wait until the last minute, you’re going to get a quarter of what’s left, which is not going to be anything worthwhile for a big ISP, so you can kind of ignore that last /8 as not even being a viable resource for you. I think it helps with the perception that IPv4 is going away faster than you think it is.

John Curran: Thank you. Okay. I think we’ve reached the conclusion of our discussion. And I’d like to thank David.

(Applause.)

Okay. This will be fun. I need my tabulators to get ready. So we have a circumstance where the maximum number of people who will support this proposal support it with the reduced triggers. For that reason, I’m going to ask the question about support of the proposal with the triggers as reduced per the slide. And you’re going to have to get a slide back. Sorry about that. So it’s been recognized policies take some time, and, given that, we can probably trigger later than we were originally thinking. The policy proposal that’s in – okay. Policy proposal – I saw someone at the mic and I thought I already had someone objecting to my vote.

The policy proposal in your book, we’d like to change that policy proposal for the purpose of this vote to have a trigger condition of the IANA pool going down to 10 unallocated /8s, that would be the trigger condition for a six-month supply, and not dropping until three-month supply until ARIN gets to its last /8.

So with the policy as amended, I’m going to ask for everyone in favor and everyone opposed. People should know that on this policy this is the sole vote on this policy for adoption. There will be some votes later talking about the 25 percent portion. But you’re voting on this particular policy as amended with the trigger condition. If you vote no, you are saying you don’t want any of this policy.

Yes, Leo.

Leo Bicknell: A small parliamentary inquiry, there were also two editorial changes on the next slide. Do you need to ask about them specifically?

John Curran: I don’t intend to. I intend to leave those to the realm of the AC. So on the policy, Draft Policy 2009-8 as amended per the trigger adjustment on the screen, I’m going to ask for everyone in favor and everyone opposed. All in favor raise your hand now. Nice and high.

(Show of hands.)

If you’re in favor of the Draft Policy 2009, Equitable IPv4 Run-Out, as amended per the screen, raise your hand. This includes remote participants. Raise your digital bit. Okay. Thank you. On the matter of Draft Policy 2009-8, Equitable IPv4 Run-Out, as amended with the trigger adjustment on the screen, if you’re opposed, raise your hand now.

(Show of hands.)

Raise it nice and crisply. You want to get counted. You don’t want to raise your hand for your row after the tabulation machine has swept by. Okay. I’m going to wait for that to come up here and then we’ll talk about the next part.

On the matter of Draft Policy 2009-8, as amended, Equitable IPv4 Run-Out, number of participants in the room and remote, 136. Number in favor, 30; number against, 28.

Okay. That will be provided to the AC. Because the AC has a complicated job, I would like to ask everyone to participate in one more show of hands. I’m going to presume that this policy gets adopted because of its stellar support that we just saw. When it gets adopted, I actually want to know whether people would prefer to have the 25 percent limit that’s contained in the policy when we get down to the final /8 or no limit. I’m going to ask for people to say yes if they’re in favor of a 25 percent allocation limit when we get down to the final /8 or whether they want no limit. A vote of yes is you’re in favor of a 25 percent limit as written in the policy. A vote of no means you’re against such a limit. Does everyone know what we’ll be tabulating? Okay. On the matter of the 25 percent limit for the Equitable IPv4 Run-Out Policy, all those in favor of the limit raise your hand now. Nice and high.

(Show of hands.)

There’s refreshments coming soon; we’ll replenish those valuable calories. But get your hands up. Thank you. On the matter of the 25 percent limit for the Equitable IPv4 Run-Out Policy, if you are against this limit, raise your hand now. Nice and high.

(Show of hands.)

I promise a break is coming. Really. Thank you.

The poll is here. So on the matter of the 25 percent limit for Equitable IPv4 Run-Out, number of participants in the room and remote, 137. Number in favor of the limit, 26; number against, 33.

This will be provided to the AC for their consideration. Thank you very much. Okay. Now we’re at that wonderful point where we get to have a break. So hello, Scott.

Scott Leibrand: I really wish I had said that before you said “break,” but would you consider asking how many people like Matt and others support the policy given the change that you just asked if we should make? Because I believe that would be a much higher level of support than either of the two questions you’ve already asked. It’s up to you if you think that’s necessary.

John Curran: I try to keep the questions simple and not convoluted combinatorials. I’m very sorry; I don’t think that’s going to be clear to everyone. So on the matter – we’re now on the break. We’re going to be gone for about 25 minutes, maybe – we’re going to be gone for 19 minutes, so jump up and get moving. Break is out there. I expect everyone back promptly at 3:30. Thank you.

(Break taken at 3:11)

Policy Experience Report

John Curran: Welcome back. If people will get seated. Okay. This afternoon we have a few presentations talking about our experience with the policies to date and also talking about the AC’s on-the-docket proposals.

We’ll start with the Policy Experience Report. Leslie, come on up.

Leslie Nobile: Good afternoon. So this is the Policy Experience Report, and I thought I would throw up the PDP cycle just to kind of remind you all of where this actually fits into the policy development process. This is a formal part of it – following need, discuss, consensus, implement there’s an evaluate phase. And this is where the staff can provide some feedback to the community on how well or not well a policy is working or parts of a policy are working, and basically is it doing what it was intended to do. So basically what we do is we review existing policies. And we’re looking for text that may be confusing or ambiguous to customers, maybe inconsistencies within the policy text, gaps, things that might be missing, and the effectiveness, overall effectiveness: is the policy doing what it is supposed to do. We then identify areas where new or modified policy text might be needed. And we base it on our operational experience. We deal with these policies every single day. That’s how we operate. So we see a lot of what comes in, how well a policy is working, and a lot of it is based on customer feedback. If we see the same problems consistently or the same questions come up, you know, this is something we would identify in this report. Because it just might need to be changed slightly or altered. Then we provide feedback to the community. Generally in these sessions twice a year we’ll do these Policy Experience Reports and we’ll make recommendations.

So at this time we reviewed just two policies. The first one is identify invalid WHOIS POCs, Policy 2008-7. What’s different about this is we have actually not fully implemented this policy. We’re in the process of writing our implementation plan, and in the course of doing so we realized that there’s some things that we should bring to the attention of the community and perhaps get feedback on.

And then a second one is merger and acquisition transfers, NRPM – oh, that’s the wrong version. NRPM 8.2. Oh, well, that’s okay – NRPM 8.2 in the policy manual.

So we looked first at this identify invalid WHOIS POCs. And the part of the text that we’re talking about, the part of the policy is just this sentence: During ARIN’s annual WHOIS POC validation, an e-mail will be sent to every POC in the WHOIS database. So the key phrase here is the requirement to contact “every POC in the WHOIS database.” That would mean all directs and all assignments and all reassignments and every type of point of contact. So earlier this year we decided to be proactive, and we had been hearing from people “you gotta clean up the data.” And so before the policy was enacted, we sort of did this trial run. We called it our spring cleaning, our WHOIS spring cleaning. And we e-mailed all registered points of contact in ARIN’s database who had direct resources. That would be IPv4, IPv6 and autonomous system numbers. And we included those with legacy space, because those are registered as direct allocations or assignments.

So we contacted about 43,000 Points of Contact. We sent them e-mails, those who had the direct resources, and said, Please come in and clean up your data. Here’s the link and just come on in and do some cleanup if it needs to be. So we staggered these mailings and it took us about four months to complete from the beginning to the end. And overall our response rate was roughly 4 percent. It wasn’t great, but it was something. But what we left behind was the POCs with reassignments. And there’s about 359,000 reassignment records with points of contact on them.

So the issues and questions that we have for you all. So based on this recent POC cleanup effort, we kind of took a look and did some estimates and we figured it could take us up to 33 months to contact the 359,000 points of contacts with reassignments using the same rate of sort of staggering the e-mails so we weren’t getting inundated with calls and e-mails asking what it was all about. So based on our original WHOIS cleanup effort, we thought maybe 33 months. It’s a long time. And it’s an annual reregistration per the policy.

ARIN has no direct relationship or contract with downstream POCs. We don’t know who the reassignment people are. They don’t know who we are. Much of the time they don’t even know they’re registered in ARIN’s WHOIS database. So there’s no relationship. There’s no contract. As with the RSA, which all direct – people with direct resources sign. There is a contract, they know who we are, they came to us, they know they’re in the database. People with reassignments don’t know. And if we started contacting all of them, there could be some confusion, lots of phone calls. So the question actually becomes: Since the upstream is responsible for entering the reassignment information, shouldn’t they be responsible for maintaining and updating it as well?

And 5.b of the RSA says yes. There is a requirement in the Registration Services Agreement that organizations sign that says organizations must maintain their data in the WHOIS database and they must maintain the data that they put in for their customer reassignments. So it’s written contractually.

So our recommendations are to send e-mail only to those points of contact with direct allocations and assignments. That would be every type of point of contact. That would be the admin, the tech, the abuse, the NOC, because they’re all registered in the database. And basically make the upstream organization responsible for updating and maintaining not only their own records, but those of their downstream POC reassignments. So I’m going to move into the next one. I guess we take questions after or –

John Curran: Let’s take them as we go, because this is probably focus. On this recommendation, any thoughts or reactions? Front microphone.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council.And I shared this with Leslie earlier, but just for the public record. I think that it is actually important for ARIN to at least spot check that the ISPs are maintaining this data accurately for a number of different reasons, not the least of which is to preserve the appearance, if not the actual fact of due diligence, on resources that have been reclaimed and not reclaimed completely.

As such, I realize that a 33-month project that you have to do every 12 months is also a relatively untenable thing. What about the possibility of randomly selecting 10 percent of the POCs to contact? By my estimation, that would be a 3.3-month project every 12 months.

Leslie Nobile: That would be doable, but that’s not what the policy says. And if we want policy text to match –

Owen DeLong: I understand you need policy change to support these; I’m asking you what changes might meet your needs.

Leslie Nobile: I think that’s doable. I think you would want community input. I think that’s probably doable.

John Curran: Rear microphone.

Chris Grundemann: Chris Grundemann. First a question: For the 43,000 POCs that were contacted, did the e-mail request that all of them respond or only respond if you had changes? Or what – just for clarity, what did that e-mail say that went out to them?

Leslie Nobile: What did the e-mail say. Let me think about it. I think it said come in and respond only if you have changes. Please come in and update if you need to.

Chris Grundemann: Okay. Because the 4 percent was alarming, if they were all supposed to respond.

Leslie Nobile: Right. Right.

Chris Grundemann: The second thing is I was one of the authors on the proposal. And our intention – which we intentionally took it out of the policy; it was originally in some of the policy text – was to automate this process and to ask ARIN staff to automate it in a way that there’s an automatic letter that goes out and just a response, an authorization code, you click, whatever, says yes, I’m here, I’m alive, I exist. And I understand that building an automation system may take some time, but wouldn’t that vastly reduce the amount of time it takes to do the verification?

Leslie Nobile: Yes, absolutely. That’s our intention. In fact, that’s how we’re planning on implementing this and making it available through ARIN Online. Automate the mailings and automate the, you know, come in and click and just say yes, or come in and actually update it. But the fact remains that these 359,000 reassignment people don’t know who we are. So that’s a flood of phone calls, a flood of e-mails that humans are going to have to respond to.

Chris Grundemann: At least the first time. Maybe the next year there’s no question because we’ve seen this e-mail before. The other thing was – sorry – part of the reason I would be opposed to the 10 percent idea is one of the main intents was to get at least one of these cycles done before IANA free pool and ARIN free pool runs out.

So if we’re only doing 10 percent every year, we’re talking ten years before we contact everybody. And that doesn’t meet one of the major goals of actually verifying the space is in use before we need that space.

Leslie Nobile: Could I ask a question? Is that okay, John? You say verifying the space is in use before you need it. It’s actually just updating the point-of-contact information.

Chris Grundemann: I understand. And maybe I’m going on my own biases of why I helped write and support the policy was to – if we find address space that doesn’t have any valid POCs, then we can start to investigate that space. And so I’m going beyond what just the policy says.

John Curran: Thank you. Remote participants, do we have any?

Paul Andersen: We have two comments.

A comment from Ted Mittelstaedt, Internet Partners, Inc.: As one of the authors of the policy proposal that triggered your WHOIS POC cleanup, I assure you we were all well aware that downstream POCs would likely not confirm their registration. We never expected ARIN to make heroic efforts to verify the nonresponsive downstream POCs. So quit wasting time doing this. We expected ARIN to invalidate the SWIP records of nonresponders, period.

And Joe Maimon asks: Why don’t these logistics warrant an emergency policy action?

John Curran: Okay. Center front.

Glenn Wiltse: Glenn Wiltse, Merit. We’re one of the people that have a lot of these downstream POCs, but there’s difficulty in updating them because, theoretically, you’re only supposed to be able to update that POC record if you’re the person who it belongs to – who it is. So is there some way that we can automate that, or will ARIN just allow us to update?

John Curran: You need proxy authorization.

Leslie Nobile: Absolutely. And that was a consideration in the implementation plan that we wrote up that was a definite. Let the upstream manage the downstream records regardless of whether they’re listed. So, yeah, as a point of contact, yes.

John Curran: I see Nate at the back microphone.

Nate Davis: Yes, Nate Davis, ARIN. Leslie, to Chris’ point and the other point that was just mentioned, do you want to talk a moment about the phone-level support that’s also needed when we send out these mailings for cleanup? The reason I mention that is that automation handles a lot of what’s being proposed here, but there’s still a human factor that’s involved in phone support.

Leslie Nobile: Right. And that really was my point that this will generate a flurry of phone calls and e-mails asking what are you talking about. And it did the first time we did it. We got hundreds of phone calls and e-mails saying we don’t know what you mean and how do we do this and et cetera, et cetera.

John Curran: Center front mic.

Leo Bicknell: Leo Bicknell, ISC and ARIN AC. I have one question and then one suggestion.

The question would be: When you sent out these e-mails, did you look at the volume of POC changes coming in; that is, is there anything to indicate that people got these e-mails and, rather than replying or calling you or whatever, just silently updated their records?

Leslie Nobile: We did track them. We had a way of tracking them coming back in. So we – that’s why I say the rough 4 percent figure. That was just those that we sent letters to. Yes. And we also tracked some of the bounce-backs, but not all. And we had probably a 12 percent bounce-back rate undeliverable.

Leo Bicknell: I guess my concern is sort of the case where you mail someone no longer with the company, so he picks up the phone and says, Hey, Bob, you need to get on top of this, and so maybe the tracking kind of gets lost.

Leslie Nobile: Right. And I can tell you one of the things that we did to accommodate that was we sent one e-mail and we included all of the points of contact associated with the organization so that the admin, the tech, the abuse and the NOC all got the same e-mail and they were all copied on it. If one of them wasn’t there, we expected one of the others to come back and tell us. And that seemed to work fairly well.

Leo Bicknell: The other suggestion, and as I say this, I realize there’s a few details that would have to be worked out, but it seems to me if ARIN is going to send direct e-mail to the downstream POCs the correct thing to say in that e-mail is to contact the upstream to make changes, not to contact back ARIN to make changes. And I realize that some people, because the mail came from ARIN, will still call ARIN anyway. And probably some of the upstream POCs will call ARIN and say, What the heck are you doing? Why are you flooding my NOC with these? But it is their responsibility to do it. So if they’re not doing it, having them feel the pain of those requests coming back to them seems on some level appropriate.

John Curran: I will note that in the domain world, for example, those entities need to contact their clients directly to update. And all that we’d be doing, then, is you’d have us automate the sending out on their behalf, but effectively put the workload of response to the upstream ISP. Okay. Interesting thought. We have remote comment.

Paul Andersen: Comment from Ted Mittelstaedt, Internet Partners, Inc.: None of ARIN staff working this cleanup have contacted the authors of this policy proposal for suggestion on implementation kinks. I personally find it ridiculous that you are appealing to the general membership to modify parts of this effort before even contacting the people responsible for writing it. Please contact us out of the meeting to assist you in understanding the intent of this policy.

John Curran: I can respond directly to that. Once a policy comes into the community, it’s owned by the community and so – but any e-mail that they want to send with suggestions is wonderful, but it’s the community’s interpretation. Yes, center front.

Andrew Dul: Andrew Dul. I don’t agree with sending the e-mails to the reassignments. I think that is appropriate of the ISPs. I’m somewhat intrigued by Leo’s idea of sending it as from the organization that is responsible to it. It seems a bit unbusinesslike, but it is sort of interesting. The other question I had is if you were talking about the reassignments, how are you able to verify that the person who came back to you is actually authorized to make that change?

Leslie Nobile: If we’re talking about sending mail to the –

Andrew Dul: If they come back and say I’m Joe Schmo and my friend Billy Bob is now the admin contact for my block. You don’t have a relationship with Joe Schmo or Billy Bob and it doesn’t seem to me that ARIN should be in the business of updating records that weren’t generated with a direct relationship. So I think we should focus our efforts on the direct allocations and assignments and let’s worry about the other part later. I realize that’s not what the authors intended. But that’s my personal opinion.

John Curran: Okay. Far left microphone.

Heather Schiller: Heather Schiller, Verizon Business. I came down from the stage because I wanted to give a little feedback about our experience with this. So I should also mention that I was one of the co-authors of the policy. And I disagreed with Ted’s comment. I think that ARIN staff is absolutely right in coming to the community to talk about their experience in implementing this.

So we got a bunch of e-mails from ARIN asking us to confirm. And what Leslie said is true. The e-mail went to all of the POCs that were listed. And you had a link to each POC, and we – I thought that we were pretty on top of our records. It turns out that we kind of weren’t. And we found that there were people who were listed as POCs who were not – like the domain wasn’t even a domain that our company owned. There were people from other companies, and we couldn’t untangle how that even came to be to begin with. But I was sure as heck glad that I got to the e-mail first before those people had the opportunity to say please remove this Heather Schiller person from all of our records. And so I’m not quite sure what I – I kind of want to point that out to ARIN staff. I know that it may create an additional burden. But for like everybody in the room who either has or hasn’t been through this experience – but to take it seriously because you could end up getting like removed from your own resources. And so I haven’t figured out what I think is the right thing to do about that, but…

John Curran: Those people who have turned on PGP validation don’t have to worry about what happens when that mail comes out. But, yes, I agree. No form is weak.

Heather Schiller: No, I’m sorry. How does – that doesn’t actually change anything. So what happened is – say they had – [email protected] happened to be listed as a POC on my – our Verizon Business resources. You got the e-mail and you can respond and remove everybody else from it.

John Curran: Okay. I do agree it’s a race condition when the e-mail comes out. Okay. Rear microphone.

Chris Grundemann: Just two quick comments. Sorry. Chris Grundemann. One thing is WHOIS authentication between POCs and ARIN and resource holders is a separate issue, I think, that probably does need to be addressed but doesn’t necessarily have to do with these e-mails.

And the second thing is although I focused on one avenue before, the other main concern of this is to have abuse contacts when you’re in an abuse situation, which is why having every POC validated is very helpful, not just direct holders, because whoever is actually using the space is who you want to talk to if you’re getting spammed or DOSed or whatever the case may be.

John Curran: Understood. Okay. Last chance on comments on this particular set of recommendations.

Matt Petach: I do want to – Matt Petach from Yahoo!. Sorry. I do want to comment that 359,000 emails to people with whom you don’t have a business relationship would be flagged as spam in our mail systems, along with many others. While we as a community may feel that there’s a transitive business relationship because ARIN worked with the ISP and the ISP is sold to somebody else, the people receiving that do not necessarily accept that transitive relationships constitute a direct business relationship and therefore not a spam condition. Be aware of that.

John Curran: Okay. I’m closing the mics on this topic. I’ve got Owen and one remote. Two remote. Go, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric. ARIN has a defined contractual relationship with the upstream, which, if I recall correctly, specifically includes a subordinate contractual relationship or at least a subordinate specification of policy be passed along in that process. Therefore, I would think that that should cover any spam conditions, but maybe not.

John Curran: It may be – certainly in an RSA. I’m not sure it’s going to get by someone’s mail message counter. It may be right, but that won’t still prevent it from being blocked. Okay. Two remote participants. Go ahead.

Paul Andersen: First from Ted Mittelstaedt, Internet Partners, Inc.: If you don’t agree with sending e-mails to the reassignment POCs, then submit a policy proposal to modify the NRPM. This issue was raised and answered a year ago on the PPML.

And Joe Maimon says: If ARIN is going to delay implementation, then emergency policy action to excise reassignments is actually more appropriate.

John Curran: Okay. Wonderful. All right. Keep going, Leslie.

Leslie Nobile: Second policy. So merger and acquisition transfers. So bear with me. I have to read the text because it’s important. So ARIN will consider requests for the transfer of number resources in the case of mergers and acquisitions upon receipt of evidence that the new entity has acquired – now pay attention, dark blue – the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity’s use of the number resources. So that says that the assets being transferred – for example, the customers that are going along with the M&A, or the equipment – must have been using the resources at the time of the M&A. Okay. So this is just one part of this M&A transfer policy. Just this utilization requirement.

So the issues and questions that we raised based on community feedback, really, from our customers. So people tell us that that is unclear to them. They’re not sure what that means. They’re a bit confused. So we say, well, the text could probably be made more clear, that particular sentence. Transfer requests often come in years after a merger and acquisition activity. It’s seven years, ten years we’ve seen. So it’s really difficult for the customer to know how these resources were being used at the time of the merger and acquisition. And frequently we’re seeing, you know, three levels down. We’re seeing company D or E come to us when it’s really company A that’s registered in the database.

So not only do they have to find all of the paperwork, documentation, et cetera, they’re trying to figure out what was being used when, when this happened maybe seven years ago, five years ago. So we have a couple of questions based on that. And actually I have one point. I did speak with a member this morning and he was telling me that the M&A transfers are so difficult for them because they do a lot of that activity, and the last thing that their CEO or their executives are thinking about are Internet number resources. They just know their network works. They don’t even know what they are half the time. So that’s never a focus; it’s an afterthought. So that explains partially why we get these requests so many years after the fact. So the questions. Should utilization at the time of the transfer request be considered? If resources that were transferred as asset – the assets were transferred using these resources are being used right now today when you come in to request a transfer, should that be considered and should that be justified. If there’s little or no utilization at the time of the transfer, let alone at the time of the M&A, should future use count. Should someone be able to come in and say they’re not being used today but we have a plan for them. Here it is. We’re going to use them within three months in this new service or product we’re deploying. So and the thing that we have to – I really need to let you all know is that the more stringent the requirements, the more likely it is that the transfers are going to be abandoned and that ARIN data remains inaccurate.

And I went back and looked at our stats. I looked at the past three years, and I compared transfer requests coming in and transfers completed. And this figure was pretty astounding because 60 to 75 percent of all transfers that get started get abandoned and they do not complete the action.

John Curran: One little note here. I want to be clear that currently the requirement is to know how the resources were being used at the time of the M&A. And the question is actually two parts, which is at the time of the transfer request if there’s usage but there wasn’t at the time of the M&A but now it’s two years later and they’re putting in their paperwork, well, it seems strange to penalize them because they weren’t using the resources two years ago, but now when they put in the transfer and then, of course, if they’re not using them now, there’s the question of in the future if they have a plan to use them. So there are actually two future states: the one of the day of the transfer – the one of the M&A the day they do the paperwork with us, and then the plan for the future.

Leslie Nobile: Right. Should I actually keep going? So I’ll tell you what our current practice is. This is actually what we do today. So the staff’s focus is on completing the transfers, getting accurate data in the WHOIS. So typically if a transfer has proper documentation, meets all of the criteria in the policy – because there’s quite a bit of criteria in there – but the resources themselves are either underutilized, not utilized, they’re not sure how they were utilized, the staff requests return of these resources. If there’s some unused space, we ask for it back and we do get it back. And I have some data on that tomorrow. But we will get resources returned to us. Regardless of whether they get returned to us and regardless of whether they’re in use at that time, we will approve the request.

So we have these recommendations because we feel like the policy should be more in line with reality. So we were thinking that perhaps the utilization requirements could be liberalized by allowing any of the following conditions: The resources being transferred must be in use at the time of the M&A, which is what it says now, or in use at the time the transfer request is submitted to ARIN, or, if not in use, the new entity must demonstrate how the resources will be utilized within the next 12 months. So that was it.

John Curran: Okay. Would people like to come up and talk about this? I want to reiterate: This is where we give you feedback on this. This is, if it’s not clear, feedback so you folks can figure out if you want to make policy changes. Our suggestions are purely suggestions. This is us trying to follow what you’ve asked. And to the extent that the community and AC doesn’t pick this up with policy recommendations, things won’t change, doesn’t have to. Okay. Center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I definitely don’t like the “or,” because, to my computer-parsing brain – so they could be in use at the time of M&A and then you got rid of that division and you don’t use them anymore and the “or” is satisfied, right, because “or” is short-circuit that way. So I don’t quite think just the “or” is the right language.

But what I actually wanted to say, more importantly than that, is it sounds to me like the actual problem here is ARIN needs to find a way to make sure that M&A transfers happen closer to the actual M&A event. If these are happening seven, ten, 15 years later, that causes a whole host of problems. And so moving it up would make more sense. And so I’m actually wondering about things like if ARIN were to, say, receive a check for the payment of fees that no longer has the same name as the old resource holder on it. Should they perhaps send them an e-mail and say, Did you in fact merge with this person who is now paying your bill, things like that. It’s just an idea off the top of my head. But to somehow make this all happen much closer and then I think a lot of these problems just disappear.

John Curran: There are probably a few things we can look at. But you have to remember, there was a period of time when the industry was rolling up 30 and 40 companies in two quarters. And the problem really is that getting the check that has the different name for a while wasn’t the exception, it was the norm. And the people you would call up to ask may not realize. They just have a list of bills to pay. They have no idea why that bill of a company is, not one they acquired, but it’s one that that acquired company acquired acquired, acquired a company earlier. It can be problematic. But I understand we can look for indicators. I guess the question is even if we look for indicators, we need to know whether or not we should prioritize keeping to the policy as is or accuracy of data. That’s what Leslie’s trying to get feedback on.

Leo Bicknell: I think the accuracy of the data is paramount, but the other side of that coin is that you don’t want to reward someone for not updating this for years. So if you simply let them update the data with a free pass, that also seems a little bit problematic. So I don’t want to impede updating the data, but I certainly would, for instance, support things like a penalty if you haven’t done this in a certain amount of time, like financial penalty. If you haven’t updated your M&A in three years and you want to get more resources, then you’re going to pay us an extra five thousand bucks to get your stuff straightened out. Because it’s more work for ARIN, quite frankly, to dig back in the old records. So it shouldn’t be a free pass, but the data is paramount.

Leslie Nobile: Can I just make one reply? Is that okay?

John Curran: Yeah.

Leslie Nobile: Just so that you know, many of our transfers deal with legacy space, so there’s no payment coming into ARIN when they come to us, so there’s really no way to check that.

John Curran: Yeah, it’s a fun lot of work with no payment for you. That’s important.

Leo Bicknell: Maybe we should charge them fees.

John Curran: So center front.

Owen DeLong: Owen DeLong, Hurricane Electric. There should be payment coming in from the years that the asset – that the addresses were transferred along with the assets forward, certainly. And so determining when the assets and, thus, addresses were transferred seems a worthwhile endeavor.

John Curran: Could you explain that?

Owen DeLong: Sure. If you transferred the assets and the addresses and failed to record it with ARIN, you can’t transfer legacy space under this policy as I understand it and have the recipient still not subject to RSA and not subject to fees.

Leslie Nobile: They are subject to both.

John Curran: Right.

Owen DeLong: Therefore, when the assets were transferred, that recipient, if they transferred the addresses with the assets, started owing ARIN money.

John Curran: I will confirm that.

Owen DeLong: Because otherwise the addresses were transferred outside of policy.

John Curran: We – I do not believe our present policy is to accrue back for that.

Owen DeLong: Let’s make this clear. Our present operational practice is not to do that.

John Curran: I will say that our present –

Owen DeLong: Our policy is that when the addresses are transferred, they’re subject to RSA.

John Curran: The odds of you ever seeing a completed transfer just went to zero, just from a practical basis. You can update your records and have the honor of paying ARIN for the six years that you didn’t.

Owen DeLong: I understand what you’re saying. I’m not saying we shouldn’t let them slide on the past invoices they owe or not. I’m saying that we should make that policy clear one way or the other.

John Curran: I do agree.

Owen DeLong: And that we should consider that in our deliberations.

John Curran: Fully.

Owen DeLong: But the issue that I see in this is you’ve got legacy space and it goes off into the ether for ten, 15, whatever, years, and some creative individual discovers, hey, look, I was able to register this domain name and I was able to create a corporation with this name on it, and I’m just going to sort of take that space and I’m going to call myself that and I’m going to register a transfer with ARIN and say, see, I’m the successor organization. I own the assets.

Leslie Nobile: That doesn’t happen. We do quite a bit of research and we trace back all the history.

John Curran: I’m going to jump in a little bit. It is possible, if you’re really creative, to look pretty good. There’s a high probability in doing that, though, that you’ll get asked a question you won’t like the answer to. At which point the historical tendency has been, well, actually I’m not sure I want to do this. I’m going to stop the process. I’ll withdraw my request. So that has happened quite a bit in the past. It doesn’t actually solve the problem because the address space is still there. But if you aren’t the holder of that address space and you abort your transfer, there’s no reason why that address space shouldn’t be reclaimed. And there’s nothing to prevent ARIN from doing so, and we have started that.

Owen DeLong: Well, good. I’m very glad to hear that.

John Curran: And we’re not taking address space from anyone because they’re not the holder of record.

Owen DeLong: Right. I’m very, very glad to hear that that’s finally happening. I think that the WHOIS contact policy we were talking about before could further help that along and make sure that we have fewer of these issues going forward.

John Curran: Yep. On some of these recommendations you don’t like the “ors”?

Owen DeLong: I do not.

John Curran: Okay. Just curious.

Owen DeLong: I don’t like the “ors” at all. I really don’t want to change it in this way.

John Curran: Rear microphone.

Tom Watkins: Tom Watkins, NTELOS. I’m a bit curious about this transfer policy. We acquired companies in the past. We still have IP spaces registered through them and it’s never been transferred over. We still pay the bill as if that entity still existed. The goal of this is to try to get this stuff transferred over. And I can’t speak for why it hasn’t been transferred over, but if I had to suspect from the previous management that was in control of those assets was they, one, probably didn’t understand the policy and were worried about trying to transfer it over, or, two, thought it was too difficult to. So if we can come forward now – and, again, we’re not delinquent on payments for this, but it would be nice, and it’s exactly what you guys want, to be under a single-business unit that owns that space now. So if you don’t have these in here, it makes it more difficult for us to transfer that stuff because these particular assets go back to 2000, 2001. So I don’t know what the utilization was then, but I know what it is now.

John Curran: Okay. We have some remote participant. Go ahead.

Paul Andersen: Yes, call in from Ted Mittelstaedt, Internet Partners, Inc.: Current ARIN practices on M&A that favor validity of WHOIS are fine; however, please do not give these organizations a free pass to not update their records. We would sooner see an organization be excluded from utilization requirements than being allowed to keep stale public records out there.

John Curran: Okay. Good feedback. Center front.

Scott Leibrand: I’ve already volunteered to write the updated policy for this in some conversations with people who complained about it being really hard for their lawyers to understand, so I would love to get feedback from the community how they want the text. And there will be lots of process on that. But I do have one question for Leslie. Since we now have 2009-1 implemented and IPv4 transfers are really easy, don’t require any documentation of M&A at all, has that changed things at all from your perspective? Or do most of the transfer requests have non-IPv4 resources, like ASNs, involved and have to go through this process anyway?

Leslie Nobile: Many of them have ASNs involved. I would say that the majority probably do.

John Curran: Okay. Keep going.

Leslie Nobile: That was it from me. Just had the two.

John Curran: Okay, just the two. Thank you very much, Leslie.

(Applause.)

Okay. Next up, the AC has a number of policy proposals which are on its docket, some of which were advanced to meeting and some of which they are still working on. I’m going to invite John Sweeting up, Chair of the AC, to talk about it.

AC On-Docket Proposals Report

John Sweeting: Hello, everybody. I’m John Sweeting with Time Warner Cable and the ARIN Advisory Council. We currently – the AC currently has four proposals that are still on our docket that weren’t ready to be presented here in Dearborn. So we just wanted to run through what those four proposals were, just prior to open mic, so that if anyone has any comments they’d like to make during the open mic period, we’ll be able to do that.

So this is just a quick slide on what happens with proposals. The AC, we either add it to our docket or we abandon it. Once it’s on the docket, it’s developed, brought forward to the list and PPM as a draft policy. And, like I said, we have a few, four to be exact, that did not make it fully developed in time for this meeting. There they are.

So the four proposals still on the docket are Proposal 95, Customer Confidentiality, and the shepherds of that are Paul Andersen and Marc Crandall; Proposal 97, Waiting List for Unmet IPv4 Requests, which is Scott Leibrand and Dan Alexander; Proposal 98, Last-Minute Assistance for Small ISPs, Bill Darte and Cathy Aronson; and Proposal 99, /24 End-User Minimum Allocation Unit.

Proposal 95, Customer Confidentiality, would require ISPs to provide only their customers’ names on reallocations and reassignments, but they would also have the option of – the ISP would have the option of providing their own address and phone number as part of the contact information. The other stipulation in it is if ARIN requested the full customer information, then the ISP would have to provide it. But it would be kept confidential by ARIN.

Proposal 97 – oh, and Proposal 95, the original text came in from Aaron Wendell. Proposal 97, the original text was by Scott Leibrand and is the Waiting List For Unmet IPv4 Requests. This proposal would change the way ARIN’s current address-issuing procedures are and instead would require that a single, contiguous address prefix would be issued for each of the approved requests. Would also create a waiting list for requesters whose needs can’t be fulfilled at the time of the request, and also try to prevent gaming the intent by forbidding requesters making small requests; whereas, if you ask for a /16 and you get on the waiting list, you couldn’t come back and ask for a /18, /19, whatever.

Proposal 98 is Last-Minute Assistance For Small ISPs. That text was sent in by Ted Mittelstaedt. This proposal would reduce the initial minimize size from /20 to /23 in stages based on utilization of ARIN’s last /8. As you can see there 90 percent, 95, 97. And it applies only to the last /8, not to transfers.

Finally, Proposal 99 submitted by Owen DeLong. This proposal would lower the multihomed end-user minimum prefix from /22 to /24. And also if any end-user requests additional address space, they would have to return the smaller prefix for a larger one and have to renumber and give the smaller one back.

The complete text for these proposals and the rationale for each one can be found on the ARIN web pages. We also had these four proposals for the lunch-table topics for discussion the last two days, so I’ve heard there was really good discussion around these. And so the AC, we really are looking for any input you might have now or any input in the future when we start talking about these on PPML.

John Curran: Microphones are open. The AC has a difficult job because they have to beg, borrow for proposals; they have to moderate the rate at which they sort of chew off suggestions that come in from the community, policy proposals. They only have so many drafts at the time and really make good progress. So hopefully they’ve chosen the right ones, but any feedback now would be the time. Thank you, John.

(Applause.)

Open Microphone

John Curran: With that, we’re back on schedule. We’ve allowed an hour for the open microphone. We have 43 minutes; that should be plenty. The microphones are open at this point. Anyone who has any topic on ARIN regarding policies, suggestions, operations, please approach the microphone.

Bill Darte: Bill Darte with Washington University, and I’m on the Advisory Council. So at this meeting and in past meetings we had lunch-table conversations and in this particular event we used that time in part to look at these proposals that are on our docket. And I just wanted to thank the people that were at Cathy Aronson’s and my table for their input, because that’s greatly appreciated as we go forward into deliberations on these particular proposals.

John Curran: Thank you. Okay. Microphones remain open. Center rear.

Stan Barber: Stan Barber, and I’m now speaking as the director of the Texas IPv6 Task Force and not The Planet, although they have something to do with that. I want to express appreciation to ARIN for sponsoring our initial activity, which is November the 3rd and 4th in Houston, promoting the creation of the Texas IPv6 Task Force. ARIN is a gold sponsor of the event. If any of you are interested in learning more, look at our website. It’s online IPv6 and IPv4 at www.txvf.org.

John Curran: Thank you, Stan. Microphones remain open. Yes, remote participant.

Paul Andersen: Question from Ted Mittelstaedt of Internet Partners: Could we have a show of hands on how many people want to soften the supersonic crash into the wall of IPv4 run-out and how many want to do nothing and let the crash happen?

John Curran: That’s a pretty simple question to talk about. We’d normally allow debate about the favor of the supersonic crash versus not, but I think everyone understands what’s being discussed. So we can forego that. I will have to speed up my polling machine. If the tabulators will come forth. I think we have a shortage of tabulators. No, we’re all here. As I understand the question, it’s – I’m going to – I can phrase it two ways, but I guess I’m going to get it right.

Everyone in favor of a supersonic crash in the wall say aye. That’s going to be it. We’re going to have a show of hands on the supersonic crash. With respect to IPv4 depletion, everyone in favor of a supersonic crash into the wall, raise your hand.

(Show of hands.)

Nice and high. I didn’t expect a vote, guys. Raise it up. Come on. All in favor of the supersonic crash, raise your hand. Everyone opposed to the supersonic crash, raise your hand.

(Show of hands.)

Nice and high. After the vote, Owen, but yes. Nice and high. Almost there. Okay. Thank you. Owen.

Owen DeLong: So in canyon flying there is what is known as the point of no return. This is the point at which the canyon has become narrow enough that you cannot turn your plane around and the walls have become steep enough that you cannot outclimb the walls of the canyon. IPv4 reached that point some years ago. Could those who voted no please explain what the alternatives to the supersonic crash are?

Unidentified Speaker: Very big pillows.

John Curran: If anyone would like to explain their no vote, grab a microphone. Center front. Identify yourself.

Scott Leibrand: Exactly what Dave just said. Scott Leibrand, ARIN AC at this point. The alternative to a supersonic crash is a subsonic crash. I believe the question at hand here is very similar to the one that I wanted John to ask before that break that we all wanted to get to, which is Ted probably wants us to know whether we should be working on this problem at all or whether we should just abandon David and Leo’s proposal and forget about the whole concept. And I think that’s what we were just voting on by way of metaphor. So I think that is useful feedback, and thank you everyone for your hands up.

John Curran: Okay. Rear microphone.

Chris Grundemann: I want to echo that and say I really don’t like the crash – Chris Grundemann. I don’t like the crash metaphor because in a crash the plane’s destroyed, the car’s destroyed, or whatever. In this case everyone continues to operate with IPv4. IPv4 doesn’t stop working the day it runs out. There is no crash. We simply can’t grow that portion or that form of the Internet any longer. So you’re running out of gas. In that case there are alternatives. You can decide to put the car in neutral and coast to the closest gas station, or you can put the pedal to the metal and run out of gas in the middle of the highway and get hijacked or whatever happens there.

John Curran: Center front.

Kevin Oberman: Kevin Oberman, ESnet. I think Chris is the eternal optimist if he thinks this is not going to be a crash. Ask the number of owners of companies that go belly-up because they had not prepared for this, had not rolled out IPv6, had paid no attention at all and suddenly they realized their business plan is no longer worth the paper it’s printed on nor is there company stock. There will be a crash. There will be victims and it will be bloody. I have nothing against padding, but I have something that extends the time until the crash occurs because I don’t believe that will do any good at all.

John Curran: Okay. Microphones remain open regarding the supersonic crash.

Those in favor of the crash, 33; those against, 27.

This will be provided to the AC for their consideration.

(Laughter.)

Mr. Schiller.

Jason Schiller: I want to explain why I’m in favor of the supersonic crash.

John Curran: Absolutely.

Jason Schiller: So we’ve always had a needs-based policy for the history of this body giving out addresses. And that seems to be a very fair approach. And I think if we’re going to change that approach, I have to have an overwhelming argument of why what we’re moving to is more fair than what we currently have, because otherwise it just feels like we’re changing the rules of the game very close to the finish line, which just doesn’t sit right with me. With regard to rationing, anything that tries to lengthen the time by rationing the addresses or giving out less, basically what that does is it increases the pain point for some community because they can’t get the addresses that they need. They experience the pain of depletion sooner. And why should one group have that burden as opposed to another group? And that’s something very hard for me to accept as being more fair than what we currently have.

John Curran: Got it. Microphones remain open on the subject of the cross.

Scott Leibrand: Follow-up for Jason. Do you believe that reducing the time window as was discussed on that slide and as we voted on earlier, that kind of thing also has that effect? Or is that an okay thing to do because it doesn’t actually ration?

John Curran: We need that calculator sound again.

Jason Schiller: I’m not sure I can answer that on the spot.

John Curran: Give it some thought. The mics will be here tomorrow.

Jason Schiller: Let me think about it.

John Curran: Remote first.

Paul Andersen: Ted would like to say the newspapers and politicians are going to call it a supersonic crash. It sells papers.

John Curran: Center rear.

Chris Grundemann: Chris Grundemann. Sorry, I completely lost my train of thought now. What I was going to say was limiting the amount of addresses or at least the time or whatever it is that people can get at the end I think does the opposite of eliminating some communities from getting all the addresses they can. I think it actually allows more communities to get the addresses they need. If you look at other regions, other parts of the ARIN region like Caribbean or like that, just because they’re big AT&T, Comcast, Time Warner Cable, someone comes in takes the last section, then a couple of cable modem subscribers or DSL modem subscribers in the States will be happy. Then there’s smaller communities. They have small ISPs that won’t get addresses if we limit it down. I think there’s more chance that most of those smaller ISPs in smaller areas in those underserved communities will have more addresses, not less.

John Curran: Thank you. Center front.

Cathy Aronson: Cathy Aronson. Chris’s comment made me think about working in the ARIN booth at trade shows and talking to people about how their network really isn’t going to actually stop working when we run out of address space. It’s going to continue to work. And so the great wall that we’re going to hit also happens because people don’t have the translation they need to get between the old network and the new network. And this policy doesn’t help that at all. Anyway, but I think we need to be careful when we talk about the great crash, sonic, whatever we call it, that people’s customers’ are still going to work; they’re just not going to be able to have any more.

John Curran: Right. It will be predominantly a crash for those people who are used to getting addresses reliably every six months or 12 months, who suddenly get told no and their replacements get to explain to their bosses what happened to the Internet addresses. Okay. We’ve got something remote.

Paul Andersen: We did. Joe Maimon’s response to why one group should bear the burden over another. The answer is simple: Because the group unable to fill their huge demands first are also the ones who have had huge advantages up to this point. Give back time.

John Curran: Okay. Microphones remain open on this or any other topic. This is the open microphone session. It is also the only thing keeping you here. Balance your need to ask a question.

Heather Schiller: Is Paul Wilson still here from APNIC? Heather Schiller, Verizon Business. Is Paul still here? I think you gave a presentation earlier that said that the number of help desk requests had gone up something crazy like 55 percent in the last year. And I kind of meant to ask earlier: Do you have that categorized in any way? Are people calling and asking, When are you going to run out of IPv4 space? Are they calling to ask, How do I get IPv6 or – I’m just a little bit – I’m just kind of curious if you have any more information about that.

Paul Wilson: I think we should have quizzes after our presentations to see who’s been listening.

(Laughter.)

Sorry. I’m as much an offender as anyone of doing e-mail during these meetings. What I said was in fact the help desk queries have gone up by 55 percent but the address requests have gone up by 5 percent in the last year.

Heather Schiller: I absolutely understood that. I’m asking you what are all these people querying you about.

Paul Wilson: I’m sorry. It’s a question of listening to the question, isn’t it?

(Laughter.)

I actually have no idea. All sorts of things. It’s an interesting question that covers everything from spam abuse to postmaster requests and everything else.

Heather Schiller: It seemed like such a large increase that I was wondering if something precipitated.

Scott Bradner: Is something in the water making them dumber?

Paul Wilson: The Internet is growing.

John Curran: Microphones are open.

Leo.

Leo Bicknell: Leo Bicknell wearing my ISC hat at the moment. Cathy mentioned translations as an interesting part, and for the most part I don’t think ARIN is the right forum for that. My company is developing e-translation technology. And the tie-in to ARIN, the one thing we need to be thinking about is we set aside this /10 and the last /8 for translation technologies and other enablers, and no one has ever defined what translation technologies, other enablers – no one has really defined what that is. And it may be slightly premature, but it seems like once we run out of all other space, someone is going to come to ARIN saying, This is my wonderful technology X, and someone will have to qualify or not as a group before we ran out of addresses if we decide what qualified.

John Curran: Let me be clearer. It would be useful if you folks would decide what qualifies before we run out since some people actually try to deploy the gear ahead of the demand.

Leo Bicknell: Really?

John Curran: Center rear microphone.

Aaron Hughes: New topic. I’m looking at an article written two days ago by Gartner that says: Don’t Sweat Move to IPv6.

Basically the article tells the world that it’s not really important and IPv6 is only good for the military, et cetera, and these kinds of things are still being sent to the global Internet and companies all over the world.I’m wondering what we can be doing to change outreach to help mitigate this kind of PR.

John Curran: On November 3rd I have a two-hour block to Gartner to correct that particular article. You’re also the sixth ARIN person to bring it to me in the last 48 hours. We actually see the press through a press monitor. We knew within a few hours of it coming out. We can’t always catch them in advance. Sometimes, like Gartner, they get to be unique and innovative on their own before we can get ahold of them.

Aaron Hughes: Is ARIN planning on proactively going to analysts to help create more articles to promote IPv6 and explain the reality?

John Curran: I have spoken to Burton Group. I have Forrester and Gartner on my schedule for the next three months, a little farther out, and obviously Gartner I would have liked to have on my schedule, but it’s taken awhile. But, yeah, we will actually go through the trade analysts first, and in the latter half of next year we’ll do the financial analysts, which should be fun.

Aaron Hughes: Thanks for attempting to address this.

John Curran: Okay. Remote.

Paul Andersen: Question from Joe Maimon: I’m not quite clear whether the PDP explicitly gives the AC the latitude to defer or delay proposals for future meetings if they feel they are not ready for general presentation or discussion, or whether they need to be abandoned or can either occur at their discretion.

Scott Bradner: The AC has full power to diddle or dawdle or delay or put forward or throw away or manage or mangle or anything. They’ve got full capacity to do anything.

John Curran: Yep.

John Sweeting: Hey John?

John Curran: Sorry. Did you want to speak to that, John Sweeting?

John Sweeting: Yes, I did. When we – the decisions we make in our meetings on any proposals are posted to PPML, and it was noted at that time that it was a petition point if someone wanted it here in Dearborn.

John Curran: Correct. You can petition and have a proposal brought here even if the AC does not act on it.

Center front.

David Farmer: So – oh, David Farmer, University of Minnesota, ARIN AC. There’s been several things that we’ve been doing lately to pay attention to the Caribbean. There’s some very interesting global political reasons that we do that. Should we set aside a special pool for them? Should we make a reservation for them? Because we could probably set aside a teensy-weensy little bit of space that would make a really, really big deal for the Caribbean and probably would be five minutes of runtime for the rest of the – for the U.S. and Canada.

John Curran: Okay. I will let people speak to this. I’m going to note that we have had – in fact, you’ll see a report on this tomorrow – we have had requests for special fees for various regions come in front of the Board of Trustees through the suggestion process, and we’ve generally turned those down, figuring that that is a social function for someone else to determine what represents good or an important need.

But on the area of addresses itself, that’s something for this community to discuss. So I see R.S., and then I see Marty. R.S.? And I see Bill.

Rob Seastrom: So in response to David, I think that while that’s a well-meaning sentiment, you’re basically handing those folks a millstone. And it almost feels like, you know, the shipping the garbage somewhere else sort of thing. And I don’t think that that’s in their best interest, or in the Internet’s best interest.

John Curran: Okay. Marty.

Martin Hannigan: Marty Hannigan speaking as myself and as someone who has some considerable experience in the Caribbean. They’re not teensy-weensy, for one. And there are some fairly smart folks down there that know absolutely and fully what’s going on with IP address depletion, and I think they’d be offended that we would try to give them special treatment like that. Thank you.

John Curran: Okay. Woody?

Bill Woodcock: I don’t know about offended, but I think that this is an issue that’s come up before with regard to Latin America and Africa right at the inter-RIR level. And I think almost everyone would agree that as a social matter that would be fair and just in some way, but that a higher fairness and higher justice is served by everyone obeying the same rules as we have all along. And, thus, the needs-based allocation policy that we have all worked under is something that I think we really have to work very hard to preserve at the end here as more and more people strive in their own self-interest; that if we become suddenly generous in contravention of rules that have protected us against self-interest for a long time, this opens a door to that very same self-interest on other people’s part.

John Curran: Okay.

Matt Pounsett: Matt Pounsett, Afilias. While I think it’s well-meaning to do more set-asides for that sort of thing, we’ve already set aside a /10 for transition technologies, and that’s going to serve areas that are developing just as well as they’ll serve Canada, the U.S. and other places in there that are already developed. We want those – you know, we want the Caribbean to move to IPv6 just as much as we want everyone else to, so I think it’s the transition stuff that will be helpful there.

John Curran: Okay, thank you. Microphones remain open. This is the open microphone session. Anyone want to bring anything to the mics? I’ll be closing the mics shortly. Leslie. Wow. That’s new and different. Go ahead, Leslie.

Leslie Nobile: It’s just a point of information. It was just a follow-up to Leo’s question today about multiple discrete networks. I did get the information, I just thought I should present it while I’ve got it. We looked back over the life of the multiple discrete networks in v4, and it looks like about 12 percent of all the approvals we do for ISPs are done under the multiple discrete network policy. When we look at the total number of orgs that have qualified, it looks like at least roughly 300 in the life of the policy.

John Curran: Got it, okay. Good to know. Microphones remain open. Remote participants, open microphone session. We’re closing the mics shortly. Microphones are closed. Any remote participants? No. Thus brings us to the close of today’s meeting. Thank you very much.

(Applause.)

Fill out your daily survey. You can get a prize tomorrow if you fill out your survey today. You’re actually sitting there, your laptops in front of you right now. I can think of a great time to fill out your survey. Yes.

Paul Andersen: Someone was busily typing.

John Curran: I figured that; that’s why I asked.

Go ahead.

Paul Andersen: Call in from Ted Mittelstaedt: Regarding the IPv4 to IPv6 transition, Thinnet Ethernet still works, but it isn’t used, the history of technical transition is that there are always much quicker people than people want to believe they will be. Comments like their IPv4 network will still work are just disingenuous. Yes, they will work for most things, but the time will come a lot quicker than people want to believe where they will be doing things that are on IPv6 that aren’t on IPv4. All it takes is someone large. Imagine for a moment if Disney suddenly started streaming ESPN on IPv6 only. Think of the transition from Betamax to VHS, from rotary-dial phones sold in stores to touchtone phones sold in stores, from glass picture tubes to flat screens in monitors and TVs, from mechanical-controlled auto engines to computer controlled. Sure, a lot of legacy, Betamax, rotary-dial phones, glass monitors and jalopies lasted past their transitions, but the transitions themselves happened very rapidly.

The computer industry, of all industries, probably embraces change the most. And without that industry, the Internet wouldn’t exist. The idea that the uses on the Internet are going to cling to IPv4 once they know IPv6 is available is ludicrous. They will want it even when they don’t know what it is.

John Curran: Cathy, do you want to respond?

Cathy Aronson: I do – Cathy Aronson – since I was called disingenuous. I just would like to say that my point was exactly what he said, that people are going to want to get to stuff that’s only on IPv6, and the networks that still will continue to work on IPv4 are going to have to translate. Otherwise, because they’re – I mean, they’re not going to readdress all their IPv4 instantly, either. So if you don’t have that kind of translation, then you’re in trouble whether you run out of address space or not. I mean, eventually there’s going to be stuff you can’t get to.

John Curran: Got it. Thank you.

Closing Announcements and Adjournment

John Curran: Okay, our meeting survey, fill out your meeting surveys. Our respondents will be entered to win a mini USB monitor. Very cool.Calling all the DMRs. If you have a designated contact for your organization, please vote now. Please vote online. We have elections for both Board and AC.

Sponsors. Would like to give one more round of applause to our sponsors.

(Applause.)

Reminders and recap. Breakfast starts tomorrow at 8 a.m. our meeting starts tomorrow at 9:00. We have a number of reports on how ARIN is run. The agenda for tomorrow’s meeting is in your folder or online. Tonight’s our social, a Night at the Museum. Join us at the Henry Ford Museum 6:30 to 10:30 for the ARIN social. There will be food, fun, and lots of cool stuff, dancing, alcohol. And I don’t know what other verbs to put in there. We’re going to have buses coming up to the lobby about 6:00, about. They’ll start loading. The first one is going to leave at 6:15. There will be a few buses. And then shuttle service back is 8:30 to 11 p.m.

Transportation to and from the social sponsor, UnitedLayer, thank you. Round of applause.

(Applause.)

Okay. See you all at the social tonight. Thank you.

(Meeting adjourned at 4:45 p.m. EDT)