ARIN XXVII Public Policy Meeting Draft Transcript - 12 April 2011 [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.

MEETING CALLED TO ORDER

John Curran: Good morning, everyone. If people would come in, we’ll get started. Good morning.

Some people must have had a great time last night, because they’re not here now. Okay. Welcome to our second day of ARIN’s Public Policy Meeting in wonderful Philadelphia.

I’d like to start out with some brief announcements and then we’ll get things going on some presentations including some policy work.

First, thank you for our sponsor, Comcast.

[Applause]

I’d like to point out today’s ARIN question of the day: How would you describe an ARIN meeting to someone who’s never attended? If you have thoughts on this, you want to be recorded for our video that we use for educational purposes, find someone at the break who says “Question of the Day,” you’ll have the sign, and you can be recorded and be part of our materials.

Okay. Open Community Survey. As I mentioned yesterday, as part of the periodic review mandated by the ICANN bylaws, they’re reviewing the Address Supporting Organization. The Address Supporting Organization is the organization within the ICANN bylaws responsible for coordination of address policy.

This organization is fulfilled by the NRO, Number Resource Organization. At the NRO we contracted with ITEMS International, a consulting firm with experience in non-government areas, non-government organizations. They’re here on site conducting interviews and promoting the survey. If you have a view on how the ASO is performing, I recommend you go to the ITEMS survey, items.fr/aso.php . It should be very brief. Less than five minutes.

Rules and reminders. Rules in your packet. The Chair will moderate discussion of draft policies so everyone can speak and be heard. State your name and affiliation each time you’re recognized at the mic. Please comply with the courtesies and rules in your program.

Today’s agenda. We have the IPv6 IAB/IETF Activities Report. We have the RIR Update. We have the NRO NC Report. We have an NRO and IANA Activities Report. We handled IANA yesterday. We have the Policy Experience and Implementation Report, and we have Open Policy Hour.

We also have a number of policies that we’re working on. Policy 2011-10: Remove Single Aggregate Requirement From Specified Transfer. 2011-11: Clarify Justified Need for Transfers and 2011-12: Set Transfer Need to 24 Months. Will be on today’s program during the morning block.

In the afternoon we’ll have three policies. IPv4 Number Resources for Use Within Region: 2011-13; 2011-1: The ARIN Inter-RIR Transfer Policy; and 2011-9: The Global Proposal for Post Exhaustion IPv4 Allocation Mechanisms by the IANA.

We’ll try to keep those policy discussions started at the appropriate time. That’s for the remote people who may not be able to attend the entire day.

Just make sure you get in before the start of the session and we’ll rearrange things to as much as possible accommodate.

Lunch table topics. During lunch you’ll find members of the AC stationed at certain tables with signs that indicate they’re interested in speaking about a particular topic. That includes some of the proposals coming up: ARIN Proposal 158, 151, 153, 157, legacy addresses in general, and what role should the RIRs play or will they play in the future.

If you’re interested in discussing one of those matters at lunch, find an appropriate table and you’ll find people of similar mind. Should be an exciting conversation in a lot of cases.

At the head table today, myself; Chairman Timothy Denton; Paul Andersen, Board member; we have Bill Woodcock, Board member; we have members of the AC: Bill Sandiford, Cathy Aronson, and Heather — and Heather Schiller in theory. I’m sure Heather’s coming.

I’d like to start out this morning to introduce the sponsor of this meeting, Jason Livingood. Jason Livingood is the Vice President of Systems Internet Engineering at Comcast Cable. He runs the team that’s responsible for managing and developing the company’s high-speed Internet service. Among his educational activities, he serves on the Board of Trustees of the Internet Society, he’s active in IETF, and he’s a member of ICANN’s Security and Stability Committee.

Come on up, Jason.

Jason Livingood: I’m told I have just two minutes. I’ll keep it very, very brief. First off, thank you everyone for coming to Philadelphia. We really appreciate the opportunity to host the ARIN meeting, particularly as it comes at such a critical time in the history of Internet addressing.

So great timing and pleased to have you here. Just a few very, very brief thoughts, and then I’ll let you get on with it.

First, the IPv6 transition. If it were easy, it would be done by now. So it is definitely not easy. And I see Geoff there. I’ll channel a little bit of Geoff because I like the message he gets across to really focus the community.

For vendors, we encourage you to work harder to deliver stable, reliable, mature code. It is not there yet. Keep working hard.

ISPs, we encourage ISPs to continue to work aggressively and in fact more aggressively on the IPv6 transition. And in part that involves taking more risks. Taking those risks now will mean less pain later. So that’s important.

And for ARIN, we think obviously you guys are a super important body, but I would say you cannot forestall the inevitable. Addresses are running out. In fact, this is probably right from Geoff’s yesterday, better that happens at the same time for everyone and everyone experiences this stuff at the same time, network operators and so on, the better.

The challenge in this transition is that it affects all different parties at all different times. And that lack of cohesiveness in facing this challenge is very, very difficult. And so I promised my team I would wrap this in, but working together at the same time on the v6 transition is incredibly important for network operators, because if you don’t work together it will be even more challenging to sort of revolt against the tyranny of shared addressing and declare independence from network address translation.

So that’s all. Thank you very much for coming. Appreciate it, everyone. Thanks.

[Applause]

John Curran: Very good. We are moving right ahead. We have the NRO Number Council Report to be given by Jason Schiller.

NRO NC REPORT

Jason Schiller: So what is the NRO, the Number Resource Organization? Well, it’s where the five RIRs come together and speak with a single voice. It consists of two parts: The Executive Council, which consists of the five RIR presidents, and that speaks with one voice on behalf of the RIRs; and the NRO NC, the Number Council, which is made up from the community. It has two elective members and one appointed member from each of the five RIRs, and it primarily performs the function of the ASO AC.

So here’s a list of all the 15 NRO NC council members. In the ARIN region we have Louie Lee, who is Chair. We have our appointed member, Ron da Silva, and myself.

So what does the ASO AC do? Well, we appoint Seats 9 and 10 for the ICANN Board of Directors. We appoint a representative to ICANN for the NomCom. And we objectively process RIR-related global policies that are submitted from the community. So we ensure that they’ve gone through the policy development process and that the same text has reached consensus in all five regions.

We also offer advice to the ICANN Board on RIR-related issues when they ask us for clarification. And, lastly, we define our own operating procedures.

So what’s recently happened since last we met? The NRO NC, we’ve had some elections. Ron da Silva has been reappointed for the ARIN region. Tomohiro has been reelected for APNIC. And we have a new member starting in January, Alejandro, for LACNIC. We’re beginning our selection for Seat 9 for the ICANN Board, and we recently updated our procedures for the Board selection process. That’s pending approval of the Executive Council.

We elected Hartmut Glaser for the NomCom, and we also put on a workshop at ICANN 41.

So besides electing seats for the ICANN board, the other important function we do is we look after global policy proposals. In this case there’s two that are worth discussing.

I’m going to use the global policy numbering convention, which is GPP-IPv4-2011. This is the global policy for post exhaustion IPv4 allocation mechanisms by the IANA. This is the ARIN Policy 2011-9, which we’ll be discussing here today.

Just wanted to remind you all that it’s in last call in RIPE, last call in AFRINIC, and has been adopted and is pending ICANN ratification — I’m sorry, last call in AFRINIC, and adopted pending ratification in LACNIC and APNIC.

And there’s a URL at the bottom, which is the official ICANN URL that tracks the status of this global policy proposal.

You’ll also recall that a year ago there was another proposal on this same topic, GPP-IPv4-2010. This one was known in this community as ARIN 2010-10, which we adopted but no other community did. So hopefully if the other policy goes forward, we can actually abandon the previous adopted policy so we can get this off of our docket.

There’s also some reviews going on. As you’ve heard a couple of times during this meeting, there’s an independent review of the ICANN ASO AC and there’s been a call for survey participants. So web-based survey takes five or ten minutes to fill out.

You have until the end of the month to do it and the URL is here as well as other places that you’ve seen. So if you’re familiar with the ASO AC and the memorandum of understanding, please go visit that URL, fill out that form.

We’re also involved in some of the ICANN review teams, such as SSR, which Hartmut Glaser is sitting on, and the Whois policy, which Wilfried is sitting on.

So, lastly, just wanted to thank you for your attention and your time. I wanted to remind you to not forget to vote. There’s a vote that’s open right now for designated member representatives for the ARIN Advisory Council and the Board of Directors. We’re not voting this year for an NRO NC member because it was an appointment year, and I remind you that Ron da Silva was appointed.

[Applause]

John Curran: Okay. We also have a report this morning from Cathy Aronson. She is going to give the IPv6 IAB/IETF Activities Report.

IPV6 IAB/IETF ACTIVITIES REPORT

Cathy Aronson: This is going to be the report for — I just went to the IETF in Quebec City, which is just a wonderful place. So here we go.

This is my official disclaimer. It’s slightly different than previous years, but this is just things that I thought were interesting. The meeting is huge. The hours are long, and it’s hard — almost impossible to cover everything.

If you were there and I missed something that you think is important, don’t be shy. Because there’s just — it goes from — it’s long days.

Anyway, so some highlights. Wow, I guess I got spiffy with the thing. This draft, if you haven’t read it, I hadn’t really thought a lot about assigning humongous blocks of address space in IPv6 and any of the really interesting consequences that that might have for us.

But Igor has this draft talking about so you assign /64 for a subnet that maybe has five or six things on it, which is kind of insane in and of itself. But and then somebody — maybe they port scan you, and there’s bazillions and bazillions of addresses that it’s scanning. What does that do to your equipment? Does it make it melt down? Should there be things that your equipment does to respond to that, like maybe prefer the things it’s seen before instead of filling its table with things that it can’t get to.

So, anyway, it’s really an interesting thing to start thinking about, because as we do assign these ginormous subnet sizes, it really does have impacts on things that maybe we didn’t initially think about, and I found it really to be a really interesting topic.

As — you know, everyone stole my thunder yesterday, right, because we talked endlessly about the shared transition space draft. That’s in the IETF last call, which it was pretty well received at the working group meeting. I thought people were going to be yelling, but they were like, oh, what a great idea, I think we should do that.

Anyway, we already talked about that. There’s a new group or a relatively new group talking about Whois extensions, and a bunch of the ARIN folks were involved in that. I don’t know if we’re going to be talking about that at all here. But it’s an interesting draft.

And I started a new category. Because last time, I don’t know if you remember, but there was a fellow from Reuters who came to IETF to make OSPF faster because they had to make trades in millisecond increments. So this time the most interesting speaker was a guy from Blue Cross/Blue Shield somewhere in the Midwest who was proposing that IPv6 have this identifier field because he needed it to debug his network.

It just seemed so out of character. So I have a new category. So hopefully next time there will be an even more interesting, strange, out-of-context speaker at IETF.

Let’s see. So there were endless updates about IPv6 Day. And if you guys don’t know, if you go to IETF, there’s a little-known meeting that’s been going on for 20 years called the IEPG, the Internet Engineering Planning Group, and it’s a bunch of operators who get together the day before and talk about things.

So these are some of the take-aways from the presentations about World IPv6 Day, and even though the IETF is trying to deprecate 6to4, it seems like there’s a lot of it, and if you’re going to do v6, you kind of need to have some relays that are close by.

Let’s see. And then there was an — ISOC put together an IPv6 workshop, and I think the most interesting thing from that is Geoff Huston was the optimist — [laughter] – on the panel and it was pretty entertaining.

And so these are some of the interesting quotes. Success, disaster was pretty good.

And I think that this one’s really important. There is a chicken and egg problem, because the providers are saying the customers aren’t asking for it and the customers say the providers don’t have it.

So I’m not sure how we get there from here. And the workshop never really has any conclusions. But Geoff as an optimist was pretty fabulous.

The Internet area didn’t meet in Quebec, but here’s some of the drafts that you might want to look at. Let’s see. This is all about v4 to v6 multicast. Actually some of these discussions were really interesting. If you do multicast, there’s a whole lot of work being done right now on that.

So Renum, the IETF before was a BoF and they are trying to decide whether to become a working group. And they did. Now there’s some drafts. And I still think that renumbering is going to have to have to happen in v6 but, boy, it seems like a really big problem.

There’s several things going on right now with green traffic engineering, like how do you optimize power and — which is pretty cool.

Then there were more updates about World v6 Day. And it seems like it went pretty well. So there’s a draft out about it, which is pretty interesting. And some of the sites are still up. And like Xbox, I think they left their v6 up and a lot more of the websites are reachable still.

Lots of 6to4 traffic. Oh, yeah, 50 percent left their AAAA records in place, which is actually pretty nice.

And just so you know, there are 40 v6 ops drafts right now, docs, so it’s hard to cover all of them, but there are a lot of things going on in v6 operations, so if you’re deploying v6, you should probably follow that sort of thing.

This is the SIDR, the securing — the BGPSEC draft is done, so that should start moving along. Maybe we’ll start seeing deployments of that.

So this is more of the 6man, which is the maintenance stuff, and they’re looking at more energy-aware device stuff. And another one of those problems, like I said, like in Igor’s draft, is unreachability detection, how much should you try, and if you have these huge subnets, how many of them. It’s kind of starting to fascinate me what we did to ourselves by making these huge chunks of address space.

And then the shared transition space draft is moving forward. And, yeah, one of the concerns that came up about the draft is that since the block is in essence RFC1918 space but it’s not known to devices as RFC1918 space, will they act like it’s really globally routable space and start trying to use 6to4, or whether they’ll have to have their code changed and whether that will be a problem, was one of the big concerns that came up and no one seemed to have an answer for that.

Let’s see. There’s some DNS work going on. I like this quote, “There’s a difference between being incomplete and being wrong,” because when you’re doing a lookup, if it’s an incomplete one or if it’s a wrong one, so, anyway, you had to be there, I guess.

I don’t know. The quotes weren’t as good and I had a pinched nerve in my neck, so I wasn’t really super happy at IETF. So I didn’t get as many happy, funny quotes as I should have.

Let’s see. These are some of the things going on in Behave that you might want to take a look at. And then does anybody have anything that I missed or questions or — this is my favorite street sign from Quebec. I think that maybe folks might not get it here.

No right on red. Right.

Oh, I’m sorry. Owen DeLong.

Owen DeLong: Owen DeLong, Hurricane Electric. On the comment about the shared transition space not being recognized by home gateways, that is a problem shared by all of the alternative solutions that will be deployed if this draft doesn’t move forward. So this draft is kind of the worst solution to that, except for all the others.

Cathy Aronson: Okay. And just anybody else? These are where you can look — like I said, in a group that has 30 drafts it’s just super hard to list all of them. So this is where all the interesting bits are.

John Curran: Thank you, Cathy.

[Applause]

John Curran: Thank you, Cathy. Good update of IETF. Difficult to take a week packed full of sessions and pack it into this. You did a good job.

We’ll move the APNIC Update up, and we’ll have the illustrious Geoff Huston come up and speak.

RIR UPDATE - APNIC

Geoff Huston: Good morning, all. About the only thing I recognize about this slide pack is my name and the city. I haven’t seen it before either. So it’s going to be as much as a surprise to you as it is to me.

We gave out some resources. We gave out more last year than this year because we ran out this year. And that’s the v4 ones. We’re still giving out lots of v6, but interestingly we gave out more last year than this year. That’s actually in number of folk coming to the door.

So we ran out of v4, and we gave away less v6. This industry’s weird. And we gave out less AS numbers as well.

I’d like to blame it on Greece, but we’re not European, so I’m not sure exactly who to blame it on. But we gave out less.

We’re now in our final stage. We ran out on the 15th of April with much fanfare. We’re now working out of 103 /8, and everyone gets a phenomenally useful 1,024 IPv4 addresses, and that’s it for their life.

Since then we’ve actually given away 583,000 addresses into 30 economies. And, interestingly, again, I’d like to blame it on Greece, but I can’t.

A thousand addresses isn’t really that useful unless you’re tiny or desperate. And the number of small, desperate people appear to be finite because there are fewer and fewer of them every month except in August.

So it’s kind of fascinating that the use of that last /8 is actually declining over time. We’ll see what happens. But that’s an interesting phenomenon.

What have we implemented as policies? Despite the fact we’ve run out of v4 addresses, the policy folks still believe there’s a phenomenal amount of work to do. So they’re busy polishing the engine.

When — revise the distribution of IPv4 addresses once the final /8 period starts. I think we now allow anything between a /24 and a /22, from memory, which is also Policy 93, the minimum delegation size, and we’ve removed the renumbering requirement; you don’t have to renumber to get a thousand addresses. We’re generous folk.

And in August we implemented two more, the alternative criteria for subsequent v6 allocations, and we’ve also been working through on the Inter-RIR IPv4 address transfer proposal, because there’s a bit of a refinement to that which has been something that reached consensus in Busan in August at our last meeting, where we’ve now decided as a policy group that we’re going to maintain demonstrated needs requirement in our transfer policy.

So that’s in the final stages of comment on the mailing list and will be approved by the Executive Council of APNIC in due course.

Did not reach consensus and politely has been returned to the mailing list to figure out why not.

A proposal for allocation of countrywide IP address blocks. I think it actually means IPv6, because there are no v4 addresses left in APNIC.

And, similarly, a very similar one, 99, IPv6 reservation for large networks. And Proposition 98, optimizing v6 allocation strategies. None of those actually reached consensus. Wow, this is about me. Like I said, I’ve not seen this slide pack before. So definitely down in the labs we’re working very, very hard.

You might be interested, we’ve been doing a huge amount of work trying to measure v6. And some of this work has actually been in terms of putting JavaScript on websites. Which a lot of you don’t like doing, I can understand why, but, interestingly, most of you will put Google Analytics on your website.

If you’ve already got Analytics and you want to know how many folk could use v6 of the folk who visit you, if you were dual stacked, so it’s a hypothetical question, go to Labs and get a little add-on to Analytics and add it on to your web page. And then you will know, which is good, and you will help me to know more, which is even better. So we’ll both be happy. So labs.apnic.net. Check it out. And take that bit of JavaScript and paste it in with your Google Analytics, and we’ll be happy people.

The Innovation Society Information Fund. This is something we’re really proud of. It’s been going for some years now, initially with a lot of help from the IDRC of Canada. It’s a small-grant awards program and it’s basically a very stimulating and creative solution in IETF needs across the Asia Pacific region. So this year 23 projects from 12 Asia Pacific economies. And they really are quite diverse and really quite wonderful. I encourage you to go down to the APNIC website and search for ISIF and have a look.

We held an awards ceremony in Nairobi in September just a few weeks ago, well attended and fascinating work. So we’re going to do more, because it’s really very good, and also LACNIC and AFRINIC are now getting involved as well with the IDRC. We’ll expand it a bit more, and we’re also as usual looking for sponsors because there is a really big creative world out there of folk who are doing amazing things with the Internet and ICT, and assisting them to get this going is really quite a great job.

Time for a new logo. Lots of brackets, lots of buttons, lots of colors, lots of everything.

You heard yesterday that you guys are endlessly distracted by color and motion. So we thought we’d do a logo that endlessly distracts you with color and motion. There you go. Just for you we did this.

Next on the world tour APNIC is off to India in the last week of February, first week of March, which is much better than being there in July because it’s a lot cooler in February than it is in July.

If you want to come to India see such delights as the Red Fort, the Red Fort is really cool. Yes, you should come along because that’s a great place.

Thank you very much. Any questions?

[Applause]

Geoff Huston: No questions? Thank you.

[Applause]

John Curran: We find ourselves moving briskly ahead on today’s schedule, in which case I will probably ask to have Raúl come up if he is available. Raúl, are you here? Can you give the LACNIC update?

RIR UPDATE - LACNIC

Raúl Echeberría: Thank you, John. I’m always available, but it’s a different price now. Okay. Good morning, everybody. I’m Raúl Echeberría this year from LACNIC. I will present the LACNIC Update Report.

So, please, I will use my video authenticator.

So first news is we announced this last week during LACNIC meeting in Buenos Aries we reached 2,000 members, which seems to be fantastic if we consider that when we started in 2002 with all the adding in the process of creating LACNIC we had less than 100 members.

As we had doubled the number of members in the last two years, for this I want to believe that LACNIC has something to do in this regard, but also it shows a different growing rate of the Internet in Latin America. Very good news, too.

Regarding the resources that we have at this moment, we have in our stock four /8s, 68 million of IPv4 addresses. It is available in real time online. So you can check the number of IPv4 addresses that we have.

It is important to remark that we have in place now a policy for reserving the last /12 only for new entrants. And I will comment about the new policy that has been approved in the last week in Buenos Aries.

As I said, the report is of IPv4 addresses is available in LACNIC and other resources available online so you can check it when you want.

Next one, please. Here you can see the IP addresses that we’re locating in LACNIC. So the red part of the bar is the IPv6. So I think that it is interesting to see the number of IPv6 addresses that we are allocating in comparison with IPv4 is growing and is significant.

And the other — the second graph is just the IPv4 addresses allocated in /8. So we are locating now approximately one /8 per year.

Thank you. This is ASNs. And I think that Leslie already commented on that yesterday, but the number of ASNs – 4-byte ASNs that we are allocating is much bigger than the 2-byte ASN.

And so I have to add that we have very few cases in the region of people coming back to change the ASNs and ask for the 2-bytes one instead of the 4-bytes that they received. It seems at least this part of our work is going quite well.

Next one, thank you. Some important projects in which we’re involved in now. Customer service. We are — this is across areas project; that is, all the organizations, all the companies are introducing or strengthening the orientation to the customer.

It means just — it changes of IT solutions but also training as working in in-house workshops, and many activities are related with this project that has been successful last year — this year, sorry, as we expect to continue working in this direction next year.

RPKI. We are working with — we are already in production phase. The system was launched in January of this year, as agreed with other RIRs. As we are working now in a hosted model as we expect to be able to move to — for us to work in a delegated model at the end — before the end of this year. We are working very close with RIPE NCC and with some developments they’re doing.

DNSSEC, we have signed already the parent zones, but we are doing some checks still. And the child zones are expected to be signed before the end of the year.

And IPv6, of course, is one of the things that are consuming more resources and time in LACNIC. As we continue doing workshops, research and development and virtual seminars, that has been very successful as we are working with different stakeholders, governments, ISPs and just doing similar things that the other RIRs are doing.

We continue working with a very successful project that is AMPARO. And the objective of AMPARO is providing training to promote the creation of CSIRTs. We’ve issued a set of materials that are for public use for supporting the creation and operation of CSIRTs. They’re available today in Spanish, but we’ve translated those materials to English, French, and Portuguese in the next few months.

So they will be available for a big part of the world. I think that there are no presence of materials like those available for public use.

It is not a competition with other different models of working in this topic. But I think there are things that complement very well with each other since they are — so far they are not very advanced materials, just basic materials, and so people that use those materials probably go later to other places for getting more training and some certifications that is something that is not in our plans until now.

We have the first meeting with CSIRTs in Latin America last week in Buenos Aries. It was a very promising meeting. We had eight or nine CSIRTs from different countries that are very able to and very willing to coordinate with each other.

And I think that this is just the beginning of something that will be very interesting in the next future as we have created an email list for providing the space of coordination and some — a new meeting was already agreed for being held together with LACNIC meeting next year in May.

We continue working also with FRIDA program for this similar — it’s being done by APNIC with ISIF. We have worked with FRIDA with this program for six years. Now we have spent more than $1.5 million funding research projects in Latin America, related with ICTs, and now in the last two years we have introduced this FRIDA award that is similar to the ISIF one.

The projects were — the award was presented last week as one part of the prize was to the fellowship for these people representatives of those projects to attend IGF in Nairobi, a very good experience.

We have very interesting projects that were awarded. But I will not talk very much about that. We continue working in setting up copies of root servers in Latin America. We plan to do two more before the end of the year.

We have launched last year and we are working now in promoting this with our members a new system for managing internal resources named SARA, a system based in EPP, and it permits to compatibilize the systems that are used for internal management of IP addresses in the ISPs with our system very easily.

The past meetings: LACNIC 15 was held in Cancun, Mexico. We had almost 300 participants from 32 countries. Seven policies were presented. Three reached consensus and have already been ratified.

And last meeting was last week in Buenos Aries, Argentina, together with LACNOG. I don’t think we can say it’s held back to back, because it’s not. We don’t organize one meeting first and the other later as you do between NANOG and ARIN.

There are activities of LACNOG and LACNIC all the week and combined — for example, one morning there’s a LACNOG meeting and a LACNIC meeting in the afternoon. So we take advantage — both meetings take advantage of the presence of the people that is interested probably more in the other one.

We have 340 participants for this. I’m not sure, but probably it’s a record for us. From 28 countries. Six policies were presented and three reached consensus.

Next one, please. The policy that got consensus in LACNIC XV, I will not speak very much about that because Einar has covered that very well. But so next one, please.

And those are the policies that reached consensus in LACNIC XVI last week. And so one is for asking for additional allocations of IPv4 addresses now if this policy is finally adopted and ratified.

The ISPs will have to present — they will have to ask for IPv6 addresses if they don’t have yet. And if they already have IPv6 addresses, they will have to present a very simple report about what is status on IPv6 adoption, what will be very useful for us for elaborating some reports and doing some survey for that information.

It will be very simple just for not introducing any complication, any obstacle in the process of the IPv4 address allocation. But we are — at least the authors of this proposal think that it will be a time for reflection of the ISPs that we have to take some time for completing the report and look about what they are doing.

The second one is a policy that will apply only in the last phase of IPv4 allocation in LACNIC region when the last /12 is — when we are making allocations from the last /12, and it is something similar. It’s also for first allocations that are made in that time. They will have to request IPv6 addresses at the same time.

The last one is for introducing — it’s like — it’s just for reserving another /12 with less restriction than the last one, but it’s for having — I lost the expression. A slowdown or a smooth finish off IPv4.

Those are now for — will enter in the last call for comments period, and then after that the Board will have the responsibility of ratifying the policy or not.

Next meeting, LACNIC XVII will be in Quito, Ecuador, and our May meeting is a meeting that is organized together with other organizations. We have the ccTLD’s association meeting and Interconnection Forum, IPv6 forum, security forums. Many activities held with LACNIC meeting during that week, and it will be held in the week of May 6 in Quito, Ecuador. Quito is a very nice place. By the way, have a very — very interesting city.

And the second meeting of next year will be held in Montevideo 29th of October to the 2nd of November 2012. And it will be again a meeting organized together with LACNOG 2012 in this case and it will coincide with the tenth anniversary of LACNIC. LACNIC was recognized as the four RIRs at the moment, the 31st of October of 2002.

So it is a very happy coincidence that the meeting will be held exactly in the date that we will make the tenth anniversary.

Okay. That’s all. Thank you very much.

John Curran: Questions for Raúl?

Raúl Echeberría: Easy questions, please.

[Laughter]

Cathy Aronson: I’m not sure if this is really necessarily for Raúl, in particular, but I’m just mystified by the 4-byte ASN thing. You guys assigned a ton of them. And we can’t practically give them away in the ARIN region. Isn’t it just one BGP system? So why is it that they work in Latin America but not in the United States? Does anybody have any insight?

Raúl Echeberría: That’s not for me.

John Curran: I think we should think about it, and then today at the Open Mic I’d like to have people up at the microphones explain why 4-byte ASNs do better outside of the ARIN region.

Thank you, Raúl.

[Applause]

John Curran: Okay. We’re going to move into the policy development section of the agenda. The first policy up is Draft Policy 2011-10: Remove Single Aggregate Requirement from Specified Transfer.

ARIN-2011-10: REMOVE SINGLE AGGREGATE REQUIREMENT FROM SPECIFIED TRANSFER

John Curran: The origin of this was ARIN Proposal 144. Introduced in May 2011. The AC shepherds are Scott Leibrand and Stacy Hughes. AC selected as draft policy in August 2011. The current version is the 24th of August version of the proposal. The text and assessment are online and in your Discussion Guide.

2011-10 summary: The proposed policy would remove the phrase “as a single aggregate” from the existing NRPM 8.3 policy, thus allowing the transfer of multiple prefixes during an 8.3 transfer.

Nothing similar at other RIRs.

Staff assessment/concerns. This would eliminate possible confusion and align the text with current implementation whereby transfers can invoke multiple discontiguous IPv4 address ranges in a single transaction with ARIN.

Implementation and resource impact. Minimal.

Legal assessment. Counsel affirmatively supports the change. We do not see it as creating any additional legal liability. Given the myriad of factual situations that may arise, a single aggregate requirement could prove too rigid and could prohibit an overall good policy result.

PPML discussion. Little discussion of the draft policy. A couple of posts in support of the original proposal. One against.

That concludes my introduction of this policy proposal. I’ll ask Scott Leibrand to come up and give the AC presentation.

Scott Leibrand: All right. So why are we doing this? ARIN has received a number of otherwise legitimate requests to transfer multiple IPv4 netblocks. Some of these transfers were ordered by bankruptcy court, others were simply requests, as far as I know, haven’t hit the news, anyway.

To date ARIN has interpreted the 8.3 single aggregate requirement to apply to the justification and not to the actual transfer itself. That has resulted in what we see in the list of blocks that have been transferred. If you go to the recently announced list, you will see all of the couple dozen blocks that have been transferred to date.

Our policy is a little bit out of match with the actual requests that are coming in and the requests that are being approved by ARIN, at least by a more or less standard reading of it. So we want to fix the policy somehow, and this is a proposal to do that.

The proposal says strike these words, strike “as a single aggregate” and strike “exact.” That’s all we’re changing.

Benefits of doing this is that it would allow legitimate transfers involving multiple networks to occur as a single transaction. If this were strictly interpreted, you might be able to come back and do repeated transfers for all the blocks you wanted to do. There’s no particular restriction against that. That seems like additional overhead.

It avoids putting ARIN policy at odds with legal requirements. When a bankruptcy court orders a transfer and ARIN says our policy doesn’t allow that, that puts Steve in a very bad position.

It simplifies policy, reduces confusion. There’s quite obviously a difference of interpretation between what most of the members of the community thought single aggregate meant and what ARIN has interpreted it to mean.

And this would clear that up. The only real drawback possibly is that if we allow transfers in multiple smaller netblocks, we might increase the number of routes in the global BGP tables. That’s a concern some have expressed.

I personally think that that is not as big a deal as maybe it used to be. We had a presentation on the CIDR report, and one of the pieces of feedback there was that people simply don’t care enough to go spend a lot of time and effort and social pressure trying to get the number of routes in the table reduced. This may not be something that needs to drive policy any longer.

We may be able to optimize the policy for the issues at hand. So staff and legal made an assessment. We saw a summary of that. And this more or less repeats it.

Basically staff and legal both seem to be in support of this to the extent that they support things in the policy process. It would eliminate confusion, align the text with the implementation, and would resolve some legal issues without creating any additional liability.

So the interest slide is probably not very interesting, but I anticipate this discussion will be. So let’s start. No tomatoes, please.

Owen DeLong: Owen DeLong, Hurricane Electric. I’m actually no longer sure whether I oppose it or support this policy. I oppose it on the basis that the implementation is contrary to the intent of the prior wording, and I think the appropriate step to take in that case is to correct the implementation and do what we need to do to the wording to cause it to force the implementation that was desired by the community.

On the other hand, it’s starting to become clear that table exhaustion may become a better motivator for v6 than address exhaustion, and passing this policy will help get us to table exhaustion much faster. So this might be a good thing for v6, and so I might remove my objection to the policy as a result.

Scott Leibrand: So you’re telling me my drawback needs to be a reason to support it?

Kevin Blumberg: Kevin Blumberg, The Wire. I’m in support of this proposal. The less areas that people use to go outside of 8.3; the better. This will allow 8.3 to get used. It will get used more often and people will stop coming up with innovative ways of doing things behind the scenes. I expect that the disaggregation will happen irrespective, through rentals, through a whole bunch of other means. If we can actually properly put it through 8.3, it will solve a lot of problems.

Tim Denton: Marla.

Marla Azinger: Marla Azinger, Frontier Communications. I support the policy. I think it’s needed. It’s — I know there’s the fear factor, but I try not to buy into the fear factor as much as the US is really good at doing. And I don’t think we’re going to have as much of a problem as we fear because we all are aware of the routing table that operate networks. And we don’t want to see chaos happen, so I think there will be monitoring on that side of it. And having policy that at least permits it where it’s needed needs to occur.

Tim Denton: Jason.

Jason Schiller: Jason Schiller, Google and the NRO NC. Plus one on concerns about the routing table. Google being default free, certainly I have concerns about the size of the routing table. Not as many as I had as with my previous employer. However, it’s worth noting that even if Google is not affected by having a routing table which is too large, if other players are, that’s not good for the Internet as a whole nor is that good for Google.

So I think the first part of what Owen said, which was if we are going to fix this, we should try to meet with the original intention of the policy proposal was, which was to discourage massive fragmentation of the address space. And there is a proposition which I believe we’ll be able to talk about at some point in the near future on this topic.

I wanted to bring up one other point to an objection which actually hasn’t been raised at this point but I expect will be at some point; that even if we write policy to encourage, to give ARIN staff the ability to prevent massive fragmentation of the address space, then it may not be enforceable.

That very well may be true, but that being the case, at least having the fragmentation and the deaggregation concerns documented gives someone like myself of a technical nature the ability to stand up within my company and argue against doing a policy or doing an action that is for the good of the community. And without that language, I don’t really have or other people like me don’t have a leg to stand on.

I also wanted to bring up a third concern, and it’s not clear to me from this policy if it would be possible to transfer a fragment smaller than what is the minimum allocation size in this or some other region.

And I would like to ask ARIN staff for clarification if somebody wanted to use this policy to transfer, say, an IPv4 /32, what would staff do in that case?

John Curran: Only to the extent that a piece of the — to the extent they can justify such an allocation under NRPM as an allocation from ARIN, then we can approve it as a transfer. Otherwise we can’t. So an attempt to transfer a /32, for example, is right now not possible to my knowledge under NRPM. I’d have to go look at critical infrastructure really carefully, but I don’t think it’s possible.

Scott Leibrand: Jason, a follow-up on your second point. Are you asking for a “you should transfer the smallest possible block” type of suggestion, or are you asking for an unenforceable must?

Jason Schiller: Yes.

[Laughter]

John Curran: So it’s your database. I assure you that we will make transfers of resource blocks in the database based on the policy that you folks pass.

So it’s highly enforceable what ends up in Whois. What’s not enforceable is what ends up in routers. And that never has been, actually. You guys configure your routers with whatever addresses you want and you believe what other people say if you so choose.

But we will obviously maintain the database according to the policies you adopt. We were founded to do exactly that. So no problem maintaining the database, just recognize that the Whois database may not be ultimately the only thing going on out there if you make policies that people can’t live with.

Tim Denton: So Mr. Ryan moved first, then Geoff.

Stephen Ryan: So I want to gently remind people that when they speak at the microphone and identify themselves as from a company, the public policy description of why you oppose or support a policy should not be particularly related to an individual company.

If, for example, you believe it might address an issue for large ISPs versus small ISPs, then it’s perfectly appropriate to say large ISPs versus small or for a particular segment of the community.

But I would prefer that as comments are made that they not be identified to companies. And I think that’s an important dialogue point that we just need to occasionally be reminded of. Thank you.

Tim Denton: Thank you, Mr. Ryan.

Mr. Huston.

Geoff Huston: Geoff Huston, APNIC. I feel a bit like that Mark Twain quote, “Reports of my death have been greatly exaggerated.”

Some basic facts about the BGP routing table over the last seven years are that reports of its meltdown are greatly exaggerated. What I’ve been doing is looking at a number of dramatic or large-scale sources of BGP, both IBGP and EBGP. The level of table growth over the last seven years is only 10 percent per year.

Moore’s law is much higher than that. The routing table is not growing in absolute size to any concerning level whatsoever.

More fascinatingly, the amount of dynamic activity in BGP, the number of updates, hasn’t changed for the last seven years.

So if you really think that the BGP table is teetering on the brink of disaster, you’re doing something wrong locally. Because the rest of the world actually isn’t there or anywhere close to it.

So while, of course, you may unleash a few million routes on the network and completely alter this, whatever we’re doing out there and into domain routing is actually working remarkably well, and I would certainly not say that that particular concern should be an overriding concern in any particular issue of determining policy for which in this case I’m neither for nor against it because I work for APNIC.

Tim Denton: Thank you, Mr. Huston.

Any other speakers? Yes, we have one remote. Please.

Bill Sandiford: Two comments from the Jabber. David Williamson from Microsoft Tellme says: I support this as written. This makes practical transfers easier to handle within policy, and that’s a good thing.

And Jack Stevens from CenturyLink says: Ditto.

Tim Denton: Well, I think we’re about ready to move to a vote.

So we’d like to have a show of hands of those who are in favor of the policy as written. And, in the usual manner, raise them high and keep them up.

Now those who are contrary minded and feel the policy should not be supported as written, would you please raise your hands.

Tim Denton: Thank you, Bob. So in relation to the matter of 2011-10: Remove Single Aggregate Requirements for Specified Transfer, the total number of people in the room and meeting remotely were 133. Those in favor were 41; those against, 2 brave souls.

So it is sent to the Advisory Council accordingly. Thank you.

John Curran: Thank you. Moving right ahead. The next policy up for discussion is Draft Policy 2011-11: Clarify Justified Need for Transfers.

ARIN-2011-11: CLARIFY JUSTIFIED NEED FOR TRANSFERS

John Curran: The history of this policy proposal is it started as ARIN Policy Proposal 146 in the May 2011. The AC shepherds are Chris Morrow and Dan Alexander. The AC selected it as a draft policy in August 2011. The current version of the text is the 24th of August. And it’s what you’ll find online and in your Discussion Guide.

Summary. The proposal would modify the existing NRPM Policy 8.3 to state that all organizations can justify a 12-month supply of IPv4 addresses.

Currently, the only reference to a time frame in 8.3 transfers is contained in NRPM 4.2.2.4, Subscriber Members After One Year, which states that 8.3 transfers are exempt from the three-month supply limitation that all other ISPs who are requesting additional IPV space must adhere to.

Quote: An organization receiving a transfer under 8.3 may continue to request up to a 12-month supply of addresses.

This proposal would remove this reference and instead add the 12-month language to the proper section of the NRPM.

Nothing similar in the other RIRs.

Staff comments, issues, or concerns. This proposal would still require an organization requesting an 8.3 transfer to qualify for space but would exempt them from the three-month supply limitations currently set forth in NRPM 4.2.1, Slow Start, and 4.22.13, Three Months, instead of allowing them to qualify for a 12-month supply of IPv4 address space.

If this became a policy, it would align well with NRPM 8.2, Transfers Due to M&A, since staff uses a 12-month utilization window when analyzing these types of transfer requests.

Impact. Minimal. We’d have to update the guidelines and staff training.

No significant legal issues.

PPML discussion. Little discussion of the draft policy. Earlier discussion of a proposal resulted in 108 posts by 19 people. Two clearly in favor and two clearly against.

“Loosening the transfer rules serves to help ensure transfers go through the RIR and are properly cataloged. More stringent transfer rules help to promote alternative approaches to acquiring IP resources that don’t necessarily get cataloged.”

Another one of the representative comments: “Give bigger chunks of scarce IPv4 space to new entrants simply because I can afford it and have taken the time to find it, insufficient information at best.”

That concludes the staff introduction to the policy proposal. I’ll now ask Chris Morrow to come up and do the AC presentation.

Chris Morrow: Good morning. So I think this is — I have a little clicker thing. Awesome. Basically it just moves a set of language around in the NRPM. That’s the easy part. The more complicated part is the discussion about dealing with new entrants who have no real history. So we can talk about that at day end.

And I think there’s also some discussion from staff and other places about this really sort of aligns what we are currently doing anyway. So seems like making the policy and what actually happens be the same thing would be in our best interests. And that’s it. Those are my two slides.

Tim Denton: Okay. The microphones are now open for the thundering herd of commentators.

Mr. DeLong.

Owen DeLong: Owen DeLong, Hurricane Electric. This doesn’t align with what we’re doing now, and in fact what it does do is allow you to bypass slow start if you want to go buy space instead of getting it from ARIN.

I don’t think bypassing slow start is a good idea. I think slow start is good policy that is there for a reason, it’s been there for a long time, it’s worked well for the community, and I think it should be preserved.

Tim Denton: Thank you.

Ms. Azinger.

Marla Azinger: I don’t support this policy as it’s written. One, slow start is kind of related to brand-new companies, and that might not be the case of what’s going on here.

Two, the three-month rule we’ve got going is killing me. It’s not very comfortable for other people as well when you’re having to go back every three months for address space.

This is saying a 12-month, which, if you actually are trying to manage a large enterprise or network, 12 months is still way too short. You actually need stability. You need to be able to plan for actual growth and make things go on a stable manner.

So I would much rather see that jump more up to 36 months than 12 months. It just isn’t supporting what people need to be able to play on.

If we run out of address space, well, yeah, that’s coming. So at least open it up, let people plan with stability.

We had more stability before we started messing with the policies a year and a half ago. Now it’s even more unstable, because we have these short-term justifications we have to keep redoing, and it’s very time-consuming and you don’t have stability.

Tim Denton: Thank you. I saw you guys in order front to back. Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I’m not sure I support this exact language, but I support the idea of loosening up slow start. While I respect the original intent of it, we’re in a different era, and I still believe we need a needs basis.

But what needs basis means needs to change with the times and needs to meet the realities of the current situation.

And I personally believe slow start in its current incarnation does not meet the needs of our community and creates an unnecessary burden on new entrants when there’s already an extremely high burden on them in the fact that we’re almost out of addresses and will be out of addresses soon.

Tim Denton: Thank you, sir.

Matthew Kaufman: Matthew Kaufman, representing myself. I support this. Not surprisingly. I would like to point out that there’s actually several different things that this fixes simultaneously. So if there’s objections to fixing one of the things, you might want to fix the others anyway.

The first is that if this does not happen, then people will use 8.2 instead of 8.3 and it only costs a little money to do that.

You simply have to create the subsidiary entity and do it as an M&A transfer.

The second is this fixes the three-month requirement in two different ways. One is that because we’re now down into the last /8, the language actually requires that it only be three months for everyone.

Two is that it fixes it for slow start. And the final is that — and it’s in the rationale that’s in the printed — is that there’s actually some ambiguity in 4.2.2.1.3, which is not a big deal.

But it’s important to note that this fixes slow start for the new entrants. It’s one thing to say you need to justify — we’ll only give you three months because we don’t trust you, and you can come back in three months. But in the case of a transfer, especially post run-out, you’ll be in the situation where you have to locate a seller, find some space, find the money to buy that space and then somehow figure out how to come back in three months and repeat that whole process when there may in fact be no space available to transfer and/or prices may have changed and/or other circumstances may have changed.

So you certainly — that’s the slow-start part. And if you aren’t affected by slow start, if you’re somebody who is relatively new and has been under the three-month policy but you would have been able to get another, then you’re also impacted by this.

So I think we need to — I also think we need to increase the time limit, but that’s another — that’s a different policy proposal.

Tim Denton: The president would like to speak.

John Curran: On a clarity point. Presently under NRPM Section 4.2.4.4, Subscriber Members After One Year, it notes that an organization that’s been a subscriber member for one year may choose to request up to a 12-month supply. That request period — once ARIN receives its final /8, that request period is reduced to three months.

But specifically that reduction to only three months that would occur when we’re in the final /8, which we have now occurred, does not apply to transfers under 8.3. And they may continue to request a 12-month period.

So under the current language in 4.2.4.4, organizations that have been with ARIN for a year may request a transfer of up to 12 months of resources.

Matthew Kaufman: What I was talking about was the organizations that are less.

John Curran: Right. Okay. Just want to be clear on that.

Matthew Kaufman: Right on the end of that. So, for instance, you could be — you could have received an initial allocation and be at month 11 and the exemption no longer — doesn’t yet trigger for either.

John Curran: Correct. I just want to be certain. So this predominantly — this change predominantly would affect — would move the language to a place where it’s easier for everyone to find and would remove the subscriber member less than one year restriction effectively.

Mike Joseph: Mike Joseph, Google. I oppose this policy. I think that slow start is useful. I’m not sure without some mechanism how ARIN might try to divine the possible utilization of a new entity for 12 months. It’s dangerous enough to do it for three.

I would point out also that it’s not clear to me that there’s no way for an entity to enter into a commercial arrangement with a potential seller of IP space and take possession of space under NRPM 8.3 and portions of allowed blocks as they become eligible.

I think what we can do by preventing organizations from bypassing slow start is to prevent the wholesale movement of large box to untested and unvetted entities through the transfer process.

So I’m not sure that this policy is really necessary to make it easy for organizations to obtain or even have some confidence of a guarantee of future availability of space, because that can be solved commercially.

I do have a question for staff, however. During the introduction of the policy, my colleague, Mr. Morrow, indicated that this would align policy with current practice.

But, as Owen pointed out, it’s not clear to me that current practice would be to allow a new entrant to obtain more than a three-month supply via an 8.3 transfer.

So can staff please clarify.

John Curran: You want to do it, Leslie?

Leslie Nobile: What we said is it would align current practice with 8.2 transfers in which we’re looking at a 12-month supply essentially, 12-month justification.

Mike Joseph: So this would result in a change of practice for staff if this policy were adopted.

John Curran: Specifically the case is at present there’s 12 months for organizations that have been associated for more than a year. There’s 12 months for what we assess for need as a result of an 8.2 M&A transaction.

This is the only place where we’re currently enforcing a three month. By eliminating it, it will be consistent with the other two types of transfers.

Mike Joseph: Thank you. I still oppose it.

Tim Denton: I see Mr. Grundemann, Mr. Leibrand, Mr. Kaufman. So Mr. Grundemann.

Chris Grundemann: So I believe that — at least my opinion, my understanding of the reason for slow start was that ARIN has no way of understanding the usage patterns of a new entity. So when giving out free addresses from the free pool, when they were plentiful, we put in place the idea of slow start so that you could — ARIN could get a feel for this organization and how they were going to grow and how they were going to move.

And the organization itself doesn’t even know that, right, day one. You may think you will have a million customers tomorrow, but we don’t know that until you’ve actually proven you can do something about it.

As we move into a system of a market and paid transfers, something which we’ve never done before, something which very, very few have completed so far, I think it’s a little early to start mucking about and saying, okay, now, all of a sudden we think that any entity that comes in says they have 12 months’ worth of need can have whatever they want. This is how speculation gets into the game. This is how we screw it up.

I think maybe this is needed at some point, but at this point, when we have 15 or 20 transfers that are completed, we may want to wait for a little more data before we start mucking about with the policy.

Tim Denton: Thank you. Mr. Leibrand.

Scott Leibrand: Scott Leibrand, ARIN AC, Limelight Networks. I support this policy proposal. I think it’s appropriate for folks to be able to get a 12-month supply on the transfer market, if they feel that they can afford it and that it be better for their business to not have the uncertainty of whether space is going to be available.

I’d like to make a comment with regard to what I think were forward contracts mentioned as a way to get around this.

If you make a contract with someone to obtain addresses in the future whenever you qualify for them from ARIN, that can be done for either purpose. That can be done to allow you to get around this requirement because you need a stable supply, but it can also be done for purposes of speculation.

So I think trying to use the, oh, well, you can just do a forward contract as a reason for opposing this proposal but then say we’re going to reduce speculation by not passing this proposal ignores the fact that you could use the forward contracts to do your speculation.

So I think what we’re really talking about here is not the people who want to game the system and get around it, but we’re really talking about people who want to kind of play by the rules as they’re written, the straightforward easy way, and allowing them to get 12 months’ worth of supply makes their life much easier as they’re starting up. And if it does turn out that they don’t have a need for that space, they will have a financial incentive to go ahead and release that as soon as that’s clear to someone who does.

Tim Denton: Thank you.

Mr. Kaufman.

Matthew Kaufman: Matthew Kaufman again. I stood up originally to say almost exactly the same thing, which is that either you believe that forward contracts won’t work, in which are case you really need to be able to let buyers buy a 12-month supply rather than a three-month supply, or you believe that forward contracts will work and, thus, all of your concerns about both speculation and hoarding can be implemented simply through forward contracts.

If people don’t understand what that means, it means I can simply — I could corner the market without executing any transfer policies simply by offering anybody, whoever wants to transfer any addresses, the opportunity to get paid millions of dollars now for me to have the first right of refusal later.

Tim Denton: Thank you. I saw Mr. DeLong. Then I saw the gentleman in the middle and Mr. Sinatra.

Owen DeLong: Owen DeLong, Hurricane Electric. I think forward contracts, while they could enable speculating or hoarding, are far more useful when attempting to comply with the policy because the ability to — speculation and hoarding depends on the ability to make liquid the things which you are speculating and hoarding, and the forward contracts are significantly less liquid than actually having the address space transferred to you.

The only place we’re doing three months is for organizations that do not already have a one-year track record with ARIN and for organizations that are getting free space from ARIN. I think that that’s valid. I think that aligning this with 8.2 where you’re talking about an M&A transfer of an organization with a track record with ARIN and its substantial network assets is a very, very different thing than a new entrant coming in and just buying addresses without equipment or infrastructure or customers or anything else.

We’re talking about organizations with no track record being able to buy essentially whatever address space they can cobble together, whatever justification they can make up out of their minds as a speculative transaction. I think that that would be a bad thing.

And I think advancing that at this time is premature at best.

Tim Denton: Thank you. Sir.

Andrew Dul: Andrew Dul, Cascadeo. I support this policy. I think a 12-month horizon for a transfer is reasonable. Any shorter, it just isn’t reasonable for someone to have a paid market transaction.

Tim Denton: I saw Mr. Sinatra.

Michael Sinatra: Michael Sinatra, ESnet, speaking for myself. I agree with Andrew, but I also agree with Marla. I’m not sure whether I support the proposal or not. But I think that the current three-month period for new or for — I don’t mind slow start, but the current three-month period for reassignments or reallocations is problematic.

And I’m wondering if we – when we did that last /8 has been given to ARIN, if we realized at that time that ARIN would have six /8s in its free pool at the same time that APNIC would be out of IPv4 addresses, because that creates a bizarre situation. And I certainly didn’t anticipate that.

And I’m wondering if it just doesn’t make more sense — go ahead, John, I’ll finish in just a second. I wonder if it just doesn’t make more sense to standardize all of these allocations on a longer time frame and then that would just sort of subsume this policy.

Go ahead.

John Curran: So there were two events related to the final run out. One was the fact that there was what they called the various space, which was space that had had multiple RIRs associated with it that we all knew was out there and we worked hard to try to clean up and get a responsible RIR for each block such that that space would be received by every RIR, but we didn’t really talk about taking that space and managing it according to a needs-based pool because we had already departed from needs basis. There was a decision that the final five /8s would be allocated evenly and not based on need.

Once you make that decision, then inevitably different growth rates mean different run out. The alternative would have been for all the RIRs to coordinate and go to only six months for all allocations and have each RIR draw down from a central pool as it ran out of its local pool and then go to three months for all allocations globally and then go to one month globally, and we could have all ticked off at the same month globally but we didn’t.

We actually, at a global level, broke up into regions and gave each region a /8 regardless of its actual pool size. When the regional registries blocks were allocated approximately evenly, this was known. It’s just the usage rate in some RIRs were remarkable compared to others.

APNIC has an enormous base of users growing at a remarkable rate in multiple economies all at once. You start doing the multipliers of devices per person, number of economies, and it ends up being a great amount of address space.

So to answer your question, do we know that there was going to be five versus four versus two in the ARIN pool? I don’t think so. We did know we were going to be with addresses and that the region, like APNIC, was going to be out for some time period.

I don’t know if that was two years or a year or three years. But it was definitely going to be disproportionate the moment that we stopped drawing on the free pool based on demand.

Michael Sinatra: I understand that part, and I also understand we can’t expect all of the RIRs to run out at the same time and that wasn’t going to happen, but should we be choking ourselves as hard as we are right now given that we actually have a relative surplus? I mean, this is all very relative of IPv4 space.

I think it’s just something we need to think about and talk about more in Open Policy Hour.

Tim Denton: Thank you.

Mr. Woodcock.

Bill Woodcock: I’m not going to speak to the merits of the policy as a Board member, but I’m probably among the most vehement anti-hoarding people in the room, and, despite that, I have to agree with Owen and disagree with Matthew on the danger of forward contracts with regard to hoarding.

It would only be a danger if the market believed that the hoarders would become valid recipients in the future, and if they were to become valid recipients in the future, then that would not be hoarding.

So the only potential threat there is spoilers, right? People paying other people to not transfer things. If you disagree, explain it to me later.

Matthew Sinatra: This simply becomes a market and forward contract, right? So I take all the forward contracts I have and I sell them to people who can qualify for space.

Tim Denton: Mr. Woodcock, are you done?

Mike Joseph: Mike Joseph, Google. One of the considerations that we have to think about, I’ll throw it out to a rhetorical question to my colleagues in the room: If we don’t want to have a three-month horizon but we still talk about the benefits of slow start, how much space do you think a new entrant would actually qualify for that they wouldn’t be coming back in a few months anyway?

Effectively unless we’re talking about — if you’re a new entrant to LIR and you’re asserting that you qualify for a /16 because you’re going to have that much uptake in your first year, it wouldn’t be prudent and in fact it wouldn’t be allowable under NRPM for ARIN to authorize that amount of space.

So removing this restriction, which again I still oppose, doesn’t seem to alleviate the concern of having to return to ARIN to either obtain more space or execute another transfer. And I think Mr. Curran wants to respond.

Tim Denton: Of course you do.

John Curran: So the problem with a new entrant is all new entrants have ambitious business plans and will soon be the number one supplier of services within a short number of months after they start business.

That’s inevitable. That’s sort of almost a requirement, as it turns out, the way the finance world works.

So the result of this is that it’s very difficult and there’s a great deal of disagreement between ARIN and a new applicant about what their actual need is in the absence of any track record whatsoever.

Three months allows us to have a reasonable compromise to achieve a track rate and a run record that let’s us safely see what that is, and so we can see the last three months and then do the next three and the next three and by a year we actually have some real track record.

So there is a value in this. I don’t know how many new entrants we’re actually seeing. They’re not all that common. I’ll note that we can function without this. But it does mean that to the extent that we are — to the extent we’re working with the parties and trying to believe them credibly, there’s more at risk.

If ARIN assigns a very large address block to a new entrant who doesn’t make it 12 months or ends up languishing, that address block may not come back or be used for years until something happens.

So the slow start is predominantly because it allows us to then base things on a past record, and that’s why it’s valuable. It’s not essential for us for doing our work, but it does mean when we get to one-year allocations we actually have a one-year past history.

Tim Denton: Thank you.

Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. In response to Michael’s question about what did we have in mind, I would say what we ended up with wasn’t unanticipated, but it was definitely on the high end of what we were thinking about.

And I think part of the timing was looking at the low end of the range and trying to find a compromise, and we sort of got lucky or unlucky, depending upon your view of the situation, and so I won’t say it was unanticipated, but we are very much on the high side of what anybody thought was going to be when that all triggered.

And then the other thing that just dawned on me while I was standing here, I have a question for those that are opposed to changing the slow start. Would setting a maximum allocation that’s more than the minimum allocation for someone in — as a new entrant be acceptable?

In other words, is there a compromise to be had here between the traditional slow start of starting with a /20 and building your competence and saying, well, hey, that’s actually kind of small for a new entrant in the current conditions and maybe that’s their minimum and we set a maximum, and they have to do their creative writing or whatever within that range.

Just as a thought.

Tim Denton: Okay. Thank you very much. Heather Schiller was next in queue.

Heather Schiller: So surprisingly I agree with Owen and Bill Woodcock. That is actually sort of better.

And if staff could clarify, slow start only applies to ISPs, correct?

John Curran: That’s correct.

Heather Schiller: That was my understanding, but I wasn’t sure if you were applying the same model to end-users.

John Curran: Let me add one thing. There is the ability of an end-user organization to request address space. That’s guided by the end-user policy. And it’s under the framework of RFC2050 that gives guidance. It is not in NRPM, but since it’s in 2050, we also have to provide a conservative approach to end-users as well.

Heather Schiller: My next question was going to be a little bit about how does ARIN staff interpret the policy for ISPs that have already gotten what would probably be their initial allocation from an existing service provider.

And the reason I ask that is because in a way this whole kind of conundrum might be moot if you obtain — if organizations obtain their first allocation, their real true first allocation, from an existing service provider.

I don’t think there’s a lot of ISPs who magically come into being and have no transit provider that they could get address space from. So if they get space from their initial provider, reallocation policy lets them get almost two years worth of space. There’s a 25 percent immediate need requirement, 50 percent in one year.

It’s quite possible for you to get almost two years’ worth of address space.

John Curran: You are correct.

Heather Schiller: So I kind of — again, the three-month slow-start model gets applied to ISPs. There is another process for you to get more address space. Then three months. I’m not sure what all the struggle is about.

Tim Denton: Okay, Heather. Then we had Mr. Chu.

Yi Chu: Yi Chu, Sprint. I know a customer, ISP customer of mine, their address requirement will not be met by the current ARIN slow-start policy. So what they can do is they can go on the market and gather space needed for their business requirements.

However, with the way that currently 8.3 is done require them for their three month slow start even if they go buy it. What that forced them to do is they just don’t do anything.

They have to get address, but they have to do it either way, with or without ARIN. So my understanding is that this proposal as it is alleviates a little bit so they can go 12 months. And I would even go further than that. We should provide a longer time frame so their business continuity and stability applies.

Tim Denton: Mr. Kaufman.

Matthew Kaufman: Matthew Kaufman again. Several of the recent comments including — and I may be misreading some of this from Heather and certainly the comment from John as well as several from the audience — make me believe that there’s a point of confusion here.

This is not about getting rid of slow start. This is not about changing how ARIN hands out addresses to people who come to ARIN for addresses. This only affects section 8.3 transfers. That is the only impact is on slow start with regard to 8.3 transfers.

So when people come to ARIN and ask for space and ARIN still has space, which would presumably be much cheaper than getting it on the transfer market, they will be encountering slow start.

So, yes, there will be some people who cannot justify three months’ worth but can justify 12 months, which is a very tiny different window. If you’re a new entrant, the difference in your business plan between justifying three months and justifying 12 months is you inflate one by 4X and that’s within the margin of error for the analysis process, and then you can decide, well, maybe you’re more comfortable getting a little more space on the transfer market.

What this really does, of course, is after that run out, when you can’t get any more address space from ARIN, it lets you get a full 12-month supply of address space no matter what type of entrant you are, new or old, because the process involved in going back again is much more onerous than going back to ARIN and saying: Yes, I successfully got through those three months; where’s my next chip block of addresses?

When ARIN is out of addresses and you go back and say, “Wow, I used my first three months really effectively. In fact, I used it in two months. Now I’d like some more,” and they say there isn’t any more, you shouldn’t have to repeatedly go back and justify every three months your own transfers off the transfer market.

Tim Denton: Mr. DeLong?

Mr. Joseph.

Mike Joseph: Mike Joseph, Google. I think this does overturn slow start. It overturns it for a policy. It overturns it for 8.3. The real question is whether we think slow start still has any utility. And I think it’s hard to make the case that it would be possible for a new entrant to come to ARIN and say I have a justified need for a 12-month supply, but, don’t worry, it’s not so much addresses that we still can’t get it, because, quite frankly, you can’t come as a new entrant and justify a massive amount of address space, even on a 12-month need, because you’re still slow started under 2050, which I think, if John could clarify, it was his earlier point.

In other words, if you come to ARIN and you say I have this many addresses, this much need, unless you can show history for that need, you’re still going to have to get increasingly larger allocations. And I don’t see why we wouldn’t want to have similar construct for the transfer market.

I think the argument that simply removing the three-month need means that an entity can get all their 12-month needs in one go just isn’t going to be true for most entities, especially if these are these massively growing ISPs that are just starting out, which someone needs to point me to one.

Tim Denton: Thank you. Mr. Woodcock.

Bill Woodcock: I’m not sure I see the logical connection between removing slow start and use of the market is. That seems to me to be a fallacy saying that if one can afford to, one needn’t follow the rules of good citizenship; that is, good citizenship is only for poor people. Am I misunderstanding this?

Mike Joseph: Is that a question directed at me? So let’s break this into two questions. One is: Let’s ask that question after ARIN runs out. Right? So after ARIN runs out, everyone has to buy their addresses. There aren’t any available for free. So no poor people, as you put it, would get any addresses, no matter what the justification interval.

So, in fact, poor people are probably better off with a 12-month justification interval, because if there’s a bubble in IP address pricing, which there might be, you can justify 12 months’ worth of addresses now instead of justifying three months now, and then three months three months from now when the prices have gone up.

Then let’s address it now. So right now you then have to figure out whether there are in fact any entities who can’t justify three months but can justify 12 months’ worth of space, which doesn’t make any sense. Right? You’d be able to justify – if you can justify space in 12 months, you can justify some space in three months. It’s just a different amount of space.

So the only question is how big is the block. So the answer is, yes, if you have money you might be able to get a slightly larger block than the block you can get for free from ARIN, but that’s true anyway because you could buy it under 8.2. So who cares.

Bill Woodcock: So as this was originally — as the transfer — the incentivized transfer policy was originally structured, it had a provision saying you could not fulfill a justified amount with a smaller block. And that was intentional, in order to create progressive pricing such that small entrants would always be able to afford small blocks whereas people who had large needs would use large blocks and the premium on large blocks would keep people from taking large blocks and deaggregating them in order to achieve excess margin on the smaller sales.

So I don’t know if that provision has since been struck, but if it’s still there, then that’s the address you’re talking about.

Matthew Kaufman: Let John answer that.

John Curran: The challenge is as currently envisioned it’s very difficult to detect a party that happens to request the size of the block that they happen to be able to transfer.

So a party that shows up and says there’s a /20 and here’s my application to qualify, even though they might be able to justify a /18, if they don’t give you that justification, it’s impossible to detect.

Bill Woodcock: The attacks on them is that then they’re coming back with a new application every three hours.

John Curran: Right. If they’re a large provider.

Matthew Kaufman: Or they do it under 8.2.

Tim Denton: Okay. I’m going to close the mics after the last speakers here.

Mr. Grundemann.

Chris Grundemann: Chris Grundemann again. I wonder if ARIN can tell us how many initial allocations for new ISPs have been handed out in the last year.

John Curran: We can get that. It’s not presently in the stats. But Leslie — do you have it off hand?

Leslie Nobile: We just looked it up. So in 2011, we just checked, and first-time ISP approvals were 265. And additional allocations to ISPs in 2011 were 484. So looks like one-third of our ISPs are new players. And about two-thirds are returning ISPs for additional.

Tim Denton: Thank you.

Scott.

Scott Leibrand: Scott Leibrand, ARIN AC. I think it’s worth noting, nobody comes in as a new entrant with absolutely no history if they’re applying under the ISP section, because they have to have already been using PA space from their upstream. If they’re single homed, they have to have been using a /20. If they’re multi-homed they have to have been using at least a /23, to get a /22.

So there’s some knowledge already of what their run rate is. And if we extrapolate that out to 12 months instead of three, there will be some error rate but we’re not just talking about VC business plans that can be made up completely out of the air.

Tim Denton: Okay. I think it’s time now to take this to a vote, or in the sense of a show of hands indicating support.

So then would those in favor of the policy as drafted, please raise their hands to signify sending this to the AC with support.

John Curran: If you’re raising your hand, please raise it.

Tim Denton: Until the blood runs out of your fingers and numbness ensues.

Thank you. Those contrary-minded, opposed to the policy being recommended to the Advisory Council, please raise your hands.

John Curran: If you’re raising your hand, raise it high, Louie.

Tim Denton: Thank you.

We’re establishing a special award for those who pass out with their hands raised.

[Laughter]

Tim Denton: In relation to 2011-11 to clarify justified need for a transfer, total number of people in the meeting room and by remote were 133. Those in favor were 25 and those against were six.

Thank you all very much.

John Curran: Okay. Our policy discussions have gone into the break period. And I have a choice here of either suspending break for all of you or and suffering the consequences, or having a short break. I think we will have a short break, which will run until — I’m sorry, it will run until 11:10. If we can be back in here at 11:10 we’ll resume the policy discussions. We’re on break until 11:10 we’ll pick up with policy proposal 2011-12 at that time.

[Break]

John Curran: I’d like to welcome everyone back. Most of you. Okay. We’re going to get started with the policy development activities with Draft Policy 2011-12: Set Transfer Need to 24 Months.

ARIN-2011-12: SET TRANSFER NEED TO 24 MONTHS

John Curran: This policy originated with ARIN Policy Proposal 147 in May 2011. The AC shepherds are Rob Seastrom and Martin Hannigan. The AC selected it as a draft policy in August 2011.

The current version is 24 August 2011. The text and assessment are available online and in your Discussion Guide.

Summary: This is a conditional policy proposal germane only if 2011-11 advances as a policy. This proposal would modify 2011-11’s changes to NRPM to allow requestors to show justified need for 24-month window rather than just a 12-month window.

Nothing similar in the other RIRs. Staff comments, issues or concerns: This proposal would still require an organization requesting an 8.3 transfer to qualify for the space under ARIN’s policies. But it would allow them to qualify for a 24-month supply of IPv4 addresses instead of 12.

This change would make the specified transfer policy fit more situations at the risk that more addresses may go to parties whose need does not actually materialize as expected based on their projected allocation rates.

Minimal impact. Updated guidelines and staff training. We can implement it fairly quickly.

Legal assessment: ARIN counsel strongly supports the immediate extension of assessed need from 12 to 24 months for proposed transfers. It is clear that the longer time period will appropriately facilitate legally simpler transactions by those who are seeking to follow ARIN’s policies.

It may also meet the goals of allowing larger blocks to be transferred to meet the needs of a single entity.

Discussion: Little or no discussion of the draft policy. Earlier discussion of the proposal: 19 posts by 12 people. 6 in favor and 2 against. Representative comments: “I would support this. I would support it even more if it were 36 months.”

“12 months supply has been sufficient in the past. It was the long-standing standard for normal allocations.”

That includes the staff introduction of Draft Policy 2011-12. I’ll invite Martin Hannigan up to do the AC presentation.

Martin Hannigan: Hi everyone. I’m Martin Hannigan. I’m an elected AC member. And I work at Akamai Technologies. My day job. There are no slides. And the reason why is because this is oddly very not controversial. There are a few minor points I’d like to make. I’d like to reiterate what John said with regards to the discussion.

There was little resulting discussion other than the perfunctory processing on the list and the follow-up AC discussions.

Again, not controversial. A few clarifications. With regards to staff board point two: Need is demonstrated but not guaranteed for performance. With the level of diligence that we see from the staff personally I believe that the risk is low with respect to any kind of waste.

With regards to the legal comment, again, I agree with the attorneys, and to be clear legally simpler at least to me means less costly. And anything that’s less costly is a good thing in the Internet.

So with that, I think that overall this is fairly simple and straightforward. There’s low risk to proceed. And the discussion might focus on the 24 months versus something longer. Thank you.

John Curran: We’re opening the microphones.

Owen DeLong: Owen DeLong, Hurricane Electric. I cannot agree that this is non-controversial. 12 months — multiplying slow start by 4X was a bad idea. This multiplies it by eight. That’s an even worse idea. And it also doubles everything that wasn’t subject to slow start.

So I think we’re way too early in the experience with the transfer policy to look at doubling the duration and encouraging speculation hoarding and all that goes with that.

Tim Denton: Mr. Kaufman.

Matthew Kaufman: Matthew Kaufman. I support this proposal. I would be okay with delaying the implementation of this policy until ARIN ran more low on IP addresses. I’m going to use an argument that I did not use last time for an extension.

So the primary reason for this policy is right now if I tried to start a new Internet business, I need IPv4 and IPv6 addresses. Frankly, I only need IPv4 addresses, but we all like to think I need v4 and v6 addresses.

Some time from now that won’t be true, hopefully, and we’ll only need IPv6 addresses. But right now I need the v4 addresses. So I need to be able, if I’m starting a venture and I need to raise money for that venture, to put together a business plan that shows exactly how I’m going to run this business.

Right now the way that works is I say I’m going to need three months of address space initially and I’m going to be able to go back to ARIN and get three months more, I know exactly how much that’s going to cost. And I can put that in my business plan.

But when ARIN runs out of addresses or is even in sort of danger seriously of running out of addresses, my business plan doesn’t look like that anymore. Instead, my business plan says: If we’re lucky enough to find some addresses on the transfer market, then we’ll be able to get some but not as many as we need per our business plan.

And then we’re going to have to go back to the transfer market and hope that prices haven’t skyrocketed and that supply still exists and so forth.

So that makes it much harder for me to attract investment. That means that not extending is essentially discrimination against new entrants, which is not surprising that incumbents would be in favor of short intervals because the incumbents already have the address space they need and are also not subject to any sort of slow-start policies.

So as a new venture, a new entrant trying to put together one of these plans, what I need is I need some sort of certainty, something where I can say, yes, I know it’s going to cost me a lot of money potentially to get those v4 addresses, but I’m going to be able to get enough v4 addresses to make it all the way through transition to v6.

The question is how long is it going to take to get to v6 penetration, and I think that 24 months is optimistic. 36 months might be more reasonable. And it might be a lot worse than that.

I was looking for Geoff here to nod his head. There he goes. That’s right. This also has a potential, though, I’m sure people will argue against this benefit, as far as routing table growth because if I can go get one block that’s big enough for everything right now, I don’t have to come back a few months later and get another block.

I don’t think that is a good argument pro or con, but I think that allowing new businesses to have enough certainty that they’re able to launch at all is something we should be encouraging.

Tim Denton: Thank you. I saw Mr. Grundemann and then Ms. Azinger.

Chris Grundemann: Chris Grundemann. First of all, if you are building a business model based on the need for IPv4 right now, you may want to consider that.

There are very large and very well-entrenched incumbents changing their business models based on the scarcity of IPv4. The world is out of IPv4 addresses. And there’s nothing we can do here today or at any other point to change that fact.

Beyond that, I’d be interested to hear comments from the community with regard to changing the 12-month to 24 months without removing slow start. In other words, decoupling the two proposals. The way it’s written right now it says if the first one goes through, then we bump it up to 24 months.

I’d like to hear folks’ comments on whether they would oppose or be in favor of not removing slow start but still bumping the 12-month transfer limit to 24 months.

Tim Denton: Marla, you’re next.

Marla Azinger: First, I need clarification of what he just. I didn’t think slow start was a part of this, period.

John Curran: Because of the fact that they’ve stated the policy is conditional upon removal of slow start, while it’s not in this policy, this policy wouldn’t be considered if 2011-11 isn’t passed.

Marla Azinger: Let me put it this way: I think slow start is kind of — it shouldn’t exist to the extreme it does. I don’t support slow start.

And this proposal, I do support, but I don’t like the 24 months. I want to see 36 months. If you are running an organization that has a large network within it, you need to be able to plan.

And to Chris’s point, these plans actually should, if they don’t, the ones I’ve been working on do, have v6 as part of that.

But you also still have to plan out for two, three years on your network in order to be able to actually know where your network’s going, know what address space you’re going to use it on.

And, yeah, that means that when you’re looking at your third year, if you’re trying to guess what your fourth or your third year is going to include for v4, unfortunately my gut says I better keep doing the v4 growth prediction as what it’s been going at this rate.

But in good concept I want to say, no, there will be less v4 need in that third year because my v6 is going to be up and running by that point and hopefully my cap and grow is starting to take effect.

That’s a hope. That’s a goal. It’s actually in the plans I’m working on. But if you are actually working on large networks, you need this time frame to do it.

In addition, if it’s a transfer, that means somebody’s actually doing work to reorganize their network in order to free up that address space.

That takes time for them to do as well. So you need a larger time frame for all of these things to come together and work nicely and enable one person to have a stable environment, the other person actually do what they need to do to free up that space.

There’s a lot of factors that require this larger time frame. And it’s not a waste. These people are — they need it. Thank you.

Tim Denton: Mr. Chu.

Yi Chu: Yi Chu from Sprint. I support this proposal and also echo Marla’s point that if this can be extended, it’s even better. The reason is it supports business stability.

The newcomers, they have to go to the market and pay for address, it’s already we’re asking a lot. Pretty tough on the newcomers, after they’re paying from the market, it’s unfair. And try to use policies here to regulate whatever the market is, I just think that’s fantastic.

Tim Denton: Number five is Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I’m not sure I support linking this with the slow-start thing. I will say, while I’m not uncomfortable relaxing slow start as the previous proposal calls for, I probably do start getting a little uncomfortable relaxing slow start to two years. However, I do not have any qualms about relaxing other transfers to two years.

And I just want to point out to those that think we should follow the current measurement of need in that if you really start to think about it, once we actually run out, and not just when we run out but a year from when we run out, if there’s any addresses left, what is being defined as your, quote, need isn’t actually your need, it’s actually what you were able to find the capital to buy last year.

So once this — if this extends out, you’re no longer talking about what your needs are. You’re talking about how much money you can spend last year is going to define how much address space you can get for this year.

And so that’s why we have to extend this out a little bit. Because while I support some definition of need and a measurement of need; in other words, I don’t support completely eliminating the needs basis, you can’t think — the world is changing and you gotta think about it differently. We’ve got to think about it differently.

Tim Denton: Thank you. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. I do not support this proposal if it’s tied to the previous proposal. If it stands on its own and it changes 8.3, I support it. But I do not support it otherwise.

But that’s the first thing. The second thing is that as a smaller ISP, I looked at this as being a very good thing for the smaller players because of the cost to acquire space, the time and the resources.

For a smaller ISP to get a /24, every six months — because it takes them six months to find someone who is willing to sell them that smaller block, et cetera, I felt 24 months was reasonable given the amount of work that goes into getting it for the smaller players.

I thought about if it was extended to 36 months, my concern is it’s very hard to forecast that far. It becomes more and more unreliable each year that goes by.

And I felt — I feel at least it’s a good compromise number, and I would be in support of changing 8.3, just that portion, to 24 months. Thank you.

Tim Denton: Mr. Leibrand.

Scott Leibrand: Scott Leibrand, Limelight, ARIN AC. I support the proposal. I look it less about new entrants than about all of us.

The last discussion was perhaps appropriately about new entrants, maybe a little more than I would have thought. But this really changes the rules for everyone. And that is, as David and others have very well said, that is something that we really need to think hard about, what is it going to be like for us to get address spaces when we don’t just have to involve our ARIN people but we have to involve our lawyers and our finance people and all this stuff.

Do you really want to go through that process every 12 months, or would it be better to do that every 24 months?

And everyone I’ve talked to who has thought about that says it would be way more way efficient to do it every 24 months.

So I think it’s worth noting that there are certain things that will prevent this from being a problem in terms of people. There are lots of other requirements that require people to make sure that they’ve documented their need appropriately, and all we’re really talking about here is the time window at which all of us have to go back for more addresses.

Jason Schiller: Jason Schiller, Google. On that very point, I’m not sure it’s in the community’s best interest to reduce for paying to continue to live in an IPv4 world.

I also wanted to point out as a follow-up to something that Chris Grundemann said about making business plans and business models dependent on IPv4 addresses and that most of the established organizations that have been doing IPv4 for some time are trying to shift their business towards IPv6 because of IPv4 depletion.

Certainly new entrants will need some IPv4 addresses to reach that legacy portion of the Internet. And I wanted to point out that we do have a provision for that in 4.10 dedicated IPv4 block to facilitate IPv6 deployment.

But the biggest point I wanted to make here is my concern is if an organization can get two or three years of IPv4 address space now, that they may see this as an opportunity to defer IPv6 deployment for another two or three years. And if a few large organizations take this opportunity, that could severely derail IPv6 deployment for the industry.

Tim Denton: Thank you. Mr. Sinatra.

Michael Sinatra: Michael Sinatra, ESnet, speaking for myself. I am generally in favor of the proposal. But I agree with just about everything that’s been said so far.

I’m concerned a little bit about the idea of a 24-month time frame for transfers for — for 8.3 transfers in particular, and a three-month time frame for getting IP addresses from ARIN. I’m concerned that that choke hold as I mentioned already is going to distort the market. And I don’t think ARIN should be in the business of distorting the market.

I think we should just let — we should standardize the needs, let the IPv4 addresses run out and let these policies do what they’re going to do in the brave new world of market-based IP address.

Andrew Koch: Andrew Koch, TDS Telecom. I just wanted to put up a suggestion maybe that we ask, maybe not just yes and no on this, but additionally if folks, if this was separated from 2011-11, if there would be more yes or no on that as well.

Because currently the way it’s written this is dependent on -11, and I think that may muddle things.

Tim Denton: Thank you. Noted.

Mike Joseph: Mike Joseph, Google. I oppose this policy. And, in particular, I have some concerns that we, more or less, just seem to have voted to adopt a policy that will allow new entrants to request the maximum amount of space for the maximum time window for their space. And now we’re considering setting that to 24 months.

So I recall the arguments that I made a few minutes ago when I said that now we’re going to have a new entrant coming in with no established track record who might qualify for 24 months, which now somehow will define what that actually means.

And that scares me quite a bit. These comments about separating the two policies seem a bit moot to me, because I think the community, sadly, seems to favor 2011-11. But I think that given that, this policy is even more scary.

Tim Denton: Mr. Curran.

John Curran: I do want to respond. It was pointed out, many of the parties who come to us were, quote, new, are not new as an ISP. They’ve been operating downstream of another ISP. They’re new to ARIN.

So it is not true — it is not inevitable that everything that comes to us is a business plan that exists solely as paper. Some of them are operating concerns that do have a track record.

Mike Joseph: Well, actually maybe you can clarify for me. In the past, when I’ve had to obtain an initial LIR allocation, I’ve had to show instantaneous current use but not historical use, because ARIN has relied upon only requests previously made to ARIN to infer a growth trajectory.

Are you planning on changing that?

John Curran: I need to confer.

Leslie, I thought, when we looked at people’s requests, while we did ask them what their going forward projection is, we did look at their past utilization, whether it was from ARIN or from another ISP.

I’ll ask Leslie to clarify.

Leslie Nobile: Actually, I think we’re actually looking at the space they received from ARIN only when we’re asking for — when we’re doing the 80 percent utilization.

David, do you have any? Yes, that is correct. We’re just looking at ARIN-issued space.

John Curran: But those organizations may already be existing organizations?

Leslie Nobile: Absolutely. Most of the time they are. That’s how they get space. If they have space, they can get space. That’s how the policies work. They have space from an upstream.

John Curran: While not being considered for the rate, it is — there exists an existing concern, is what I’m trying to say. They’re already operational.

Mike Joseph: Sure. But it could have been allocated yesterday.

John Curran: It could have been, yes.

Tim Denton: Mr. Hannigan.

Martin Hannigan: Martin Hannigan with myself for this comment. I would like to support this proposal. No surprise.

But with regards to the vast majority of the comments that we have, I think that one thing isn’t really so clear.

This proposal really is a great equalizer between smaller networks and — smaller networks and larger ones because the larger networks already have the capability today to guarantee their access to address space for many moons going forward. And restraining the smaller guys from doing the same thing seems to be unfair and unrealistic.

Also, with respect to some of the later more intellectual points that I’ve been privy to hear over the course of the NANOG meeting and here, I do think it is advantageous to get rid of the address space if we’re not going to use it as soon as we can and to also, perhaps, put a dent in the liquidity which would ought to give a boost to IPv6 transition.

So the last point I’d like to make is with respect to cost. I’d much rather have to go to the attorney one time, not two. This wouldn’t — I think Scott mentioned two times at the attorney. For most of us it would be one time, with the space locked up for the period and then whether or not slow start even matters anymore should be thought about to some extent, because if you lock up enough address space for a long period of time, you can come back whether slow start is three, six, nine or 12 and be assured you’ll have address space.

Thank you.

Tim Denton: Mr. Schiller.

Jason Schiller: Jason Schiller, Google. If this community wanted to give direction to ARIN staff such that they should consider history of a year or longer using a provider aggregate, would that be something that would be best handled through the Consultation and Suggestion Process?

And I wonder if such a suggestion was accepted, what impact would it have on support for this policy.

John Curran: As the policy isn’t clear, then it’s handled by ARIN’s procedures. If you make a suggestion, we can reevaluate it and change those procedures. But if you want it to be such that it is not at the discretion of staff, then making the policy clearer is the right way to do it.

Jason Schiller: So this could be a policy proposal on the docket at some future time to consider PA history as a viable measure of —

John Curran: Sure.

Jason Schiller: Great. Thank you.

Tim Denton: I think it’s now time for the show of hands. The counters will arise. Your names will be taken. No.

Those in favor of recommending to the Advisory Council that they adopt the policy as written, would they please raise their hands.

John Curran: Hold your hands up high.

Tim Denton: And those who are contrary-minded and would feel it should not be recommended to the Advisory Council, please hold up your hand.

John Curran: Equally high. You will not touch the ceiling no matter how hard you try.

Tim Denton: All right. In relation to Policy 2011-12, Set Transfer Needs to 24 Months, total number of people in the meeting room and by remote who were voting is 134.

Those in favor, numbered 29. Those against measured 7. Thank you all.

John Curran: Okay. While it is true that we have some policy proposals to do after lunch, and we could move them up, because we want to respect the remote participants, we will stay on schedule of handling the afternoon policy presentations in the afternoon.

However, you are all up and awake and excited and we still have 20 minutes to go before lunch. So because of the level of interest that’s been expressed, I’ve asked for an RPKI update to be provided.

I believe Andy is available to do that. So we’ll give a brief update between now and lunch on ARIN’s RPKI efforts.

CHANGES AT ARIN—NOT YOUR GRANDPA’S RIR ANYMORE (RPKI, DNSSEC, ETC.)

Andy Newton: Andy Newton, chief engineer at ARIN. And I’m going to talk to you about DNSSEC and RPKI.

First off, a brief DNSSEC update, then we’ll go into RPKI and what it looks like and our status with it.

Why are we presenting both of these? Because they are two — they address two critical infrastructures for the Internet, the DNS and the routing fabric.

And they are both the focus of some security work, including the focus of the governments being interested and these are getting scared.

So DNSSEC. Pure or regular-style or old-style DNS is easy to spoof. It has no security on it whatsoever.

So the IETF, over a number of years, came back and created this security framework that sits on top of DNS, so you can validate responses and you can’t spoof DNS responses.

There were quite a few steps we had to go through in order to get the DNSSEC to move towards securing the reverse DNS. The first was we had to transfer the reverse zones or the reverse management to ICANN for IN-ADDR.ARPA. And then after that we had to move the nameservers out of the roots into a zone for the IN-ADDR.ARPA servers themselves.

That was the management of moving the nameservers around. Then we had to — there were some signing of the nameservers, including signing of our delegations from the IANA. And then, finally, the things we had to do internally were to allow you to provision your DS records so that your delegations could be signed in the reverse DNS. That was all done via ARIN Online and the RESTful provisioning system.

So this is a graph of the traffic when those changes were made. The first kind of hump there on the left is when we switched over to moving the servers out of the root.

The big blip in the middle is when a sister organization of ours had a certain flooding incident. But as you see, the kind of troughs and valleys that go off to the right of the graph, that’s as each one of the servers was moved out of the root zone and into the IN-ADDR.ARPA zone.

I’m not going to go through the movie we have. But on the website we do have this nice little movie that demonstrates how to manage your DNS information, your reverse DNS information through ARIN Online. It’s a nice little movie, walks you through it and allows you to see people or allows you to see the entry of all the information.

It’s real easy to do. If you have any questions about that, you can go to that movie and click it and watch it. Don’t do that right now, though.

So that’s DNSSEC. The main focus of what I’m here to talk to you about is RPKI. So we put out our pilot in June of 2009. It was essentially rebranded code from the RIPE NCC.

Currently we have 46 organizations participating in our pilot. And that actually, even though it’s a pilot, puts us in the number two slot for the number of participation in the RPKI in total.

So we think that’s pretty good. So what is RPKI? Essentially what it is is it’s taking AS numbers and IP addresses and signing them. And once you’ve done that you can associate an IP range out of your network blocks that you have, put an originAS on there and sign that, that’s what’s called a ROA.

And once you have a ROA, you can start validating origin routes with your routers or with your routing infrastructure. ROAs aren’t the only objects you have in the RPKI. There’s RFC 3779 certificates which are the actual certificates that sign the resources the IP addresses and the ASN numbers, or AS numbers. CRL, Certificate Revocation Lists, are the way that public key infrastructure manages the revocation of certificates and other signed objects.

Manifest records are very specific to the RPKI. They’re basically a detailed list of all the files and repository or under a certain authorization or tree.

And then there’s ghostbuster support which is all about who has made an attestation for a ROA. Anyway, if you want to know what it looks like, the RPKI is basically a bunch of repositories sitting around the Internet. They’re Rsynced. This is a view of one of the directories in an Rsync repository. And the validators, RPKI validators Rsync all the files and aggregate the information.

So once they’ve done that, the validators can take the ROAs. They can use that to determine whether a route can be marked valid, invalid or unknown. And from there ISPs use local policy to use that to influence their local policy.

So let me skip that slide. So the RPKI is just like any other public infrastructure. It’s a tree structure. Ignore the acronym at the top of the tree there. But there is a top of the tree and basically from there you go down to the RIRs and from the RIRs to allocation recipients all the way down to the final assignment.

What that means is you can take that prefix or prefix with a max length, associate it with an originAS number and sign it. How it gets validated: First step is you take that network range and the originAS, determine whether it was signed with the private key for the public key that you have.

Then determine whether the certificate that signed that information is valid. And then you follow it all the way back up the tree.

So why are we talking about the RPKI? Well, there’s a lot of — there are a lot of issues surrounding the RPKI that some are not just technical, or issues that impact the technical implication of the RPKI.

And when we first started doing this, we were taking the RIPE NCC code they generously allowed us to have and we applied it to our database and our data set, and we were ready to go January 1 of this past year.

Unfortunately, after some review of the implications to ARIN, we determined that there were two new features that we needed.

The first was non-repudiation in the generation of ROAs. For the hosted CA model, which is where you don’t actually have your CA, you let ARIN host it for you. If you want us to generate a ROA, we have to have a facility that ensures you’re the one who asked for that ROA to be generated.

The second feature what we had to have was what we call the “Evil Mark” attack, which is, say, essentially Mark Kosters, our CTO decides one day he wants to re-route a network via the RPKI, well, we had to design a system that doesn’t allow Mark to do that. That’s what we call it the “Evil Mark” attack.

In general, the architecture of an RPKI system, an RPKI-hosted system, you have an RPKI engine that sits between your database which has all your registration information and it drives your hardware security module. The hardware security module, if you don’t know what that is, it’s a specialized piece of hardware whose whole purpose in life is to keep private keys private. Once a private key is encrypted or put onto an HSM, you can never ever get it again. It can be backed up, but you can’t get that private key.

So as of last year we worked quite hard on the RPKI and we got — we took the RIPE code and we applied it and we modeled it to our database.

We have a slightly different registration system than RIPE has. There’s some work in taking the RIPE code and making it very compliant with our database.

We have that ready to go basically under this model where we were driving using it to drive some Sun SCA 6000 via PKCS 11 interface. And that was all ready to go, then we had the new requirements that came along. The new requirements essentially made us have to go back and look at the HSM.

The HSM is the key to getting the non-repudiation of the ROAs and preventing “Evil Mark” from compromising the system.

What happens here is the HSMs — normally the way HSMs work, they have a standard interface, normally PKCS 11. There some other standards, too.

But you essentially hand HSM a blob and say please sign this, and it will take the private key it has and signs that blob.

Well, if anyone can drive the HSM, that means that anyone can have the HSM and just sign anything they want.

What we had to do was we had to get an HSM that was smart enough to know that there were certain things it can sign and certain things it cannot sign. And this required us to find some programmable HSMs, which we did in the form of the IBM 4764s.

What these 4764s do, we actually feed them in a DER encoded ASN 1 object, and they go validate the object and pass back out a signature, which we can then place in the ASN 1 tree. That’s how that works.

The other thing we did for the ROA non-repudiation is in our, in the browser, when you come into the hosted CA, the browser actually does client-side signing of the ROA request before it passes it back to ARIN.

It’s kind of a poor man’s public key infrastructure, or a lightweight public key infrastructure is the way to describe it, but the signing occurs in the browser itself.

We are working on this code. So here’s an example of how this would work. This is an actual screen shot from the code base that we do have. A user would come in and they would try to load up their key.

You’ll see the yellow button down there it says “key not loaded.” They would click on the browse button to actually pull their key from a file on their local desktop, put that into the browser and then, boom, the button turns to green, says “your key is now loaded.”

You fill out the information, the name of your ROA, the AS number you want, and the prefix and max length you want.

And at that point you hit sign and continue. The browser actually does the signing right then and there. It’s not passed back to ARIN at that point.

Then you ask the browser to hand the information back to us. So at that point you have signed a ROA request. A ROA — it’s a ROA signing request. And only you could have submitted that because only you had the private key.

The other efforts outside of ARIN: The other four RIRs already have RPKI in production with hosted CAs, and they’re also working on up-down as well which is more of the delegated model where individual ISPs run their own CAs.

Major vendors are actually working on support for getting routers to talk to RPKI repositories and RPKI validators, and there’s been a lot of announcements of public domain software.

As far as ARIN status is going, we’re still working on the hosted CA, which is the first part of our implementation. We expect that out in this coming year, and then shortly after that we’re hoping to have the up-down code to come out as well.

The up-down code, we will attempt to reuse the RIPE NCC code that they’ve allowed us to have access to. So hopefully it won’t be a lot of rewriting on our part on that end.

Again, this provides credibility for the routing infrastructure. It will also facilitate the transfers market, and it helps bootstrap the routing security.

So questions?

John Curran: Microphones are open for questions.

Okay. Thank you very much.

[Applause]

John Curran: At this time we are going to break for lunch. I think I have some slides.

Lunch table topics. Again, if you’re going to go to lunch, there will be topics discussed at each lunch table. Sit at a table that you consider of interest.

Security, take your valuables with us. The room is not locked. There is no posted security.

Look forward to seeing everyone back here. We will resume — we will resume promptly at 1:30. Thank you.

[Lunch break taken at 11:55]

John Curran: Okay. I welcome everyone back. If everyone will come in and get seated, we’ll get started.

We’re going to start off with the NRO Activities Report. Our chairman of the NRO, Raúl, will come up and give that.

NRO ACTIVITIES REPORT

Raúl Echeberría: Thank you, John. I never know when I have to speak. But I’m here.

Okay. I’m speaking now on behalf of the NRO Executive Council to present the NRO report. So please — so this is what the Number Resource Organization is. It’s a vehicle for RIR cooperation and representation. It’s formed for the purposes of protecting unallocated number resource pool, promoting and protecting the bottom-up policy development process and acting as a focal point for Internet community input into the RIR system.

It was established under the ASO within — as ASO within ICANN framework by a memorandum of understanding signed in October 2004 during an ARIN meeting in Reston, I guess.

The officers rotate every year. This year I am the Chair of the Executive Council and John Curran is the secretary and Paul Wilson, who is not here, is the treasurer. And it will rotate again next year and John will take the Chairman’s responsibility and Paul will be the secretary.

And there are some different groups that we have formed for improving the coordination in specific areas. One of them is the Engineering Coordination Group, the ECG, chaired by Arturo Servin from LACNIC; the Communications Coordination Group chaired by Ernesto Majó from LACNIC; Public Affairs Coordination Group that was recently created and is chaired by Andrés Piazza from LACNIC.

Those positions rotate together with the rotation of the officers. So the people working in those areas in the ARIN team will take the chairmanship of those groups next year.

And we have another group that is the Registration Services Managers that is chaired by Leslie Nobile from ARIN. And this group doesn’t rotate, so it is always chaired by Leslie until she retires in 20 or 30 years.

Okay. So we are not incorporated. The NRO is not incorporated and it’s not a budgeted organization. So we approve the expenses in different areas, and we distribute all the NRO expenses according to a formula that’s updated every year by our CFOs.

And the results of 2010 was the one that I’m showing in the screen. Very soon, later this month, the CFOs will meet in the annual meeting and they will check, recalculate the formula for the distribution of the 2011 expenses.

As we continue making a contribution to ICANN, it’s a volunteer contribution, we continue contributing with the same amount of money. That’s $823,000. It’s used the same formula for distributing the amount that we pay to ICANN.

Next slide, please. Some of the activities in the last year in December 2010 we started to use different approach for informing, keeping informed the ICANN community during ICANN meetings, as we have there an ASO Advisory Council update to the community, and we have also a meeting with the Governmental Advisory Committee of ICANN. We frequently meet with them and present some reports, especially about IPv6 adoption and also when some global policies are under discussion and they require some input from us.

After that, in March, we participated in ICANN meeting in San Francisco. Again, there was an update to the community by the Address Council of the Address Supporting Organization, and there was also a face-to-face meeting of the Address Council in San Francisco. And I don’t know what happened with the last line, but the same activities were held in Singapore, the Address Council update to the community.

We are very active in the Internet Governance Forum. We have participated very actively in all the — every year in all the IGF events. The sixth IGF was organized two weeks ago in Nairobi, Kenya.

There is a Multi-stakeholder Advisory Group that’s responsible for setting up the agenda and discussing many things regarding the organization of every meeting.

We have two people from the NRO participating in the meeting, Cathy Handley from ARIN and myself.

Also this year was created a group under the Commission on Science and Technology for Development that is part of another body that is ECOSOC that is part of UN for discussing the possible improvements to the IGF.

There are some governments that have been claiming for introducing changes in the Internet Governance Forum, making this forum — proposing that the IGF could make more concrete recommendations and introducing some other changes that are not very good for us.

But the good thing is that we have also two people in this working group that was created under CSTD representing the NRO interests there, and they are Sam Dickinson from APNIC and Oscar Robles who is a member of the board of LACNIC.

The last meeting of IGF was held, as I said before, in Kenya in Nairobi two weeks ago. During that meeting we had a meeting with the UN Assistant Secretary-General Thomas Stelzer.

It was an opportunity to give our views and share with him our views and positions regarding the future of IGF when we remarked the idea that IGF should remain as a non-decision-making body and forum and that we should keep the characteristic of an open forum, very participatory, and all stakeholders could participate in equal footing.

We had also a booth in IGF, run by RIR staff. And so we participated in many workshops. We coordinated some of them. We participated as participants and speakers in other workshops.

This year, as all the five first years of IGF, we used to contribute with the IGF secretariat, but this last year, due to the fact that the IGF secretariat and the structure is still evolving until there will be more clear information about the future of IGF, we made anyway a contribution to the IGF host to the Kenyans, the organization committee, to help them to set up the network facilities.

So we had very active participation during this IGF and discussions — all discussions about IPv6, IGF improvements and institutional arrangements that were some of the topics in IGF this year. It was a meeting that was much more political than previous ones. But it is reasonable, understanding that all the idea, the concept of IGF is under discussion.

We had also a meeting with a representative of the Brazilian government about the IBSA proposal. The IBSA proposal is a proposal that was made public two weeks before IGF by the Indian, Brazilian, and South African governments. This is where IBSA comes from, India, Brazil, and South Africa.

They have proposed some changes in the Internet governance landscape, and they have proposed the creation of a body under the UN for doing many things, but among other things to — exercising some oversight and control of all the operational and technical organizations including standard bodies.

What has been — it’s a proposal that we cannot agree with, of course. So we met with the Brazilian representative, we expressed our views, and he also clarified some things, saying that it is not a final proposal; it’s just some materials for discussion and the discussion will be continued in the future.

It was a productive meeting. But it is important to say that during IGF these proposals from IBSA countries didn’t get too much support. And it was discussed deeply during the Critical Internet Resources session.

So many people spoke, with positive words, but against this proposal. Thank you.

So in the international cooperation, we continue working with — continue trying to do something with ITU. So we sent several months ago a letter to ITU-T and ITU-D directors inviting them to hold talks to be consistent with the outcomes — outputs from the ITU Plenipotentiary Assembly of 2010 that ask ITU-T and ITU-D to work in a coordinated way with all stakeholders.

But a good meeting has not been possible yet due to the conflicting agendas of all the potential participants. Some of us have met with ITU-T and ITU-D directors in some meetings. The talks are positive. We’re not in the worst time in the relationship between the RIRs and ITU.

We participated very usually in the IPv6 working groups in ITU, but there will not be any meeting this year; next meeting is schedule for March, I think, next year, but we continue following up those discussions and we continue participating.

As we are also in OECD, we participate as founding members of the Internet Technical Advisory Committee, making contributions about specific documents, sometimes with speakers in different OECD activities.

Some ongoing activities. The engineering coordination. Of course engineers are very focused on resource certification and implementation and coordination. As we made more progress in RPKI, more workshops coming up and we continue working on that.

There was an NRO workshop in February, Miami, Florida. I reported on that in the last ARIN meeting. It was a meeting hosted by ARIN.

It coincided with the time of the ICANN/IANA distribution of the last five /8s. We took advantage also the presence of many people there for having a meeting with ICANN representatives, ISOC, IAB and IETF executives.

The last NRO Executive Council retreat was held in August in Montevideo hosted by LACNIC. It was very positive. We had very constructive and proactive discussions.

And now there is a possibility of having a new I*. I* means that representatives of ICANN, ISOC, IAB, IETF, all the things that start with I except ITU. So probably we are trying to schedule a second meeting of this year in November, but it is not finished yet.

Some of the things that we have discussed during the retreat was the agreement to establish the Public Affairs Coordination Group, as I mentioned before, review and discussion of RPKI, technical coordination, review of regional discussions, and concerns.

I want to take advantage of this opportunity for saying something that I didn’t say yesterday when I went to the mic for clarifying things about RPKI. Dmitry, a member of RIPE NCC Board of Directors, said yesterday that we have to be very careful in RPKI deployment.

I want to say that we agree on that. There was a very strong agreement in the NRO EC retreat about the fact that we have to take very seriously everybody’s concern about RPKI and so we cannot ignore different concerns and fears that are being expressed in different forums. But it doesn’t mean that we have to stop our developments.

But we have to do that very carefully and take very seriously everybody’s concern, as this is what we will do.

There is also — it was part of Jason’s presentation. He already informed you about the ASO review. Raimundo Beca and Tom Mackenzie from ITEMS consultancy firm are here present in the meeting probably talking with some of you because they are performing an ASO review. That is part of our commitments with ICANN.

As a constituency within the ICANN system, we have to conduct this review that of course will be useful not only for accomplishing the ICANN requirements but will be useful for our own decisions or future decisions regarding improvements of the work of ASO review.

So please, those of you that are consulted, approached by these people, please be kind and share with them your views. And, also, as Jason said before, it’s good to have your participation in the online survey.

Okay. That’s all. Recent NRO statements and communications.

We are very active in sending letters to many people, and we have sent many letters, some of — we sent a letter to ICANN about IANA contract in March of 2011, this year.

We have also sent a letter that we already mentioned yesterday inviting ICANN to hold talks about implementation of a RPKI global trust anchor. We have submitted comments to the US Department of Commerce notice of inquiry on IANA contract, and those are the main characteristics of our comments; that we don’t support any expansion of IANA functions, we support ICANN as IANA function performer to support — we support to keep the IANA functions together. That is very important for us.

And we have introduced the idea of the cooperative agreement as a future possible step reducing the oversight function of the US government regarding IANA functions.

We have also — as I mentioned before, we sent a letter to ITU about NRO/ITU relationship recently, and we also talked about that. We sent a letter to ICANN proposing a meeting to evaluate the progresses made in technical discussions about RPKI global trust anchor.

All statements and correspondence with other organizations are available on the NRO website. We try to be as transparent as possible. If we forget something, please let us know, because it’s not intentionally. The intention is to have everything available in our website.

Thank you very much.

[Applause]

John Curran: Microphones are open for questions. Vint?

Vint Cerf: First of all, I just wanted to underscore and emphasize some of the things that you brought up, Raúl, especially with regard to the Internet Governance Forum.

With regard to the proposal from India, Brazil, and South Africa, they met one by one with a number of different groups during the IGF. I had the benefit of getting feedback from a number of those independent meetings.

Questions were raised, one of which was what problem are you trying to solve. We did not get very coherent answers. We got different answers back depending on which group they were talking to.

I have to say that the idea of creating another UN agency to oversee all of Internet governance matters does not strike me as a really wonderful move for any of us.

Second, the ITU was very visible during the IGF meeting. There was a ministerial that was held prior to the IGF, and it was very clear it was distinct and separate from it, sponsored by the ITU and by the host government, Kenya.

It’s clear that one of the major thrusts that the ITU is using to advance its interests in Internet space is security. So we heard that frequently over and over again; that the ITU felt that it had authority and responsibility in that area because it had awarded itself that responsibility from the plenipot in Guadalajara last year — or was it last year or earlier this year?

Raúl Echeberría: Last year.

Vint Cerf: – where they modified their paragraphs 101 and 102, which they’re free to do every four years.

So I just alert you to the fact that security is being used as an excuse to intervene in Internet space.

During the IGF, the question about the Internet Governance Forum conduct in the future was debated, or at least commented upon, and the most stunning presentation came from the American representative, Lawrence Sterling — or Strickland, rather, who was from NTIA.

He didn’t pound the table, but he verbally pounded the table and said under no circumstances would the US ever contemplate anything other than a multi-stakeholder IGF. And he insisted it should continue. And he got quite a round of applause as a result. The only one that I can remember during that session.

The Russians and the Chinese have made a proposed statement of principles supported also by a couple of the central Asian republics, which on the surface look like they are in aid of improving security on the Internet and moderating behavior.

But if you read more deeply into what they are saying, it also would allow for sovereign nations to constrain what people are allowed to do and say on the Net. So there’s a subtext in there that you should be aware of.

And finally I want to endorse continued interaction with the OECD because it’s an important counterbalance to UN organizations, including the ITU.

Thank you.

Raúl Echeberría: Thank you very much, Vint, for those comments.

In those talks with the Brazilian representative and also during the Critical Internet Resources main session, we made a point that was that this approach independently of the fact that creating a UN — a body under UN is a very bad idea and it’s very – it’s not feasible because the only council that has been created in the last years were the Human Rights Council, and it took 60 years to create it.

And so I don’t think it could be feasible to hold negotiations and implement a new body under the UN. But beyond that, those comments, we think, as we have said publicly, that the genesis of this proposal is wrong, because it tried to look — it tries to find a single solution for the Internet governance, for all the Internet governance. And Internet governance is composed by different mechanisms, several mechanisms that are very different among themselves.

So trying to find a single solution for improving the participation of stakeholders in — under one model is something that’s a very wrong approach. Because what we have to do is try to engage different stakeholders in every mechanism, Internet governance mechanism, respecting the specific characteristics of themselves.

An example I gave was that probably the governmental advisory committee in ICANN is a good idea. I’m not saying that’s — I don’t think very strongly probably than that, but maybe it’s a good option for improving participation of government in ICANN, but nobody could think — should think about creating a GAC under the IETF, for example. It could be a very crazy idea.

So we have maybe in the case of IETF the liaison that they have with ITU is a good way for keeping governments informed and updated about what IETF is doing.

So the genesis of that proposal, of looking for a single model of Internet governance for everything, is very wrong.

Andrew Dul: Andrew Dul. I have a question about the voluntary contribution that the NRO is making to ICANN. I believe the amount on the slide was 830,000. How is that number determined and how is it reevaluated going forward?

Raúl Echeberría: It’s very easy answer. In the early years of ICANN, even we didn’t pay any contribution, ICANN was making a calculation, and they allocated to us a hypothetical responsibility of contributing with certain percentage.

So at some point, in 2004, when we signed — 2004 — when we signed the agreement with ICANN, we took a percentage of that, the ICANN budget at that time and the calculation, the result of the calculus was $823,000. So it has remained in the same amount for seven years.

So nobody has expressed an interest in revisiting this issue. So neither us nor ICANN, as we are — you can imagine that we are not very excited with the idea of paying more. So we are happy with that.

Thank you.

John Curran: Any other questions for Raúl? No. Thank you, Raúl.

[Applause]

John Curran: We will now resume our policy development sessions. We have three of them we’re going to handle this afternoon. The first one is ARIN 2011-13, which is IPv4 Number Resources for Use Within the Region. And I will do the staff introduction to the policy and then we’ll have the AC come up.

ARIN-2011-13: IPv4 NUMBER RESOURCES FOR USE WITHIN REGION

John Curran: Draft Policy 2011-13: IPv4 Number Resources for Use Within the Region.

History of the proposal. It was Proposal 155. Submitted in July 2011. AC shepherds, Bill Sandiford and Cathy Aronson. AC selected as draft policy in August 2011. The current version is the August 2011 version in your guide and online.

The policy makes clear that ARIN should provide address assignments and allocations to organizations that are for use solely within the ARIN region.

Status at other RIRs. AFRINIC has a similar requirement in their last /8 policy, presently last call. LACNIC has a similar proposal discussed last week at the LACNIC meeting.

Staff issues or concerns. This is something that came out of ARIN’s policy experience report. We reported that ARIN is receiving an increasing number of requests where it’s clear that the intended use is outside the region.

While the definition of a RIR in NRPM 2.2 supports the principle that ARIN issues space for use within the region is not clearly stated within existing policy.

The lack of criteria has caused confusion for both staff and customers alike. Clear policy direction is needed, particularly now that IPv4 depletion is upon us, so that ARIN will issue space in a manner consistent with community expectations.

Staff notes that the proposed policy text is absolute in its phrasing, and while this appears to be appropriate for policy intent, this staff evaluation does not include any specific assessment of the resources or efforts in enforcement post-issuance since this policy proposal does not address this aspect.

I.E., it’s absolute policy. The work involved in post-issuance enforcement is not addressed by the policy. So I do not know — we are unclear if we should issue address space and find it used outside the region what the community would want or how many resources you would want us to put on following up to that.

Resource impact. Minimal. Updated guidelines and staff training would be necessary.

And legal assessment. Directionally, counsel has no concern regarding a proposed ARIN policy intended to restrict the remaining allocations of IPv4 addresses within the region. However, this policy is rigid. It prohibits any such resources outside the service region. Since a violation of the policy would justify revocation, this aspect must clearly be evaluated.

If you consider the fact that even incidental use outside the region technically would trigger, I don’t know whether any of you would suddenly like to have your resources revoked because of a misconfiguration, which this would actually potentially allow, just because it ended up on a router that was outside ARIN’s service region.

That concludes — PPML discussion. Little discussion of the draft policy. Earlier discussion of the proposal. 30 posts by 14 people.

“Oppose. It imposes topological considerations on newly assigned resources for multi-national operations domiciled in the ARIN region in a way that favors some new entrants or returning resource holders over others.”

“I could perhaps be convinced to support a modified proposal which indicates the organization requesting the addresses must show the intent to use the addresses substantially within the ARIN region (whether that’s 33, 51, or 98 would be another discussion).”

So that concludes the staff introduction, and I’ll now invite Bill Sandiford up to give the AC presentation of the policy.

If you wear glasses that look like this, I have them. You don’t. They were in the lunchroom. So if you need glasses and you had them earlier today and you don’t now, this might be yours.

Bill Sandiford: Good afternoon. This policy was authored by Robert Seastrom who normally likes to do this himself but he got married this week. So if he’s watching on the remote, congrats to Rob. But turn it off because you’re not supposed to be watching on your honeymoon.

As was stated in the rationale section of the proposal, the problem that was attempted to be addressed here was that the various RIRs will exhaust their free pools at different times, creating a situation in which requesting organizations can attempt an end-run on ICP-2 and the RIR framework by coming directly to ARIN for space to use outside the region.

In other cases, subsidiaries, sister organizations located within the ARIN region, or global organizations that have a presence here could have requested space that is ultimately destined for use in other areas.

It was believed that failure to address the situation in a timely matter could grant an unfair advantage to large multi-nationals who could then shop around for their RIR of choice and hasten free pool run-out in our region.

The policy text was to insert two statements into two sections of the NRPM, basically to ensure that organizations requesting IP addresses from ARIN must provide documentation to demonstrate that the number resources will be used in this region.

Like I said, it’s two sections. So that was a bit long. And that’s pretty much it as far as what to present on the policy.

John Curran: Microphones are open.

Mike Joseph: Mike Joseph, Google. I strongly oppose this policy. It would make it impossible for any multi-national entity to continue to receive address space from ARIN.

There are fundamental elements in this policy that if adopted in all regions would prevent certain types of business operations from continuing worldwide. For example, if you have space that is portable within your network or served for an anycast use, it would be impossible to use that space obtained from ARIN and if adopted by other RIRs any IP space for such uses.

While I support and agree with the intent of the meaning RIR shopping, this policy is poorly written and misguided to that end. I think further policy work is needed, but this policy in its current form should be strongly opposed.

Tim Denton: I’m just going to go through the — so Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. This policy is a disaster for members of the ARIN region and for the Internet as a whole.

As was said, we do need to do something, but this ain’t it. I put a couple of proposals out there for changes to the text on PPML, and I’ll leave it at that. Thank you.

Tim Denton: Thank you. Mr. DeLong.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I’ll echo what’s been said without repeating it, particularly the issue that this could result in — if this policy were adopted, ARIN could, on a theoretical level at least, turn around and immediately conduct Section 12 audits of just about every multi-national ISP in the ARIN region and revoke their space solely on the basis of this policy. I think that would be a bad thing.

Tim Denton: Mr. Pounsett.

Matt Pounsett: Matt Pounsett, Afilias. Like some other people have said, I support the concept behind this, but I can’t support this as written.

Virtually all of the addresses that we have are anycasted. We use them in the region. We use all of them in the region, but we also use all of them in other regions.

And the way this is written, it would prevent us from doing that and we’d be out of business basically.

Tim Denton: Thank you. The gentleman over there.

Dani Roisman: Dani Roisman from SoftLayer echoing the lack of support for this proposal. It would definitely put many multi-national ISPs at risk. Not only do we already have situations where we may have customer demands where they’ve asked to relocate services from our servers in one country to another country to assist with performance reasons, but they don’t want to renumber. There are other reasons why multi-nationals might end up using addresses from one RIR elsewhere on their network.

One of the other concerns that I have, though, based on what was written is there is no — there was a statement regarding requiring a demonstration of use within the region. I think it’s too vague and too difficult to demonstrate how an ISP would definitely use these IPs within the region.

I think also to echo some previous comments we heard this week, this is yet one more policy. While it seems nice to try to keep people from other RIR regions from coming over to our playground and stealing our toys out of the sandbox, the end result is actually further extends — artificially extends the life of IPv4, so I think this policy is also a detriment to IPv6 adoption.

Tim Denton: Thank you. I saw Marla next.

Marla Azinger: I’m opposed to this policy. One, I’m a little shocked that it’s even being talked about. It shouldn’t have been put on the agenda, in my opinion. That’s my personal opinion.

But you would find ARIN, I think, in court a lot if we passed this, because there are, as other people have said, multi-national organizations and it is dispersal a bit.

I’m also wondering why there’s really a problem, because I have already actually requested address space specifically solely for outside of the region, and it was denied.

So I think the staff understands what’s going on already and there isn’t actually a problem.

John Curran: An organization which is asked “Do you intend to use this address space within the ARIN region” and says no is indeed turned down. We reference NRPM 2.2 and we say that’s clear.

An organization which is incorporated recently in Delaware and indicates that it has a robust virtual infrastructure of many, many, many things to be numbered but coincidentally is related to an organization located in another region that may not have a lot of address space that is seeking a very large address block because its combined global operations is using a lot of address space turns out to be an interesting problem if they say some of them will be used within the ARIN region. Okay?

So that’s the kind of problem we face, is when someone is looking for address space because they definitely need it, the need is predominantly based outside the US, but there is US usage, it’s very difficult for us to point to policy and deny that.

Marla Azinger: I think my point is clear enough. I tested the system. It’s working like it should, how we need it to already. And this is not a good answer.

Thank you.

Tim Denton: I see the two gentlemen, Matthew Kaufman and the man behind him is 8 and 9. Mr. Sinatra is No. 10 and the gentleman here is No. 11.

So Matthew Kaufman.

Matthew Kaufman: Matthew Kaufman. I strongly oppose this. I would like to question ARIN’s staff on the analysis. I’d like to know — it seems like it’s a non-trivial amount of work to have a field that actually explicitly marks the addresses that are subject to this policy versus the ones that are not.

And I also would like to know how ARIN staff intends to detect this out-of-region use, which also doesn’t appear to be in the analysis of how difficult this is.

In addition, I’ve been in several multi-national entities where we routinely take address space that was used in a lab in one location and have a lab in India do quality assurance work, for instance, and we would simply VPN the entire network over to them for a while and then back.

I don’t understand why that’s necessarily a trigger for an audit and a revocation. The rest of the issues I have on my list have been covered.

John Curran: To address your staff question, specifically the policy evaluation said the same thing you did. The evaluation is based solely on enforcing the policy at the time of the request.

The ongoing efforts, automation and level of enforcement, are not addressed in the policy nor in the staff review.

Tim Denton: Sir.

Sean Kennedy: Sean Kennedy, XO Communications. I object to this for the similar reasons; that I don’t think it’s appropriate for ISPs in the ARIN region, particularly network operators that have infrastructure overseas.

I would support something specific to provider-independent address allocations which could be based on the upstream ASNs which ARIN already collects and some language enforcing how that’s routed.

I also think there are other things that weren’t considered, such as if RIPE, LACNIC, AFRINIC and ARIN all have these proposals, what about RIPE providers that are in the US for interconnection purposes; when they renumber to ARIN space, how are they going to get that space? What if their three-month projection is not a /22 because they have five interconnects that each need a /30?

Lastly, as a provider which could lose an allocation because of the actions of my customers, there’s an implicit need for me to track where my customers are allocating these addresses without any change to 4.2.3. I can’t go to my IT organizations and say: You have to change the provisioning systems to make sure and track where customers are using these IPs; you have to spend the money to do that as a defensive mechanism.

So if the policy were to be changed, there should be corresponding changes in other parts of the policy manual.

Lastly, 2.2 does not say that ARIN only operates in the ARIN region. It says its primary function is in the ARIN region. But the history of interconnection in the US is slightly different, where lots of other providers from other regions have come here to interconnect: Miami, DC, LA. And that’s different than what’s appropriate in LACNIC. So that should be addressed in a policy and is not.

Tim Denton: Thank you. Mr. Sinatra.

Michael Sinatra: Michael Sinatra, ESnet. Just a suggestion that this may be an instance where the Chair wants to do two shows of hands, one for the policy as is to move forward, and if there is an outstanding lack of support, then a second one as to whether the AC should continue with this overall task of trying to —

Tim Denton: Yes. This is being whispered in my ear.

Michael Sinatra: Okay. I’m actually interested in what the community thinks about the overall.

Tim Denton: Sir, you were next.

Igor Gashinsky: Igor Gashinsky with Yahoo! I would like to echo all the other people who said that – who think this is an extremely bad idea. We do tend to shift resources around to meet global demand, and sometimes those resources come in chunks of /16s. They could be shifted temporarily, for a couple of hours, they could be shifted for a couple of months.

What’s more, anybody who runs a worldwide network tends to IP the entire network out of one region, tends to be whoever is — wherever the headquarters is. You then tend to IP the services that serve that network out of that region as well.

So this policy would make life incredibly difficult for a lot of people, and a lot of people today would be in violation of this policy.

I understand the reasoning for wanting to do something, but this particular thing is a really bad idea. So thank you.

John Curran: ARIN staff gave in the policy experience report — noted that there’s the potential for addresses to be issued whose use is solely outside of the ARIN region.

We don’t say policy needs to be changed if that’s what you folks want. What we’re saying is this is how we are seeing people come. If someone right now comes and self-declares that their address request is for entirely for use outside the US, we will turn it down.

If they say something else — or outside – I’m sorry, not the US, the ARIN service region.

If they say something else, then they will get address space. This is not necessarily a good or a bad thing. It’s something for the community to know.

If the community supports how we’re handling it today, there’s no policy needed. If the community thinks clarity is necessary, then a policy is needed. Staff is not advocating for a policy, just pointing out how the policy is being experienced in time today.

Tim Denton: I see Mr. Leibrand came up, then I have Mr. Cerf and Alain, Mr. Echeberría, and then you.

David Farmer: I have a remote participant. That is David Williamson from Microsoft Tellme. He says: I oppose this policy as written. The absolute phrasing is incompatible with realistic usage and better phrasing might make more sense.

Tim Denton: Mr. Cerf.

Vint Cerf: Vint Cerf, Google, speaking for Vint Cerf. This policy and some of the other things I’ve heard are architecturally nuts.

It seems to me that autonomous systems are intended to operate topologically and it shouldn’t matter where the IP addresses are.

If there is a policy that forces people to split up autonomous systems into different IP address groups, there’s something busted about the idea. I oppose this.

Tim Denton: Alain?

Alain Durand: Alain Durand, Juniper, speaking as myself. I oppose the idea of this policy. We had a great presentation from Geoff Huston yesterday that was showing the bad things that happened when the different regions run out at different time. We had a great statement this morning from Jason Livingood who was saying it will be better for this industry to all run out at the same time.

All those types of policies essentially are protectionism, trying to say we are going to extend the life of IPv4 in one region against the life of IPv4 in other regions are actually doing harm, they are not doing good. I oppose this.

Tim Denton: Señor Echeberría.

Raúl Echeberría: Thank you. Just to clarify that this — a similar proposal was discussed in LACNIC last week, but it was not – the proposal didn’t get consensus.

And according to discussion that is being held in the list, it seems that the authors are looking for a different approach now due to the same constraints that were expressed here for applying a policy like this one.

Kevin Blumberg: Kevin Blumberg, The Wire. I’m opposed, like everyone, but I would actually ask the question: If there is a concern about the stretching of the truth of “Are you using these IPs in the ARIN region,” you can ask for clarification in the beginning saying “Are you predominantly using this in the ARIN region,” and if you find out after the fact through whatever means that they lied, you now have the means to revoke based on fraudulent information.

And that I feel would be acceptable if you’re concerned about protecting the IP space. But I don’t feel as this is written it in any way does that. It goes way beyond that. Thank you.

John Curran: I think we have two-thirds of what you just said, we actually have operational, meaning we do ask where you intend to use the address space. We do use that for the basis of deciding whether or not to issue you address space.

I think an earlier speaker indicated it is possible to hear no. What we are not doing is following up. And I will note that in the absence of some pretty clear policy, we would not follow up on this at all.

So that is certainly an area where in particular if you would like us to go back to people-issued space and double-check that they’re using it predominantly within the region, we would ask for language to that effect in the NRPM.

Kevin Blumberg: I guess the point is that the way I understood it from you is that if a little bit is being used, as you said, of a much bigger block, that would be allowed if there was some. And what — I guess the question is: What is “predominantly”? Is “predominantly” currently in the text?

John Curran: At present there’s no clarity in the text regarding the amount or the ratio.

Someone who self-declares to not be using them within the ARIN region gets turned down. Someone who needs address space in the ARIN region but doesn’t necessarily state what the ratios are and some might be outside, the staff has no guidance on how to handle that request.

Kevin Blumberg: So, again, that is the portion that I would feel more — as an area that could be worked on, but not like this. Thank you.

Tim Denton: Mr. Farmer and then Mr. Joseph.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I would even be opposed to a “predominant,” at least by going by a general definition of predominant.

I put out some — just some basic scenarios where it’s quite easy for a multi-national corporation to think of itself as homed in the ARIN region, get its addresses from the ARIN region, and still use most of that address space outside of the ARIN region.

But none of its use outside of the ARIN region or in any of the other regions is any larger than its use in the ARIN region. And just from a basic idea of would I think of that corporation as homed here in the ARIN region would be yes.

And so we need to be careful about this, and I think the problem is worse than the — or the solution is worse than the problem.

And so probably unless people have some much better ideas on how to solve this, I’m going to want to make it go away.

Tim Denton: Thank you.

Mike Joseph: Mike Joseph, Google. Actually, David just touched on exactly some of the concerns that I had as well with “predominant.” I think “predominant” is also problematic. I might need 30 percent ARIN, 25 percent RIPE, 20 percent LACNIC, et cetera, and that may not meet the definition of prominent, but as a US-based corporation looking for address space to use worldwide, that certainly should be allocated from ARIN, in my opinion.

I think if the Chair takes the earlier request to poll the room for interest in the general topic, then perhaps a further discussion during open mic might be sensible.

Tim Denton: Mr. Schiller.

Jason Schiller: Jason Schiller, Google. Wanted to make two points, one question on this “predominant” discussion. I’m just trying to follow what you were saying.

Are you suggesting that you would be in – this is a question to David Farmer. Are you suggesting that you would be in favor of a policy that required at minimum 20 percent of the address space to be used in the ARIN region? That way if ARIN was their largest region where they decided to home their headquarters and they were in all five regions, doing the math, 5 goes into 100 percent, 20 percent, so is that sort of the type of approach you were recommending?

David Farmer: That was the approach I recommended on PPML with maybe an additional clause that says “of the regions ARIN has to be the largest.”

Jason Schiller: And then the other thing I wanted to point out is the policy we’re currently discussing does not have a retroactive capability to it. So any allocations or assignments given out prior to this policy being adopted, that space would not be in jeopardy of being revoked because of this policy.

Tim Denton: Thank you. Cathy Aronson.

Cathy Aronson: Cathy Aronson, Cascadeo, ARIN AC, whatever long list. Two things. One, I just wanted to make a clarification. I’m not really speaking in support of this proposal, but there was a misconception earlier that someone’s previous space could be revoked if they used it out of the region, and this specifically says address space from this policy forward, so I just wanted to say that.

Also, what if you’re a — I was once a – well, I worked for a multi-national company sort of that had networks all over but only had one headquarters that was here in the United States.

So what then? Because I can’t get address space from another registry because I wasn’t incorporated in another region. So what do I do then?

Tim Denton: Thank you. Marty?

Martin Hannigan: So I’m not in favor of this policy either, and for all the same reasons everyone else is, but there’s also some nuggets to think about with respect to exhaustion.

Even though this doesn’t affect my prior allocations, am I supposed to eat the ones that I stopped using later or I have need in another region and I have availability of ARIN address space but because I can’t use it in that other region I’m supposed to transfer it to another region?

I think there’s a lot more to think about with respect to this, and I do think it’s a little bit insane. And I also agree with Marla that I’m not quite sure how it got to the forum.

Bill Sandiford: Well, I’m so glad you said that, because I was about to address that. One of the reasons it got here, I was specifically thinking of Marla’s question, if you actually read R.S.’s comments on PPML after people started responding to the initial – when the policy text first went out, he admitted — he said, you know: I don’t think this actual policy will solve this actual problem but it’s meant to foster this discussion because there is more work that needs to be done in this area.

And I know from my perspective alone, I felt that simple abandonment of this policy would not allow that discussion to be fostered and ensue.

So I spoke with R.S. about this. And my personal view was the best way to ensure that discussion ensued was to get it to the meeting in this forum, and those thoughts have sort of been proven right. We didn’t have a single person speak for the policy, but we had a lot more discussion and debate about it and about alternatives and suggestions than what came on PPML with the original policy text itself.

So from my perspective, that’s how it got here. And I’m glad to see the discussion that ensued.

Tim Denton: So what we’re going to do is we’re going to have our usual voting for or against the proposition as written. And then we’ll have a second voting for whether the concept should be further pursued in the AC.

So the first round of voting will concern are you in favor of the proposition as written. Would you please raise your hands.

A wasteland. A nullity. A blinding desert.

Assuming we’ve seen everyone who would be in favor of this proposition, how many would advise against the adoption of the proposal as written?

A thick forest. A consensus.

Bill Sandiford: It is possible.

[Laughter]

John Curran: Yes, it is possible to make a policy that everyone hates.

[Laughter]

John Curran: Sometimes we even adopt them.

Tim Denton: The counters are still counting? Okay. No, no. What I now propose is the second question — is it all right if we take the second question, counters?

John Curran: Let them finish.

Tim Denton: In relation to the matter at hand, those in favor were nil, zero, zip, and those against were 56.

So now I would like to ask the second round of the question, which is do you think the topic should be pursued by the Advisory Council? Would you signify your ascent to that idea by raising your hands.

Now those who would counsel the Advisory Council not to pursue further exploration of this issue, please raise your hands.

In relation to the matter whether this topic should be pursued further by the Advisory Council, those in favor of the proposition — total number of people voting here or in remote were 124. Those in favor of further pursuit of this topic were 10. Those against were 33. And that concludes the matter. Thank you.

[Applause]

John Curran: Very well. The next policy proposal is ARIN 2011-1: ARIN Inter-RIR Transfers.

I will do the staff introduction to it, and then I’ll have Bill Darte from the AC come up.

ARIN-2011-1: ARIN INTER-RIR TRANSFERS

John Curran: Draft Policy 2011-1: ARIN Inter-RIR Transfers. Origin was ARIN Proposal 119 in October 2010. AC shepherds are Bill Darte and Rob Seastrom. AC selected as draft policy in January 2011. It was presented at ARIN XXVII in San Juan. It remained active on the docket. The revised version is revised as of 22 September 2011. That version of the text and the staff assessment are available online and in the Discussion Guide.

Summary. The proposal would allow transfers of address space to and from the ARIN region as long as both RIRs agree to the transfer and apply compatible, needs-based policies.

Status at other RIRs. There is an Inter-RIR Transfer policy adopted at APNIC. There is a panel discussion at the last LACNIC about the same topic.

Staff assessment. The present language is unclear, vague, and open to interpretation. The phrase “compatible, needs-based policies” is undefined. While many in the community understand the intent, it’s important that the policy text be clear and understandable to all.

The phrase “which otherwise meets both RIR policies” is also vague. Which policies must the transferor and transferee meet of the set of policies at the respective RIRs, or both policies of the respective RIRs for both parties? The text should be revised to precisely convey the author’s intent.

Staff provided an outline of how the policy would be implemented based on our reading of the text that exists.

There is the possibility of zone fragmentation and reverse DNS issues which the RIRs would have to work together to address.

Resource impact. Significant, regarding those reverse DNS issues, because you’re punching holes in zones managed by other RIRs. It’s not insurmountable, but particularly with the automation that we’re all doing, it requires a little bit of thought.

Legal assessment. Counsel suggests one major addition to the policy, which may be totally consistent with the intent. Currently it’s the understanding ARIN policy does not permit transfers within the region unless resources are covered by an RSA or LRSA. The language of this section might be properly clarified to reinforce that resources not already under registration service agreement may not be transferred until ARIN has validated the correct resource holder.

PPML discussion. 38 posts by 12 people; 5 in favor and 2 against.

“This is not a perfect policy, but is another one of the IPv4 pragmatic policies we need to pass and move on.”

“Opposed. There is substantial need for IPv4 at every RIR. One is not more important than the other, so there should never be a policy permitting a transfer out.”

“Concerned that the staff report stating this was a major implementation. If a company decided to transfer out a thousand /24s to a thousand different companies, that would be a lot of time/cost that the region would be burdened with.”

That concludes the staff introduction of Draft Policy 2011-1. I’ll invite Bill Darte up to give the AC introduction.

Bill Darte: Thank you. So the principle that this draft policy is based upon is, to the extent possible, IPv4 addresses should be available for use. IPv4 addresses should be distributed to those who have need.

Those with available IPv4 addresses should be able to specify the recipient of their choice. RIR policy should given those transfers and should control the registration of those resources.

The name is a misnomer — it’s been misnamed a couple of times now, it seems to me — that the policy really ought to be entitled “Inter-regional Specified Transfers.” The intent is to expand the existing NRPM 8.3, Specified Transfer Policy, to give those wishing to transfer IPv4 addresses the flexibility, more flexibility, in doing those transfers.

The Specified Transfer Policy, as is available in the NRPM, is written here, but basically in summary the ARIN community has created a policy allowing entities to specify for transfer of their available IPv4 addresses to another entity within the ARIN region.

And while it does not expressly suggest that compensation can be made for that, it doesn’t preclude it either. So I think it’s well understood that compensation for the effort needed to make those addresses available might be recompensed by the receiver.

The draft policy text is my bad. I’ve counseled the AC for years about making overly detailed and complicated policy statements and then fell into it face-first myself. It’s bad, and it needs revision. So let’s assume that that’s the case, but go to how it got to be that way.

So we’ve actually talked about this draft policy and policy proposal before that for quite a long time. And the attempt at writing this was to be rather explicit and encompass a lot of the suggestions that were made at various meetings and in many meetings within the Advisory Council itself.

So it was suggested that any policy in this area should be reciprocal, both allowing in- and out-of-region transfers; that the transfers are between the RIRs that support needs-based policies; that RIRs have to agree that this is an appropriate thing to allow; that the parties meet all of both RIR policies.

That would be for those transferring out, whatever policies are in place that govern transfers in that region would have to be satisfied, and for those receiving those in another RIR, the recipients would have to be in concurrence with the policies of that region for receipt.

In other words, again, perhaps needs-based. They would have to demonstrate need for those resources.

It’s certainly a needs-based intent, and the need is for networking purposes that the receiving RIR is entitled to the addresses. In other words, they have need.

It’s not explicit about some things that were also discussed at one point or another about block sizes.

Would this allow, as the one comment suggested, somebody deaggregating a block into a thousand /24s and sending them out all over the world? Is that a reasonable thing?

It doesn’t talk about utilization or prior allocations. It doesn’t talk about assignments or transfers. It doesn’t reference RFC2050 anymore or subsequent transfers.

So there was a lot of detail that was discussed that was never incorporated into this badly worded policy statement.

But if enacted — I’d like to get to the heart of the matter here — if enacted, entities could release IPv4 resources to ARIN for transfer to another entity within ARIN, those entities demonstrating need for those resources. That’s what 8.3 currently says. Or to another entity needing resources in any other region.

That would be the enhancement of the 8.3 NRPM statement. Or receive needed resources from another region. And that’s the reciprocal form of this. And conform to existing policies that would govern those transfers both out and in.

I think what we’d like to see here is policy that would allow people who have resources to in fact specify where those resources should go.

If you were the entity — and I would ask your indulgence on this and think about it. If you were the entity freeing up resources that you would like to specify for transfer to someone, would you want the most flexible opportunity to identify the recipient?

And if there was a compensation issue, you know, would you want to be able to be compensated by the highest bidder, for instance.

You would have the flexibility of course if you didn’t think transfers should take place outside of the region of not doing so.

This policy is about giving the transferor the opportunity to have the widest choice in how they would specify those transfers, all of which would be needed to demonstrate need for those transfers.

So that’s what I think that the guidance that the AC would like from you is whether we should allow transferors of IP addresses to have the greatest flexibility in identifying who they’d like to transfer those resources to.

And I’d welcome your comments.

John Curran: Microphones are open.

Tim Denton: Matthew first.

Matthew Kaufman: Matthew Kaufman. First I’ll answer that question. Yes.

What I don’t understand is why we need all of the complexity here. I don’t understand at all why we can’t simply delete within the ARIN region from 8.3 and make them sign an ARIN RSA and be served by ARIN.

Just like we talked about a minute ago, there are organizations that have some, part, all of their address space outside of the ARIN region managed by ARIN. I’m sure there’s a good answer. I just want to hear.

John Curran: If this community so directs ARIN to serve parties outside the ARIN region, we would need to engage with discussions with the other RIRs, because we are party to agreements, such as ICP-2, which talk about us serving specific geographic service regions for very good reasons.

I’ll note we worked very hard to establish RIRs locally in other regions for areas such as local autonomy and language, and we’d be running contrary to those very reasons by serving them.

I’m not saying it could not be done. If directed by the community, we’d engage in those discussions. But presently we have a service region and we’ve agreed to have a service region with a group of other RIRs as part of a given policy.

Matthew Kaufman: I understand all of that. But this is – what we’re talking about is hopefully incidental registration out of region rather than — which does not seem nearly as complex as everything else that’s proposed here.

So the answer to the question proposed is yes, but I think this is the wrong policy for getting there.

Kevin Blumberg: Kevin Blumberg, The Wire. Yes, this is the wrong policy. I have two concerns with it. One, it saddles ARIN members with costs that are inappropriate, given that the transferor more likely will be monetizing these transfers.

I do believe if this is going to happen, it should be adequately compensated. We should not be paying for it, in resources. That’s the first thing.

The second thing is I am concerned that this policy is a floodgate, not a spigot, and I would like to see the policy have an end attached to it in terms of the size of the total transfer outs at which point it can be relooked at within the community. I would suggest something along the lines of 5 percent of total, both legacy and non-legacy, space managed within the ARIN region as being the end at which point it can be revisited.

John Curran: Regarding the point about cost to the region. I want to be clear. This doesn’t talk about fees. ARIN has the freedom. The ARIN Board can direct to have a fee charged for processing a transfer.

That would be a one-time fee, most likely, if the transfer was then to another — to someone registered in another RIR and that other RIR was then providing directory services and reverse DNS services.

So it is possible to recover those costs in a one-time fee. If you don’t think a one-time fee is suitable and ARIN both should incur the costs of the transfer and the costs of the ongoing services, then, obviously, if we had ongoing services, we’d need to have ongoing fees.

Matthew Kaufman: No, a one-time fee is appropriate. It’s because I saw the staff assessment that said this would be a burden I feel it’s important to mention.

Tim Denton: Marla Azinger, please.

Marla Azinger: I support the policy, I just have a couple of concerns about stuff that’s in it. The networking purpose has to be deployed within three months. So depending on the amount of address space that is said to be transferred, they may not need to actually deploy all of it in that first three months and it may be over a period of a year or two. I don’t think we need routing statements out there that don’t need to be out there.

So I’m concerned about a statement in here saying route it all now. Because you know that’s what’s going to happen. It’s deployed. It’s routing.

So I just think that’s not necessary to be in there. I think the reason you put it in there was probably so you would be guaranteeing that people aren’t getting space they really don’t need. But I think we have other measures in place that are controlling that, so it’s just an unnecessary item that’s in there.

Also, I don’t think that — I think it’s needed. I don’t think it’s going to be used possibly as much as some people might fear, because when you do have said transfers occurring, it’s more likely that it’s going to be existing companies and they’re just using it in different areas and not necessarily really needing to transfer it out of that entity.

So I think this policy is good. I actually don’t have the fear factor of it doing damage.

Tim Denton: You, sir.

Randy Whitney: Randy Whitney, Verizon. I support this policy. I also agree with her point of view about the three month. I have concerns about that.

But I did want to remind the room that APNIC did restore a needs-based transfer policy, so the one objection that people will possibly raise has been solved.

Tim Denton: Are you finished with your comments?

Randy Whitney: Yes. He had a comment or something, so I don’t know if it was to me or not.

Tim Denton: Are you just in the queue? Okay. Thank you. I have no idea, but Mr. Pounsett.

Matt Pounsett: Matt Pounsett, Afilias. To answer your question, yes. Although, yeah, I’m not entirely certain about the wording. I actually have a question for Bill.

The way I read the meeting RIRs policies phrase in here, the way I read it, the receiving entity would have to meet the requirements to receive that address space in both RIRs.

But something you said in your lead-up made me —

Bill Darte: The intent of the wording was to suggest that in the area where the transfer was originating, the transfer would have to meet whatever policies for transfer were available.

On the receiving end, the recipient would have to meet whatever needs-based policies or other policies direct their location in that region.

So the recipients would have to meet the receiving RIR policies and the transferors would have to meet the policies in the originating RIR. That’s what the intent of the statement was.

Matt Pounsett: So I don’t think the intent agrees with the language there, so that would need to be fixed.

Tim Denton: Mr. Curran.

John Curran: ARIN staff had difficulty discerning the intent of the policy language but specified how it would implement the policy and would ask that the AC make the policy language match what Bill said and our implementation rather than what it says today.

Tim Denton: Now that we have one microphone and three people behind it, even I can do this job. So you’re up next sir.

Dani Roisman: Dani Roisman with SoftLayer. I agree that we definitely need a mechanism to allow for transfers from inter-regional registries.

I had one question, actually. A couple comments, one question first. I heard in the hallway from what I believe is a reputable source that currently you can transfer resources.

I was directed to give it a try and ask APNIC, for example, hostmaster at APNIC, to take one of my ARIN allocations and transfer it over to APNIC and that APNIC would more than likely actually facilitate that.

Is that actually the case?

Tim Denton: Go ahead.

John Curran: There has been a very small number of transfers that have actually been accomplished inter-RIR when organizations have completely picked up and relocated from one place to another, and we’ve matched the serving RIR back in the earlier days of the Internet to match where they are now residing.

That’s probably less than I can count on my hands. But it has occurred. It would be much better for us to not do that because you think it’s the right thing but to do it because we have certain policy.

Dani Roisman: So I do think we need governing policy. I don’t think this is it. I think a few things that are missing are, for example, there was a mention of the burden on DNS. I think there needs to be clear guidelines to prevent a burden on DNS. An example was it may be to – there’s a finite size, maybe it has to be on a bit boundary, et cetera.

I think also there may be organizations that may consider doing inter-regional transfer in order to meet the interregional usage requirements. So, for example, a multi-national who then says, well, I have these resources I’m using elsewhere. In order to meet my 2.2 requirement for my future addresses, I need to first move some of my addresses away.

I’m also interested to learn whether or not this policy was supposed to assist organizations in multi-national situations where they’re using their resources elsewhere or if the motivation was to assist with third-party transfers or other-party transfers, for example, open market, where the seller and buyer may be in different regions.

Tim Denton: Are you done? Thank you. Then I have Owen, Chris, Martin Hannigan, and then Alain.

Owen DeLong: I think Martin might have been in front of me, actually, but Owen DeLong, Hurricane Electric.

I’m not wild about this policy. I’m not wild about the existing 8.3. But if we’re going to have a transfer policy and we’re going to have this situation where we’re all moving IPv4 blocks around in random different ways to pretend that the end of the world isn’t nigh for IPv4, and we want to try and pretend we can pour additional life support into this dead protocol, then it does not make sense to limit it to intra-region transfers only.

It’s harmful on a global scale. It’s causing problems today. It will continue to cause an escalating amount of trouble as we go forward, and we need not to do that.

It’s time to think globally and act locally. I don’t like this policy, but it’s one of those things where I don’t like the consequences of not passing it even more. So we need to just sort of hold our noses and do it.

Tim Denton: Mr. Grundemann, then Mr. Hannigan and Alain.

Chris Grundemann: Chris Grundemann. I won’t take too long because I think most of what needs to be said has already been said, but I feel strongly enough about this issue that I wanted to say it again very briefly.

This is a very necessary piece of policy. This is something that needs to be done for a number of reasons that have already been stated. And I think that the AC, at least several members of the AC, understand that the text needs to be cleaned up.

And the basics is just that the sender would have to comply with the sending RIR’s policy, the receiver would comply with the receiving RIR’s policy, and we’re done. It becomes very simple and I think very straightforward and, again, quite necessary.

Thank you.

Tim Denton: Just a sec. In queue I had Mr. Hannigan and then you.

Martin Hannigan: I don’t have an opinion on this proposal or potential policy either way, other than things change rapidly, and I think that the intent that we define things today may not actually match the intent that we would have in the future.

So, for example, my colleague, Randy, stated that APNIC restored a needs basis but they could just as easily unrestore that needs basis.

I understand that that would cease transfers based on the language that I’m reading here, but I think that, regardless, it matters.

And with respect to which direction the transfers are going to go, I think initially it’s clear that they’re all going to be out, not in, and that at some point they will be in.

But, again, neutral.

Tim Denton: Thank you. Alain.

Alain Durand: I would just like to say plus one to what Chris Grundemann said a minute ago. We need a policy like this. It needs to be cleaned up exactly as Bill Darte explained, and please make it as simple as possible.

Tim Denton: Scott Leibrand.

Scott Leibrand: So we have a pretty clear consensus, I think, that we need to do something. The last time around we seemed to – six months ago we seemed to have a consensus that we should do something along these lines, but we couldn’t agree on what.

We had lots of suggestions. We ended up with this text. I do not want to go back and do this, another round, in another six months, because I believe we are at a critical time where we must get this going quickly.

But we must do it in a way that has appropriate text; that it actually works and doesn’t create a giant sucking sound or any of the other things that people were worried about.

So there’s been a few suggestions going around in IM even just in the last little bit.

I would really encourage people to think about and hopefully discuss how do we structure this policy so that this does what we want and doesn’t allow what we’ve been calling the wash-rinse-repeat cycle of get addresses from the free pool, transfer them to somebody else who needs them in another region, come back, get more addresses from the free pool, and make a big profit doing that.

If we want to transfer addresses to other regions, maybe we should do it directly, but that’s another discussion for after this particular policy.

So if anyone has any opinions on ways that we should structure this text, please get up and talk about it now while you’re thinking about it, because last time around we asked you to post to the list and we ended up with a bit of a hodgepodge. I think we need to get that discussed now.

Tim Denton: Microphones remain open. Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I was chairing one of the lunch tables, different topic, but part of the topic that we were discussing came up the wash-rinse-repeat cycle.

And one of the thoughts we had on taking care of it at the table was what if you transfer addresses out of your organization. In order to get any new addresses out of the free pool, you have to do slow start.

That was the thought we came up with. Basically what it’s saying is not that you can’t have more addresses, but that you’re going to be under the scrutiny level of slow start, which I don’t think any functioning ISP really wants to be under of any size.

And so you would not want to transfer addresses out then get more addresses and be under slow start, because you would impact your business.

And just to add to that, and then the part of the reason that came up was the idea that, well, it’s essentially what you would be doing if you were just creating corporations and then transferring their resources out.

Tim Denton: Thank you. I see Louie, and then I saw you, sir, and then Mr. Schiller.

Louie Lee: Louie Lee, Equinix, also Chair of the ASO Address Council. I support this policy as written, for all the problems it’s still got, but it’s something that we can deal with in another six months, but we should still adopt this policy.

Mike Joseph: Mike Joseph, Google. I support this policy in principle, but I agree that it needs quite a bit of cleanup. For one thing, it lacks any reference whatsoever to the NRPM or a change to any particular section or any language.

I do think it’s worth considering as that language is drafted the risks previously mentioned of new entrants forming and then transferring out, perhaps some time limit on entity length within ARIN or some such before they would be eligible to transfer out of region.

Although, to be honest, that may be moot since we just rejected preventing multi-nationals from acquiring space in ARIN anyway.

Tim Denton: Thank you, Mr. Joseph. Mr. Schiller.

Jason Schiller: Jason Schiller, Google. I too am concerned about the wash-rinse-repeat concerns that other people have voiced.

I do not think a slow-start approach, as David Farmer suggested, would be at all helpful. I do not believe that ISPs who are growing will be transferring any resources out. And ISPs that are not growing who are transferring resources out, well, they’re not growing, so they don’t need additional resources, so slow start doesn’t necessarily hurt them.

But I think it’s primarily going to be smaller organizations that are transferring this space. And I think the appropriate way to deal with it is to put some sort of limit on — once you’ve transferred space, whether inter-regionally or locally, that some time limit kick in that you cannot get additional new space either through transfer or from an RIR until such time limit expires.

I’d also like to see some other rewrites. If clearly the rules that apply to the transferring in or the transferring out, for example, with what I’ve heard today, which is not reflected in the text, is that to transfer space out of the ARIN region you have to follow all of the policies that apply to transferring space in the ARIN region to another party in the ARIN region.

And the recipient who is outside of the ARIN region, to receive that space, that recipient must meet all the criteria of transfer recipients in that receiving region.

I believe that’s what people think this policy should say, but that’s clearly not reflected in the text. And that should be cleaned up, if that’s what people want. If that’s not what people want, then I’m misunderstanding the conversation.

Mike Joseph: Just to clarify real quick. Mike Joseph, Google. When I was referring to a time limit, I agree with my colleague, Jason, but also would say there ought to be a time limit on how long you must have held the resource before you could transfer it out as well.

Tim Denton: I see you, sir, and then Heather Schiller.

Andrew Koch: Andy Koch with TDS Telecom. One thing I just want to make sure that’s clear, when we say transfer, we’re dealing with 8.3 transfers and not 8.2? Is that correct?

Tim Denton: Correct.

Andrew Koch: Okay. If acquisition of a company happened of some sort, that would be a concern.

Heather Schiller: Heather Schiller, Verizon. I agree with the last point that Mike from Google made. That I think this sounds too easy to game; that a company comes and says, Okay, ARIN, I need space. They pay for it. As long as the amount they make is more than what they paid to get it from ARIN, when they transfer the entire resource away before the end of the year, they don’t have to pay for it again, and then that organization pays for it in another region.

So I think that the putting the hold on when they can get an additional block doesn’t really change anything because they can just come back as a new company. But putting the hold on how long they have to hold the resource before they can transfer it away significantly increases the ability to profit quickly from this.

Tim Denton: Thank you. Mr. Schiller.

Jason Schiller: Jason Schiller, Google. Just to further that point in terms of how long that hold has to be before they transfer the resource, it has to be longer than the current futures market. So that hold could end up being a very long time period.

Tim Denton: Thank you. Mr. Kaufman.

Matthew Kaufman: The hold is subject to a different type of biased gaming, which is that organizations which have enough space now to run a FIFO policy, where they transfer out addresses that have been held long enough and replenished those by taking in new addresses, are at an advantage over organizations that don’t hold enough to fill the FIFO deep enough. So you’re just changing who makes the money, not whether or not it will be made.

Heather Schiller: I’m sorry, can you explain what FIFO is?

Matthew Kaufman: First in, First Out. So if I have two years’ worth of addresses that I’ve been accumulating over time, I can just shuffle in one end and out the other.

As I say, someone will make money doing this. All you’re doing in this meeting is deciding who makes the most and who makes the least. But people will make money doing this.

Tim Denton: Thank you.

Heather Schiller: There’s the option of not doing this at all. So I can remember as an AC when we were initially looking at 2008- — it was originally 2008, wasn’t it, where we looked at all this stuff and all of these — we came up with the list of all these different restrictions that we could replace on how transfers could happen in region, and we’re basically having that same discussion again talking about between regions.

So I find that interesting, and we might want to kind of think about why we sort of chose to go with a much simpler text. It seems like we’re trying to bring all that control back in again.

But the reason I got, I stood up, the thing I wanted to say was about something Dave Farmer said about the large sucking sound — I think it was Dave Farmer — who said something about limiting the — maybe it was Kevin — the overall amount of address space — limiting the overall amount of address space that gets sucked out of the region and — or sucked into the region later on.

So no one’s touched on that, and I was wanting to hear more information from the community what they thought could be done or if that should be done.

Tim Denton: We have one proposition on the table, and I’d like to — in a sense, so we can discuss other would-be policies, I just want to make sure that our discussion sticks to the text or the principle behind the current text.

I see Scott Leibrand. I don’t know if Kevin or Martin came up first. Martin and then you. So Scott.

Scott Leibrand: This is moving rather quickly, and so I’m not going to attempt to suggest which particular things are useful and which are not. But there are at least two sets of conditions that I believe might apply at least in part.

One is from ARIN Prop 151, which we had a lunch table topic on today. That’s a proposal from Matthew Kaufman on basically rewriting the transfer policy. It has a couple conditions that would be useful on the existing transfer policy if we wanted to adapt it to make inter-RIR transfers not as subject to wash-rinse-repeat.

Matthew Kaufman: That wasn’t from me. I don’t say —

Scott Leibrand: Okay. Whoever proposed 151. That’s what’s in there. And there’s also some conditions in 2008-2 which was the original transfer policy that Heather referred to that are also relevant.

So I would encourage people to pull out your web browser and look at those and determine whether you think any of those are useful.

Tim Denton: Okay. Mr. Hannigan.

Martin Hannigan: I have a question for probably the eighth speaker ago, but I guess we can direct this at Heather, if you want to at all, Mr. Chairman.

But you had started out your comment with why would we do anything, I think, or something to that — something equivalent just as a — kind of an offside remark.

Maybe we shouldn’t do anything at all and maybe we should just document the transfers instead and let it sort itself out. Why wouldn’t we do that?

Tim Denton: Would you care to respond, Heather?

Heather Schiller: My comment was more that we have the option of not permitting inter-regional transfers at all. It wasn’t that we — not the option of just letting it go this way and not changing what the text is. It was about not doing this at all.

Martin Hannigan: I think it’s clear that people do want to permit the transfers. We’re hung up with the control functions, with deciding who is going to make money, who is not going to make money, and perhaps we’re even trying to decide how much money they’re going to make, when it sounds like a simplification of the process to at least get this going or at least get out of our own way and let some things happen would be to just instead document the transfers and let them have at it.

Tim Denton: Just a second. I think we’ve got a quite clear proposal on the table. And I would like discussion to focus on that proposal, whether you’re in favor of it, whether you’re against it in principle, or whether you favor it with wording amendments.

This discussion is not going in a place that is useful for the Advisory Council to take your advice. So are you for it in principle, are you against it in principle, or are you for it with amendments?

I’d like discussion to be somewhat focused along this line.

Kevin Blumberg: Kevin Blumberg, The Wire. I just actually would like a clarification on one thing. In an 8.3 transfer, which this would be based on, the transferor cannot go back to ARIN for how long for new space?

Bill Darte: There’s no specification at this time. It’s been suggested there should be.

Kevin Blumberg: Okay. So I would suggest that that would be a good amendment to this as well. Thank you.

Tim Denton: Thank you. I think I’ll do Chris and then back to you, Matthew.

Chris Grundemann: Chris Grundemann. I heard some things that started to sound like taking resources out of our region.

Tim Denton: Are you for it in principle, against it in principle, or favor it with amendments first?

Chris Grundemann: I’m in favor of this in principle. And the reason I’m in favor of it in principle is because we are talking about a global communications medium that we call the Internet.

And it is only successful because it is a global communications medium. If you talk about resources staying in our region or leaving our region, it’s completely irrelevant to the operation of the Internet.

Tim Denton: Thank you. Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I will say plus one to what Chris just said, and only add the ARIN region has approximately — with all the legacy address space and all the things, approximately twice the address space of any of the other RIRs, and it is just under half of all of the allocated /8s equivalents.

So we’re fat and happy. This is coming from somebody who is not small. So we are fat and happy. We need to share. Let’s get over it.

We decided we didn’t like all the rules and we needed a simple piece of language —

Tim Denton: David, are you in favor of it in principle?

David Farmer: I am in favor of it in principle.

Tim Denton: Thank you. Do you have anything further to say?

David Farmer: Yeah. Let’s keep it simple.

Tim Denton: Matthew Kaufman.

Matthew Kaufman: I continue to be in favor of it in principle. And just two quick comments, which is that imposing — not doing this at all simply causes the transfers to be done in a different way by creating lots of shell corporations here, and doing it with a limit on the total number simply means that the people who are first make the money.

Tim Denton: I think I’m going to close the mics. And our shepherd will have one final comment. And I’m going to warn you that I’m going to reverse the normal order of questioning.

I’m going to have it: Are you in favor in principle of interregional transfers or against, and then we will deal with the specifics of this proposal. So…

Bill Darte: I think it’s not constructive to talk about regional transfers. It’s about whether people free up resources and have the flexibility to specify where those resources go. That’s what this policy is really about.

It’s not about who — you know, which region wins or loses. It’s about whether people have the opportunity to free up resources and specify where they go as an augmentation to 8.3 as it’s written now.

Tim Denton: Okay. So then we’ve got our counters up?

The first vote I’m going to ask you to take is whether you favor inter-regional transfers in principle. And that’s the question. Would you raise your hands, those in favor. Thank you.

Those against interregional transfers in principle.

No surprise as to the question are you in favor in principle to interregional transfers, 124 people in the room and remotely have voted; 53 were in favor and 1 was against.

Now, the next question will be slightly different again. The next question I’m going to ask is: Do you agree to this proposal, first of all, as written on condition that it receive some language tweaks that were proposed in this discussion.

So, in other words, will you accept interregional transfers as proposed in the policy with the Advisory Council being instructed to accept some sensible tweaks to its language. For clarity. I don’t wish to overspecify the solution.

Vint Cerf: Would you specify what the alternative is going to be?

Tim Denton: The alternative is going to be that they do not accept the proposal as written, even if modified by the discussion we have currently engaged in.

Vint Cerf: So the question I guess I’m raising is: If you voted no — if you said “I don’t accept even with tweaks” — does that mean the proposition dies and we have to start all over again with another proposal, or can the proposition continue to work?

Tim Denton: I’m very concerned to make sure that the Advisory Council receive instructions from this house to continue to work on it to perfect it or make it reasonably tolerable.

Vint Cerf: The reason I’m raising this as an issue, Mr. Chairman, is I’m concerned that the only way that the Advisory Council could continue to work on it is if we all voted to — in favor of this with some tweaks, because the value of tweak is a little undefined. That’s what I’m concerned about.

Tim Denton: Yes, I understand the value of tweaks is less than perfectly defined. And we may have to confer to get a third vote as to define further.

But I just want to get a sense of the room that the room favors or does not favor this proposal going ahead with some language tweaks.

Owen DeLong: Mr. Chairman, if I may?

Tim Denton: Mr. DeLong.

Owen DeLong: Owen DeLong, ARIN Advisory Council. This question I don’t think provides particularly useful input to the AC, and the Chair is here leaning in my ear telling me the same thing.

I would like to suggest that we instead ask the question: Does the community support the Advisory Council making minor changes and moving this to last call versus the alternative being that the community supports the Advisory Council continuing to work on this and bringing it back to another meeting.

Tim Denton: Thank you, Mr. DeLong, for that language. Can you repeat that language for me again?

Owen DeLong: Sure.

Does the community support the Advisory Council correcting this and moving it to last call versus does the community feel that it needs major changes and another trip to a meeting.

Tim Denton: Okay. So we have heard the language from Mr. DeLong. Do we favor it, moving it to last call with tweaks.

The proposition is now going to be put to the house. Do we favor it being put to last call with the Advisory Council making language tweaks. Please signify your ascent if you agree. You can put your hands down.

Those against the Advisory Council putting the proposition to last call even with tweaks. Those against the Advisory Council putting this to last call.

Leif Sawyer: A question of clarification. Based on what Owen had said, I thought we were going to be voting on whether or not this got kicked back for complete rework, not voting against it going back with tweaks. They’re different somehow.

Bill Darte: If it were to go to last call, then it would be in another cycle of work.

Leif Sawyer: That’s not necessarily true.

Tim Denton: Just a second. Can we just have — no. I don’t want anything further. We’re reaching the stages of lack of clarity.

Now, is the vote — has the vote been taken? All right.

2011-1: ARIN Inter-regional Transfers. Those in the room voting and by remote, 124. Those who are moving it to last call and making such corrections as may be necessary, those in favor of the proposition were 24; those against were 17.

John Curran: Thank you. That information will be provided to the Advisory Council for their consideration.

We are now within four minutes of break, and in order to be efficient I am going to actually do the staff introduction to the last policy of the day at this time, and then when we come back from break we will have the AC presentation for the last policy of the day.

ARIN-2011-9 (GLOBAL PROPOSAL): GLOBAL POLICY FOR POST EXHAUSTION IPV4 ALLOCATION MECHANISMS BY THE IANA

John Curran: Draft Policy 2011-9 (Global Proposal): Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA.

This originated as ARIN Proposition 137 on March 2011. AC shepherds, David Farmer and Chris Grundemann. AC selected it as a draft policy in August 2011. The revised/current version is the 22nd of September, 2011. The text and the assessment online — text and assessment are online and in your Discussion Guide.

Summary. The IANA issued the last /8s in February 2011. There is no global policy for IANA to allocate address space to the RIRs that are smaller than a /8. The proposal tells IANA to set up a recovered address space pool, accept returns by any means, and allocate address space to the RIRs in equal amounts twice per year, minimum size of a /24.

Status at other RIRs of similar policy proposals. AFRINIC, it’s in last call; APNIC, adopted; LACNIC, adopted; RIPE NCC, last call.

Staff assessment. Issues or concerns: This proposal would fill a policy gap. It would allow the RIRs to return IPv4 address space in blocks smaller than – yeah, that’s right. It will allow the RIRs to return IPv4 address blocks smaller than /8 to the IANA for equal redistribution among the RIRs.

Resource impact. Minimal. This is predominantly guidance on how IANA does its job.

Legal assessment. No significant legal risks and is a useful advancement.

PPML. 17 posts by 10 people; 3 in favor and 1 against.

“Also significant to this discussion, APNIC has reached consensus and is in last call on a policy restoring needs basis to their transfers. Assuming that this policy is fully ratified, I support 2011-9.”

“I read this as yet another attempt to funnel resources out of ARIN to other regions. IANA is depleted. They’re no longer part of the picture. When can we stop trying to give resources back to them?”

So we will break at this point and we’ll have the AC presentation on the proposal when we get back. We are going to resume promptly at 4:00 with ARIN 2011-9. I look forward to seeing everyone here in 30 minutes.

[Break taken at 3:28 p.m.]

John Curran: It is now 4:00. If everyone will come in and settle down, we’ll resume our afternoon program with policy development.

I’ve just completed giving the staff introduction to 2011-9: Global Policy Proposal for Post Exhaustion IPv4 Assignments. I’ll now ask Dave Farmer to come up to give the AC presentation.

David Farmer: Quick introduction to remind you all what John told you before. This is a process creating a process for IANA to allocate IPv4 resources to the other regions from a central pool now that it’s exhausted.

Problem statement: IANA is exhausted, but I’m told there are bits and pieces left. Not a lot. Handful of /24, maybe two handfuls, I was told.

Also, there’s a possibility that IPv4 addresses will be returned to IANA. The other RIRs can do it — it’s possible for us to do it.

It’s conceivable that some of the legacy holders would return them straight to IANA. There currently is no policy for what — to tell IANA what to do with these addresses.

So this is our third try at one of these policies. 2009-3 did not get approved with common text in all three RIRs. We, ARIN, changed the required returns to voluntary returns and none of the RIRs adopted that language.

2010-10, which was another try, was abandoned or withdrawn at the other RIRs. And so that leaves us with this one.

As was talked about, it’s been approved in two RIRs and it’s actually completed last call in the other two but hasn’t moved its next step just yet. They’re still chewing on it, processing it and deciding what came out of last call.

The details of the proposal will create a recovered IPv4 pool. This will contain any fragments that IANA has sitting around and anything returned to IANA excludes any special use addresses.

The recovered IPv4 pool stays inactive until the first RIR has at least — has dropped below a /9.

Once the pool is activated, each RIR will receive one-fifth of the recovered pool rounded to the nearest CIDR. This will repeat every six months if more come in, whatever.

Smallest allocation to an RIR will be a /24. Reporting: IANA may do public announcements, but they will — they have to put this stuff on the website and they’re required to make their announcements on their internal lists and the appropriate other lists.

IANA’s going to announce which addresses they assign to where essentially. RIPE requested a summary of — an IANA staff impact analysis. I’ve got two slides here that summarize that. One of the issues that came up in that was it wasn’t clear from IANA’s point of view whether this was intended to supersede the IETF’s right to make special assignments in the future.

It wasn’t clear that it was supposed to either. So they wanted clarity on that issue. They noted that this will replace the current procedure for updating legacy Class A allocations. And they also noted that the allocations will not necessarily be made from a single block but probably made up of multiple individual, separate blocks and will most definitely inflate the size of the IANA IPv4 registry that’s on the website.

There’s details from the RIPE website of the actual whole email because I didn’t want to just copy the whole email because it would have been five or six slides.

Implementation guidance was added to the rationale to clarify this, stating that the NRO must clarify this global policy is not intended to supersede the IETF’s right to make the special assignments as documented in the RFC, and that the NRO and IANA should coordinate with the IETF to make such assignments as necessary and honor the reservations made for works currently in progress.

Other relevant information is APNIC is — whoops — is restoring — I thought I fixed this — oh, well — is restoring needs basis to its transfer policy. This eliminates one of the major objections that’s been raised to the whole concept of returning addresses to IANA and having them be pushed out.

Advantages: This removes two areas from the previous policies that failed to reach consensus. One was our issue of it doesn’t define how — what addresses are returned. Leaves that to be a local issue.

And then in our version we had tied some stuff in to transfers and how they should or shouldn’t take place, and that had major objections in other regions.

Disadvantages: It doesn’t provide any details about how the address space is going to be — where the address space for the recovered pool comes from. But, guess what, that’s what we told them we wanted. So they gave us what we wanted.

So questions and discussion?

John Curran: Microphones are open. Our Chairman is unavailable, so I’ll be chairing this discussion.

Center rear mic first.

Sean Kennedy: Sean Kennedy, XO Communications. I don’t propose any changes to the language, but I will note that we just spent most of our afternoon discussing use of ARIN IPs in other regions and there were proposals that it was necessary to transfer IPs to other registries because of the way the last — in part because of the way the last few /8s were handed out without being on the basis of need, one to each registry.

So it might be worth having a discussion of whether the Board of Trustees, upon receiving the allocation, do a vote on whether ARIN needs the block at that time, and, if not, return it using the return proposal to the space to be considered at the next six-month interval.

John Curran: To be clear, and I’ll answer on behalf of staff, if this policy is adopted, then the return of any particular block to the IANA would be something that the staff would do based on the guidance of the Board of Trustees.

So while not a precise process, as you outline, we do have space that we currently have in the pool that’s returned space. One of them is notably 254 of 256ths worth of a /8.

And I would bring to the Board the fact that we now have a policy that allows that not to be stranded for the Board to consider. But I don’t know how the Board would evaluate each for return.

So end of the table here, Martin.

Martin Hannigan: No surprise. I’m not in favor of this proposal. First of all, 2010-10, as David referenced, had overwhelming consensus in our region. And this proposal basically stripped out all of the things that we thought that we had needed to put forward and into the other regions.

I wouldn’t feel so bad about that, except that some of us did go around to all the other regions, and personally I don’t feel that we got a fair shake with regard to our ability to actually present the policies.

There were political maneuvers and whatnot and unhappy people. And that’s the way it works. That’s fine. There’s no reason to cry over spilled milk, but we lost a significant amount of what we thought was fair and what we wanted in order to establish a fair process to return addresses to the IANA.

The second thing is I think Section A is a red herring. The IANA should dispose of fragments, regardless, which I believe they already have. The example there would be various registries.

And I note I actually saw a message, I believe — and, Leo, please correct me if I’m wrong — that Leo asked for guidance on this issue either on the PPML or NANOG and said what should I do with these fragments that are in the registry, and I believe that there were minuscule, or there was a really small amount of them, so I don’t really think there’s a lot of damage not to require some additional work on this proposal.

Third, Section B in the allocation method is fairly disparate. Why would we give any addresses to RIRs that have addresses like LACNIC and AFRINIC if the intent is to fairly distribute addresses that are at the IANA on a needs basis? That doesn’t make sense to me.

The fourth point is, you know, this doesn’t force us to return any address space, but putting this in place without any kind of clear direction from the community to the Board and the staff pretty much opens the door to unilateral action.

Not that I believe that would ever happen, but I do think that 45, the status of 45 /8, the Interop block, is still up for question and we could see that go back.

I’m glad that John mentioned that it would be a discussion between the staff and the Board, and I hope that the intent in the community would be considered as well.

Again, I think that we lost a lot of what we had asked for previously. We had overwhelming consensus, and I think this doesn’t even take us a step closer to any kind of agreement.

John Curran: Thank you. He directly referenced Leo, your reference email. Do you want to respond?

Leo Vegoda: Yes, just responding to Marty. I counted what we’ve got. I think it’s 27 /24s that are waiting for something to happen or nothing to happen. Because it’s only — there’s only 27 /24s. So I don’t think it’s going to make a great deal of difference in the big scheme of things.

Martin Hannigan: To contrast that to the various registries comment I made, I believe that was 768 by 5, the distribution.

So, you’re right, a couple of /24s as compared to that one. That underscores my comment with respect to I don’t really believe that a policy is needed to clear out the current fragments in the registry.

John Curran: Far left mic.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council. I think that this policy actually does contain most of what we asked for in 2010-10.

I think the policy is reasonably clear, reasonably well written. And whether the 27 /24s that are currently stuck in IANA with no way to get out being distributed such that each RIR gets, what is it, five /24s out of that deal, we narrow it down to two /24s being left, I think that the optics on that are at least good even if it doesn’t actually matter in the grand scheme of things.

We’ve spent a lot of time talking about IPv4 policy. The reality is that IPv4 policy at this point is rearranging deck chairs. So if we’re going to focus on rearranging deck chairs, which we seem to be determined to do, I think this is a good way to rearrange the deck chairs and we should just get on with it.

John Curran: Scott Leibrand.

Scott Leibrand: I believe this is important politically in the global political context, in the context of all the Internet governance stuff, that we go ahead and demonstrate that we’re in solidarity with all the other regional Internet registries, adopt this and move on.

I think the thing we need to be moving on to is, okay, we’ve got a process in place at the IANA to do something with address space they get.

I would like to encourage people at the member’s meeting, or whenever it’s appropriate, to provide feedback to the Board as to what they think they should do. But it’s going to be a Board decision. And I’m fine with that.

So I believe — I agree with Owen that this policy proposal is pretty much what we wanted in terms of not forcing the ARIN region to do anything in particular and making sure that stuff doesn’t get stuck at the IANA.

And I believe those are the only two important things. So I support this as written and would encourage everyone else to do so, so we can get on with more important stuff.

John Curran: Okay. Further comments on this? Microphones are open. I’ll be closing the microphones shortly.

Jason Schiller: Jason Schiller, Google, NRO NC. I have two questions, one for Marty and one for Scott.

Scott, my question for you is: If this policy were to pass today, would you feel comfortable recommending that the Interop space be returned to the IANA under this policy?

Scott Leibrand: I can only have a personal opinion on that because I have no role in the process of determining that other than to express that opinion now.

And my opinion on that is I would be fine with most of 45 /8 going back to IANA and being distributed to the other RIRs, simply because of all the reasons we’ve been talking about today and yesterday; we’ve got too much of a disparity in space between regions.

I don’t think that would be an ideal way to reduce that disparity, but it would be less of a disparity after that were done than there is now.

So I think it’s better to get at least a little bit more space to where they’ve got a shortage than we have now. So I’m fine with that. But I’m also fine if the community says no, no, no, don’t do, that the Board would say, no, we don’t want to do that.

Either way, I think that’s an independent question from whether we should have this process in place for the IANA to do something if someone chooses to give them space.

I think we absolutely need to do that.

Jason Schiller: Thank you, Scott. Martin, my question for you is you said there were a number of provisions in 2010-10, I guess it was, that have been stripped away and are not in this proposal.

And I think it was Owen came to the mic and suggested that a lot of the things we asked for previously were in this proposal.

Can you run down a list of some of the things that are missing that you think this community needs?

Martin Hannigan: I could. But even though 2010-10 was — basically it is a policy as far as at least the PDP seems to relate, it’s not in the — it’s not in the guide book.

And I have a slight problem with my computer or I would have went and found a way to go ahead and print that myself before the meeting. So I would need a little bit more time to do that.

But just one other comment. You know, this isn’t about five /24s for each region. This is about — this is an attempt to divide and conquer the issue, get the IANA return mechanism in place, which I don’t disagree is reasonable.

But, again, I called Section A a red herring and I said Section B, and I focused on needs which we seem to focus on a lot, and seems to be a reasonable focus, which was for all intents and purposes way out of whack.

John Curran: Jason, based on the answers you’ve heard, are you in favor or opposed to the policy?

Jason Schiller: Jason Schiller. At this point I think I’d like to hear more about the concerns that the community had in the past about past attempts about this and whether those concerns are still valid or are no longer valid.

John Curran: As written, would you be in favor of it as written, with what you know now, or would you be against it?

Jason Schiller: I’m trying very hard not to put words in the community’s mouth. The concerns that I heard previously were significant. And if those concerns — if the community still has those concerns, I would be opposed to it.

However, if the community does not have those concerns, I would support it. I am happy to enumerate the concerns as I heard them, but I don’t want to lead the community in this discussion.

John Curran: Rear microphone.

Cathy Aronson: Cathy Aronson, ARIN AC. I think that it’s really important that there’s a policy at the IANA that allows blocks not to be stranded there regardless if any ever get returned.

I think there was a misconception, at least when I was in another region recently, that if a /8 was returned to the IANA, that there was a policy, because the IANA hands out /8s, but really, in essence, since the end game happened, there is no policy even if they get back a /8, it’s just going to sit there because there’s no — so I think that it’s really important and responsible of us to have a policy under which address space doesn’t get stuck there.

And I’m with Jason. I would really like to hear what people think about whether we should return, because, historically, if we got a /8, we returned it.

That’s what we’ve always done. And I’m sort of in favor of that. And I’m also in favor, because I know you’re going to pin me down, of this.

John Curran: Good thing. Saved me words. Thank you.

Far left mic.

Owen DeLong: Owen DeLong, ARIN AC, Hurricane Electric. I just reread Section B based on Marty’s comments, and it’s actually a little bit ambiguous, because it doesn’t activate the policy until there’s need, and then it turns the policy allocation unit into 1 out of 5, but it doesn’t say every RIR gets 1 out of the 5. It says every RIR gets no more than 1 out of 5.

So presumably there’s some implication there that only the RIRs that have need get their one-fifth of the space at that time. But it’s not completely clear, at least to me, in the policy whether that’s the case or whether once one RIR has need, every RIR starts getting pieces.

John Curran: Given the ambiguity, you spoke in favor of the policy in the past, are you still in favor?

Owen Delong: I still support the policy, because it’s better than what exists now. But I would encourage getting at least clarification from IANA on how it would get implemented.

John Curran: Marty, you said you wanted to respond.

Martin Hannigan: That was an interesting point, Owen, and I appreciate that. And I would just add, not only is that ambiguous, but there’s also a phrase in the policy in Section B that says “addresses returned by any other means,” which that’s fairly ambiguous as well and open to interpretation.

And when you define — also in regards to another ambiguity, there’s a reference to the RIR having less than a /9, if I — hold on. Let me pin it for you.

With regards to what triggers the actual execution of an assignment for the pool, it doesn’t actually specify what pool they’re talking about, because in our last discussions we learned — just like we learned about various registries, we learned that RIRs have multiple pools. And with regard to the way that IANA does their needs analysis, some of those pools aren’t counted, like things that are reserved and whatnot, it’s not clear if those pools are counted.

Vint Cerf: It’s Vint Cerf again at Google. I actually think we’re trying to over-engineer the end game here. We are in a sense blocking what is needed, which is to give some flexibility to IANA to deal with any address space that does happen to be returned to it.

There’s nothing in this policy that forces any of those returns. My recommendation is to pass this policy as written on the grounds that if we don’t do it, we will be accused of blocking and mishandling the end game.

We don’t need that. Right now we need to focus on getting IPv6 out there.

John Curran: Far left microphone, Scott.

Chris Grundemann: Chris Grundemann.

John Curran: Sorry, Chris.

Chris Grundemann: At this point, plus one to what Vint said. We’ve been dealing with this for three years. This is a very, very simple policy at this point. It gives IANA the mechanisms they need. Let’s give it to them.

John Curran: Closing the microphones shortly. Approach the mics if you’re getting in line.

Jason Schiller: Jason Schiller, Google. Definitely plus one for what Vint and Chris Grundemann said.

But I also want to make sure that if we do pass a global policy for IANA to distribute resources, that it’s one that we can comfortably get behind and return space.

I don’t want it to be an empty policy that this community is not comfortable recommending the return of space.

In answer to a previous question, for clarity, Section B, subsection C, an IPv4 allocation — I’m sorry, Section B — Section B, “in each IPv4 allocation period each RIR will receive a single IPv4 allocation unit from the IANA.”

And then further on: “No RIR may get more than this calculation used to determine the IPv4 allocation unit even when they can justify a need for it.”

So I believe it’s very clearly written in this policy that each RIR gets exactly one unit and all five get the same size.

John Curran: Thank you. We’re closing the microphones.

Marty, you wanted to respond and far left mic.

Martin Hannigan: Just so it’s clear, I’m also plus one with Vint and I’m also plus one with Jason. I would like to get behind a policy that we put forward.

But I thought we were trying to address this through transfers. I mean, we should pick one. Is it going to be transfers or returning to the IANA? And if it’s going to be returning to the IANA, forget the transfers, give it back to the IANA, because it will be cheaper for all the users that actually do need address space, but do it in a way that we can live with.

John Curran: Okay. Microphones are closed unless someone needs to — I didn’t hear him reference anyone’s comments, so I’d prefer that we keep the mics closed as is. You can respond.

David Farmer: We need to do both. I’ve been saying this for a long time. There are organizations that cannot and will not transfer addresses, and they may have unused addresses. We don’t want them trapped there either.

I represent an organization that probably would never transfer because the liabilities and tax implications and the implications that we got them from the federal government could jeopardize way more money than you would ever pay for them.

John Curran: Final comment, far left microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I do support this proposal. I have two comments. The first is that my only concern is that this is a leapfrog to forced reclamation later on.

That is my only concern, and I want to make that very clear. That’s my first comment.

My second comment is with the inter-RIR, I don’t know anyone who will actually use this policy to return, especially if they can monetize and donate it to charity, why return it to IANA for nothing.

John Curran: Given those two facts, though, you’re still in support?

Kevin Blumberg: I still support it, yes.

John Curran: Our final comment is a remote comment. Go ahead, Scott.

Scott Leibrand: Joshua Sahala, Infocrossing. He says: 2011-1 creates an avenue into IPv4 address sale on an inter-RIR basis. This proposal would have little or no teeth given there’s no financial incentive for address holders to return space to ARIN to then return to the IANA when they can sell them via inter-RIR transfer. He agrees politically this sounds good and should probably move forward to avoid stranding address blocks.

John Curran: Thank you. At this time we’re going to put the question to the body and a show of support.

I’m going to ask everyone in favor of advancing this policy proposal and everyone opposed. So on the matter of policy proposal, Draft Policy 2011-9, Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA, if you’re in favor, raise your hand now. Raise them nice and high. Nice and high. Thank you. We have that.

Everyone opposed raise your hand now. Nice and high. Thank you.

We’re tabulating now. Thank you for your presentation.

On the matter of Draft Policy 2011-9, Global Policy for Post Exhaustion IPv4 Allocation by the IANA, total number of people in the meeting room and remote, 119. Number in favor, 47; number against, 2. This information will be provided to the ARIN Advisory Council for their consideration.

Okay. That concludes our policy portion of the meeting. We’re now going to move on to a few reports. We have some today and some tomorrow. I’m going to give the Policy Development Proposal update. And that’s actually very quick.

PDP UPDATE

John Curran: People may or may not notice that we extensively use the Policy Development Process when we do all this. What the AC does, what we can do with it, is all based on our PDP.

There is a new proposed Policy Development Process. It is out for consultation. You can find it on the ARIN website under Suggestions, if you go to the top, you can find it on the ARIN Consult Mailing List.

Comments are welcome on this proposed PDP. A group of Board members and a couple of AC members and a couple of members chosen at large got together and made suggestions, and we’ve integrated those all in, but we need community feedback.

So please take a moment and look at the draft PDP. We’ve extensively rewritten it to hopefully be clearer on what the process is that we use. So we look forward to receiving your comments.

At this point I’d like to invite Leslie up to give the Policy Experience and Implementation Report. This is where we talk about various policies and the staff experience that we’ve had implementing them and whether or not they might be topics for future policy development work.

IMPLEMENTATION REPORT

Leslie Nobile: Good afternoon, everyone. I will go quickly on this one. So I’m starting with Policy Implementation Report.

Basically this is where — John just basically said what I would say, but I’ll repeat it anyway. We update the community on recently implemented policies, and we’ll provide some relevant operational details if there are any.

Since the last ARIN meeting, we implemented 2011-6, Returned IPv4 Addresses. And it says that any IPv4 address space that comes back to ARIN, whether it be returned, recovered, or revoked, has to be retained for timely redistribution to ARIN’s customers until a global policy is adopted that allows for the return of this space to IANA.

So this basically opens up the floor to allow space that is less than a /8 that ARIN has gotten returned to it to be returned to the IANA.

Let’s see. Actually we did move the Interop space into the available pool per this policy just recently.

Reserved Pool for Critical Infrastructure, 2011-4. This one reserves a /16 equivalent for issuing under the IPv4 micro-allocations for critical infrastructure policy, NRPM 4.4. It says if any of the reserved addresses aren’t used after 36 months we can use it for other purposes.

And we’ve always held space for micro-allocations, but this just makes it clear in policy that it will be a minimum of a /16. And with v4 depletion, if it’s not used after 36 months, it could be used back in the available pool for customers.

Better IPv6 Allocation for ISPs, 2011-3. This is the one we just recently partially implemented. At this point we can issue up to a /24 to a customer. And we’re awaiting the implementation of the rest of the policy which would allow us to issue /20s and larger. We expect that by the 15th of February.

This one allows ISPs to have uniform subnets and it defines something called the Serving Site. It says each one gets a block large enough to number its largest Serving Site. And we’ll be issuing on nibble boundaries, /32s, /28s, /24s, et cetera.

Standardized IP Reassignment Registration Requirements, 2010-14. This has lots of bits and pieces, so bear with me. This one applies to all ISPs who issue from dynamic address pools to residential customers.

There used to be a cable policy for cable ISPs only, and this has been expanded to include all dynamic address pools, to ISPs assigning to dynamic address pools for their residential customers.

It requires enhanced reporting for v6 assignments. It says that all /64s and larger static assignments have to be registered in Whois. They have to be SWIPed or RWhois. It allows a resource review when ARIN believes an organization is not in compliance with reassignment policy. And it better defines residential customer.

It was kind of vague before. And it now excludes a business working from a home, which makes it very clear that it’s not — that would not be considered a residential customer. And it requires an abuse contact for all organizations.

So we recently did this. We sent out email to all ORGs and said please add an abuse contact per this policy. And if you don’t, we’re going to add one for you. Basically we’re going to promote your existing ORG Tech POC to the Abuse POC. And if there’s no POC at all, we’re going to put a placeholder record in.

We have done that for all of our records, and we’re in the process now of informing all POCs who are now abuse contacts that they are the abuse contact.

We’re sort of staggering it. We’re not doing it all at once. There are about 45,000 of them or something. So we’re running a little bit slowly with that.

So let’s see. So operational feedback on other policies that were implemented previously. I just have one. I just wanted to show this graph. NRPM 4.2.4.4, Subscriber Members After One Year. It says that once ARIN gets its last /8 from IANA, an ISP can only request up to a three-month supply instead of the 12-month supply that they were previously able to request.

I put the chart up from 2010 and 2011 to show you the drop in February once this policy was implemented and ARIN did get its last /8. You can see the real drop-off in allocations, in IPv4 allocations. We’ve had a couple of blips up when a few large ISPs have come in. But, in general, we’ve seen our allocation rate go way down.

And just in case you’re wondering, the light blue is the assignments and the dark blue is the allocations. And that’s all I have on that part of it.

Any questions?

John Curran: Any questions?

Kevin Blumberg: Just one question. You mentioned in 2011-4 that it was 36 months after implementation.

Leslie Nobile: Right.

Kevin Blumberg: Not after run out?

Leslie Nobile: No, it was after implementation.

Kevin Blumberg: I’ll talk about it later then.

John Curran: Microphones remain open.

Any other questions for Leslie? Yes. At the end.

Martin Hannigan: Martin Hannigan, Akamai Technologies. Can you explain why such a huge difference? I would think that, in assignments and allocations, because I would think just because we reduced the window of need to three months that we would still have at least somewhat of the same volume? No?

Leslie Nobile: No. We don’t have the same volume. Requests continue to come in, but we’re issuing less space due to the — it’s been cut into a quarter. So you’re getting three months instead of 12. So we’re issuing far fewer /24s than we were. But the request rate is pretty similar. Does that answer your question? I’m not sure.

Scott Leibrand: This is Scott. I believe the math works out that you should get one-quarter of the amount of space requested previously in the first quarter, one-half in the second quarter, three-quarters — it should ramp up to the full amount. Because there’s going to be a bunch of people, based on their timing who are now coming back every quarter, and then at the end of that full year everybody’s coming back every quarter.

And if they’re requesting the same amount of space as before, over time it should even out. So that would be ignoring any effects of people requesting less space because of whatever, they didn’t really need it or it’s harder now or whatever.

John Curran: You would expect to see the rate of requests pick up over time based on the fact that prior people received much shorter allocations and are now coming back.

Leslie Nobile: I can add one thing to that. Over the past several years, I looked at the allocation rates. Our allocation rates in the ARIN region have gone down.

I mean, we were issuing over three /8s several years ago. We issued a little over two and a half last year. The year before just a little over two. So our allocation rates in our region have gone down over the years, and that’s — this is not just due to the three-month allocation rate. It could be market saturation.

There’s just a lot of reasons. But we’re not seeing the largest ISPs come in on a regular basis. That’s the reality.

John Curran: Okay. Any other questions for Leslie? Okay. Thank you, Leslie.

[Applause]

John Curran: You have Policy Experience Report.

POLICY EXPERIENCE REPORT

Leslie Nobile: I’m staying. Almost kicked me out, but he didn’t.

Policy Experience Report. So this is the Policy Experience Report, the second half of this. So the purpose of this is to review existing policies, the ones we’re working with presently, for ambiguous text — things like ambiguous text, inconsistencies in the policy, gaps, and the effectiveness of the policies: Are they working according to their original intent? Are they working properly? Are they working for the community?

So we identify areas where new or modified policy may be needed. And we base this on our operational experience.

We work with customers day in and day out and we hear it all. And our customer feedback. And we’ll provide feedback to the community and make recommendations when appropriate to see if there’s something needed within some of the existing policies.

So we reviewed just two policies this time. The first one is Additional Assignments for Small Multi-Homers, NRPM 4.3.6.2. And we reviewed Multiple Discrete Networks, NRPM 4.5. That one you may have seen quite a bit of traffic on the PPML list.

So the first one — I actually have to read the text. Bear with me. Sorry. I always have to do this.

“Any end user that possesses an assignment smaller than /22 under any part of Section 4.3 shall not be able to get an additional assignment unless they agree to return all existing 4.3 assignments which are /23 or smaller within 12 months of receiving a new assignment.

“The new assignment shall be sized to accommodate their existing utilization in addition to their justified additional growth space under Section 4.3.6.1. The common cases for this are expected to be a /24 returned after receipt of a /23 or a /23 returned after a receipt of a /22.”

So this is the case of a policy, from what we’re seeing, may not be accomplishing its original intent and goal and purpose.

So I want to give a little bit of background and sort of lead you down the path so you can see where we’re coming from on this one.

The total number of Org IDs with at least one IPv4 end-user assignment in ARIN’s database since the beginning, from the beginning to right now, is 2,525. 89 percent of those end users have never come back for an additional assignment. 11 percent have come back for an additional assignment. So we see that end users don’t often come back.

So when we look at the total number of end-user assignments made since this policy was implemented just one year ago, there’s been 570 assignments made.

In the /24 and /23s, which is what this policy addresses, there’s been 297 total. /22s, there’s been 141. /21, 56 of them. And /20 and larger, 76. So more than half of all the assignments we’ve made in the past year have been under this policy, /23s and /24s. Out of that 297, only one has come back for an additional assignment.

So we haven’t seen any kind of activity in the additional assignment category.

So what we were looking at, what we’re thinking is only a small number of end-users actually come back for more space. Renumbering is difficult and expensive. We know that from working with our customers. We’ve been working with them on the multi-homed policy. There’s a renumbering requirement in the multi-homed policy. And we’ve been doing this for years, and it’s a struggle for our customers every single time they have to renumber and get new space.

And it’s difficult for us, because it puts the staff in a difficult position where someone says: I can’t renumber; I have this sudden growth; I don’t know what to do; I need space now; I didn’t renumber.

So here we are forced to decide whether we enforce this policy or potentially harm someone’s business.

So if aggregation is the goal and the policy doesn’t contribute anything significant toward this goal, is renumbering really necessary? And it seems to us that it forces a very small number of companies to suffer the pain and expense of renumbering with no obvious benefit to routing table conservation. And I believe that was the original intent of this policy.

So our suggestion was remove the renumbering requirement as it does not appear to meet the goals of this policy.

So that’s the first one. Do we keep moving and go to discussion after? So moving on to the next one.

NRPM 4.5, Multiple Discrete Networks. Okay. So the organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: regulatory restrictions for data transmission; geographic distance and diversity between networks; autonomous multi-homed discrete networks.

So the issues. Compelling criteria is vague. It’s open to interpretation. It’s not defined anywhere. It leaves it up to staff’s judgment completely. Discrete network is not defined anywhere within this policy. There’s some examples given, but they’re not all inclusive, presumably, and they are also wide open to interpretation. There’s been a recent argument made on PPML and to ARIN that route aggregation was the basis of the MDN policy and should be considered.

So we went back and looked at the original intention of the goal. We’ve known this from the beginning because we worked with the original author on this in 2002. It was very difficult for certain companies to get additional space. Basically it was to prevent networks that couldn’t actually readily reallocate space from being forced into opening up multiple ARIN accounts in order to obtain additional IP addresses.

So these people could never reach 80 percent overall utilization due to topological discreteness. They were opening up 10 and 20, and in some cases 40 and 50 different Org IDs with ARIN and paying for each one separately because they couldn’t get to the overall 80 percent utilization.

So the current practice right now as we see it, and from what we’ve been able to read from way back in the beginning and what we know is, we’ve defined discrete networks as sites that are not connected to each other or sites that are connected but customer traffic cannot pass from one site to another over an ISP’s internal network.

So customer packets are not allowed to transit their IGP. And we have some examples. And they’re pretty much consistent with the examples that are in the policy.

They lack a backbone. They have component networks operated autonomously. They have contractual or system limitations. Or they operate under regulatory constraints that prohibit interregional transit. That’s how we’ve applied this policy and that’s the only — those are the only conditions, literally, that we have used.

So I threw these approval stats in because someone asked on the list, it doesn’t tell you much, but it does show you that this policy is used successfully quite often.

The total number of v4 and v6 approvals that we’ve had in total are 872 IPv4 approvals and 1,134 IPv6 approvals.

Out of that, the total number of approvals under MDN have been 44 IPv4, or 5 percent of all approvals are MDN, under MDN, and 19 v6, or 2 percent of all v6 approvals, are under MDN.

We know as staff that this policy works well. We have never really had an issue with it. The people who haven’t qualified haven’t qualified because they were unable to meet the utilization rates, not because they couldn’t define what a discrete network was. It’s just never come up as an issue until this time recently.

So our questions: Should the MDN policy apply to a network that can aggregate but chooses to originate more specific routes for operational reasons?

And sort of a counter-question. If yes, then wouldn’t everything qualify as a discrete network?

We have some suggestions. One is modify the policy to add a clear definition of what a discrete network actually is, because that is nowhere in the policy.

And perhaps remove the phrase “must have compelling criteria.” That shouldn’t actually be needed if there’s a concrete definition of discrete network, and it takes that sort of staff interpretation out of it.

And that’s all I have with that. Are there questions?

John Curran: Okay. Microphones are open on the Staff Experience Report. We have a remote question? No?

Scott Leibrand: My question is with regard to the first one that you did, which I’m going back on mine, additional assignments for small multi-homers. You said that only one person has ever come back and renumbered and got a bigger block.

Have you had people come back that got /24s and /23s, asked for a bigger block, you tell them they have to renumber and they said, oh, never mind, and went away?

Leslie Nobile: I don’t think so. I don’t think we have yet. It’s funny — like I said, very few organizations come back. We’ve only had one that we can tell under this particular policy.

Scott Leibrand: So I’m wondering, if given the 89 percent that never came back under the old policy either, I’m wondering what the compelling need is to remove the renumbering requirement if we’re not denying anyone yet.

Leslie Nobile: Right. You know, we’re just looking at this. We know renumbering is difficult. We wondered is it actually achieving what it’s set out to achieve. It’s supposed to be route table conservation. If nobody’s coming back, why would you make five people suffer for something that doesn’t achieve the —

Scott Leibrand: Why should we have a rule that doesn’t block anybody from doing anything and doesn’t — yeah.

John Curran: The question that you’re asking, though, is do we have stats on the people who, when told there’s a renumbering requirement per the policy, get discouraged and go away?

A, we don’t generally — it’s hard to keep stats of people who don’t put in a request after they talk to us; but, B, people can see that in the policy and may be going away before they ever even approach us.

So it’s very hard to quantify. I do agree, we don’t know if there’s a problem here. We do know the policy is not getting used.

Kevin Blumberg: Kevin Blumberg. If you were to stretch this out over five years, would that number really change significantly or not at all in terms of the number people, the percentage of people?

Leslie Nobile: Coming back? You’re talking about the first policy, right?

Kevin Blumberg: The first. Exactly what Scott said. Because this is back just one year.

Leslie Nobile: No. The bottom one is back just one year. But, overall, in general, when you look at the top number, for all end-user assignments, over the past 13 years, only 11 percent have ever come back for an additional assignment. So we assume it’s going to be similar with this.

Kevin Blumberg: So my concern, to add to this, is actually once we reach run-out and end customers start using 8.3 and everybody is transferring /24s, should they be forced to renumber out of their /24 into an 8.3, /23 or /22? That doesn’t make sense either.

So would that — would this policy apply if they use 8.3? Because technically they got it under this policy.

John Curran: Presently, the way the transfer policy is written, it requires you to qualify under all the constraints of an assignment or allocation policy.

So, yes, this would carry under such circumstances. This is something that the AC in its ongoing work may want to look at, whether or not we want that one level of redirection back to the base allocation policy at all or whether we want to either clean up the allocation policy so it’s also transfer-friendly, or move those portions directly into the transfer policy, one or the other.

Center front.

Andrew Dul: Andrew Dul, multiple discrete networks guy. Can we go to the second-to-last slide where you had the question about what does or doesn’t qualify?

That one, yes. As the original author, I believe the intent was to create a policy that would allow organizations which didn’t have a backbone, weren’t allowed to transit traffic for regulatory reasons, chose to create multiple autonomous systems that were separate, those were the criteria that I remember and have been seen used over time.

The intent of the policy was never to apply to networks that chose not to aggregate, just because they didn’t want to.

So that was the intent of the policy and that’s how I’ve perceived that it should have been used over time.

This is a valid question, if people want to open the policy wider. But, from my perspective, I would probably say then everything is a multiple discrete network. That’s how I’d answer that question.

John Curran: Thank you. Microphones remain open. Anything else for Leslie on the Policy Experience Report? Closing the microphones. Microphones are closed.

[Applause]

OPEN POLICY HOUR

John Curran: We’re coming into slides. We have one slide good. Okay. This is the Open Policy Hour.

And during the Open Policy Hour we welcome new ideas for people who have suggestions for policy. And this is for people to discuss them sort of in an open fashion so that people of similar views can get together and do drafting.

We encourage people to sign up for Open Policy Hour so that we know time-wise, if we have 30 people, we can schedule accordingly.

We have had someone sign up who has slides. So we’re going to have an opportunity to hear from someone about a thought about policy, and then we’ll open it up for discussion of that or any other policy ideas people have.

So I think Richard Barnes, are you here somewhere? Come on up, Richard. If we can find his slides.

Richard Barnes: I came up with this idea a little too late to get on the ARIN agenda. So I ended up giving a technical background in the ARIN session yesterday, in the NANOG session yesterday. This will sound familiar to those who were here yesterday morning.

So just to review the situation here, we’re talking about geolocation and how this relates to IP addresses.

So the situation is there’s a bunch of apps out there that want information about where users are who are connected to the Internet, where IP addresses are being used. And there’s a bunch of different apps that want this, things like selecting which version of Google or Yahoo! to send them in German or French, Dutch, English even, ranging all the way from that to things like fraud mitigation for online commerce.

And the problem here is that these apps need the location information to do their job. And, you know, in principle networks could provide this information because operators own the physical infrastructure and they know how they’re doing addressing and where addresses are being assigned.

In principle, this information exists in the hands of operators, but there’s no real way to get this to the apps.

So the apps have gone about scavenging information from wherever they can. They scrape contact information out of the Whois database. They wardrive for Wi-Fi access points to see where they see which access points and they buy databases at cell towers from cellular operators. And there’s all this sort of scavenged, unreliable data around. So we arrive at a couple of problems.

So because this data is non-authoritative, it’s not actually bound into the real infrastructure, it fails in a fair number of cases.

And so overall the quality of this information is sort of mid to low. And as a result these apps don’t work as well as the developers would like them to work. Subscribers end up having apps that don’t work as well as they could.

And, you know, sometimes this results in calls to help desks when you’re a Malaysian ISP and your subscribers are all getting Google in English because you suballocated from someone in Singapore and Google thinks that you should be getting Singapore Google, which is in English and not in Malay.

So when you as an operator get this call, you don’t have a good way to fix this because all the data is being scavenged from some source you have no control over. And you have to rely on these ad hoc things like a wiki that NANOG operates that has individual email addresses and web forms you have to go through to fix everything.

And so because of these first three problems, there are starting to be some interim solutions that are doing some very bad things for privacy, things like having operators install things in their aggregation routers that will act as the man in the middle on http transactions and inject geolocation information in a way that subscribers can’t control or can’t see.

And so the question arises: Can we do something as ARIN to help this situation? So I wanted to propose this solution as a potential thing to make this situation better.

The idea is to add — people are already using the Whois database for geolocation. They’re using the registration information that’s in there as geolocation, even though it’s actually not.

So the question is maybe we should actually just add a field there to have geolocation.

And so what would the form of this look like? It could have two things. I’d like to propose that it is useful to have two possibilities here.

One is to have one of these geo URIs. So you can just say, you know, at these coordinates the U equals an uncertainty radius in meters. So within two kilometers of this point on the Earth, that’s where these addresses are used. If we attach this to a prefix, say.

That’s very direct. You know, it’s useful in situations where there’s not really concerns about privacy. I mean, I imagine using this for like the BBN offices where we were not really concerned about revealing we actually have an office over here and you should provide us content that’s localized for this place where our office is.

Now, the second option is to do sort of an indirect form of this and to have an http or https URI that uses this HELD protocol that the IETF has developed to allow some external source of location to provide the ultimate location and the Whois just to act as a matchmaking service.

So in this http case, the Whois database wouldn’t store the geolocation. It would provide a contact point where an application could go to find the real geolocation.

That’s kind of nice from a privacy perspective because then the control over who gets location, who gets what location, is entirely between the operator and subscriber.

The registry, ARIN, never gets involved in that. And in that case the location information never actually shows up in ARIN’s hands. There’s no privacy concerns that ARIN has to address.

So, yeah, that’s the proposal. There’s a similar — some similar work going on in the RIPE region. There was a prototype that their database team released that’s mainly of that first form I mentioned. Second on the slides, first as I talked about it.

The RIPE prototype actually just allows you to associate a pair of coordinates with the resource instead of having any uncertainty radius or any form of indirection.

But that’s — their first prototype is ongoing discussions around that. There’s also been a little bit of discussion of this in the APNIC region.

In those regions, there’s a little bit more pressure for this because of things like language concerns. There’s a lot more diversity of languages and a lot more need for content localization in those regions. It’s driven a little bit more need in those regions, but it’s under consideration there now.

So basically wanted to bring this forward and say should we — is this a policy that people would be interested in? Information people would be interested in having the database? Or is this just nuts and I should go away?

So questions?

John Curran: Back of the room.

Matt Pounsett: Matt Pounsett, Afilias. Is there a particular reason why the LOC record in DNS doesn’t suit your needs here? It allows you to specify coordinates and precision.

[Inaudible]

Richard Barnes: I’m familiar with the LOC record. So that may address the direct form here and that may be the thing — a simpler way to do that.

What that misses is some richer geolocation cases. The LOC record works really well. It has two coordinates. And I don’t think it even has an uncertainty radius.

Matt Pounsett: Yeah. It does, coordinates and precision.

Richard Barnes: Pardon me. Three coordinates and uncertainty radius. So it works well when you have that level of information which is saying it’s in this geo URI. So maybe for that case that’s good enough.

But where we’re more — where other things are more useful is in things where there’s some sort of non-uniform uncertainty, where you might have — the cellular operators are very fond of ARC bands, for instance, where you have a ranging measurement for a cell phone and you know what sector of a tower it’s in.

So this reference location service that you could get through an https URI could provide that additional location semantics. And it can also provide things like civic addresses, where you can say at this street address you’re in this state, you’re in this locality. So there’s additional semantics there.

You could have in addition to what’s in a LOC record. Sort of empirically, people aren’t using LOC records. You could also make that observation.

Bill Woodcock: There’s a reason why people don’t use LOC records, because once they get started, they get phone calls telling them to stop. No reason to think that that wouldn’t happen again since that happens every time people put accurate geolocation data out there.

Richard Barnes: Keyword there might be “accurate” and perhaps “visible.” Because some of the stuff that’s going on now is injected, is introducing location in a way that’s not visible.

And so maybe by providing a channel where people could provide some lower-quality forum than a LOC record provides could be visible but not something that makes people uncomfortable. Sort of privacy managed.

Bill Woodcock: I guess my issue is the same as Matt. This looks like re-innovation to me. Looks like you’re taking essentially an existing protocol and saying, well, now we’re going to deliver it over a different channel when there’s no problem with the current channel.

Cathy Aronson: Cathy Aronson. When we were discussing bringing this to the Open Policy Hour, the question that I kept coming back to is whether or not — where this would fit in our process. And maybe, John, you could speak to that, like if as a community, whether we — you know, if we wanted to do this, put this data, these data in the Whois, then would that be a suggestion process thing?

Would that be a policy process thing?

John Curran: If you wish to require it to be in Whois, then it needs to be in the policy. And as the directory services section of the policy, you just add another number in there and you say organizations shall blah, blah, blah. There you go.

If it’s just ARIN should support this as part of the Whois service, then just make a suggestion and we put the technical work in the budget.

Cathy Aronson: My impression of this was more of the latter, where if it was available people might use it.

John Curran: That’s correct. In the suggestion process, it will mean I’ll take it and I’ll add it to the list of requests and I’ll prioritize it with the Board and they’ll cut the budget and we’ll do what we actually do.

No, it will get in there in a priority somewhere based on the feedback received.

Center rear mic.

Michael Sinatra: Michael Sinatra, ESnet. Speaking as my organization, we do use LOC records and DNS.

Now speaking as myself. A little analogy. A few years ago a couple of really crappy airlines — let me make this hypothetical.

A few years ago, on another planet, a couple of really crappy airlines merged. And everyone was to believe that they would produce this really great airline. And what they produced was an airline that people had to drive to other cities just so they could avoid taking.

We’re combining two flawed things. I mean, personally I don’t have much good feelings about geo IP. I think it is flawed. And I think that we have enough trouble trying to get Whois kept up to date, especially the fact that ARIN doesn’t have that many enforcement mechanisms to make it happen.

I don’t see how combining these two things is going to produce something that’s better. And you can answer that as how do you think that it might make things better.

John Curran: Closing the mics soon on this topic. Far right. Go ahead.

Yi Chu: Yi Chu from Sprint. Richard, really I’m interested in this getting worked. And I have had experience actually, mainly in the Asia region, some geo provider put my customer in the wrong country and it caused a lot of problem, and it’s very, very hard to have it corrected.

What I would like to see is there’s a course level, that I can point to the record that tells the geo locator, you’re wrong it’s in this country, correct it.

John Curran: Okay. Get to the mics if you want to speak on this topic. I’ll close them in a moment. Far left.

Chris Morrow: Chris Morrow, Google. But this is really just me, not Google speaking. So I wrote down quickly five, at least, issues that I ran through.

There’s some privacy issues, which people have talked about. Bill’s brought up. There’s an issue of granularity of the record. So my house is in a different /24 than my neighbor’s house, yet we’re less than 100 yards away.

It’s not clear that you want to fill the Whois database with /32 records for the entire v4 space, never mind the v6 space.

If you wanted to get down to house-level granularity, and we can discuss those regional, granular, whatever. But the bigger issue which we talked about in the CIDR Working Group not for Whois data but for RPKI geo records, it’s an issue of bit rot. You can put this stuff in today, later on it’s not there, it doesn’t get updated or people change or what have you, there’s a huge problem of keeping this all up to date. That’s, I think, probably the biggest thing.

The other thing is that there’s a bunch of existing data gathering that happens for this, and I’m not convinced there’s really a huge problem with this data anyway. It seems relatively accurate and in relatively reasonable period of time people can get the records updated.

I know that I just had something updated at MaxMind in like a day. So I’m not special in this case. I just found that little support thing and put in the content.

And the last bit is: Why does ARIN care? Why does ARIN care? I mean, if you’re going to put it in the Whois, in ARIN’s Whois, ideally it would be something that ARIN would care about.

It’s not really a question necessarily for Richard, but for everybody: Why would we want this? What benefit is it to ARIN? And everybody’s tools are going to have to be updated to both find it, and we can ask Kosters how that process works, or — he’s going to kill me later — or we can not only find it but keep it up to date.

And I think there’s a huge number of problems with this, and I’m not convinced that there’s a real problem anyway, with the original part. But thanks.

John Curran: Thank you, Chris. Do you want to respond to any of that?

Richard Barnes: Let me respond to a couple of those. With regard to the granularity, part of the point of having this indirected service is you don’t have to have individual records for a /32. You can have a service that knows about everything in this /16. And you can go query more precisely at that point.

So granularity is perhaps not an issue here. Regarding what existing services provided, maybe they’re not so bad. The complaint I’ve heard actually a lot recently, in addition to just the difficulty of patching things up, the major guys are obviously used to getting corrections, MaxMind and Quova and those guys. But some of the smaller websites that are rolling their own, there’s sort of this infinite possibility out there.

So that’s sort of the most discussed one. But IPv6 is an increasingly mooted one. I’ve heard it cited at several service providers as an inhibiting factor for IPv6 deployment; that they can’t get geolocation from the guys who are providing it for today for IPv6.

Chris Morrow: I think they’re just searching for a bullshit reason not to do v6. People who are rolling their own, honestly, really should think about this.

Richard Barnes: If you think of the v6 context as well, a lot of the techniques that are used to get better than Whois scraping quality right now don’t really scale to v6 because they’re based on network scans and trace routes and things like that.

John Curran: I’m closing the mics. Just the people in the queues. Okay. Center front.

Heather Schiller: Heather Schiller, Verizon. So one of the interesting parts about geolocation data is you want to be able to trust it. So the organizations who use it for advertising want to trust whatever it is.

When you can lie about the record, then the data is less trustworthy. So that’s why you have organizations who go and pay the people who know — sorry — the service providers for that specific data.

So I don’t think that putting it in Whois is going to significantly help the situation. So if you can lie in Whois and say, yeah, I’m really in the United States, give me that YouTube content, then I think YouTube or whoever the content providers are going to catch on.

So, I mean, I guess what I’m saying, it’s hard enough to get those records updated today. Like this seems like a step away from providing good data.

John Curran: Far right microphone.

Mike Joseph: Mike Joseph, Google. To touch on Heather’s point. We use a number of sources to influence where we think a user is and individual user-provided signals or even operator-provided signals aren’t that significant.

We have to get it right, at least some definition of right. And as I mentioned during the NANOG talk, which was a bit longer, it’s not clear to me that this particular signal, if available we might consider it, but it probably would not carry that great of a weight.

And that is, again, because both users and providers lie. And, finally, if this were to be implemented, it would almost certainly belong in reverse DNS, IN-ADDR.ARPA, which I think you touched on during your NANOG talk.

John Curran: Far right.

Chris Grundemann: Chris Grundemann. Irregardless of all the geolocation-specific technical details of this and speaking as someone who has been trying to at least work on clarity and accuracy within the Whois, just for email addresses and phone numbers to be able to contact the organization that controls the entire space, I wish you a lot of luck getting people to actually use this even if it were available.

John Curran: Center front.

Igor Gashinsky: Igor Gashinsky with Yahoo! I’d like to agree with Mike on what he said. We also are a very large provider that use this or use geo databases, multiple geo databases.

When people tell us that things move, we sometimes update it, sometimes not, because probably about half the time they’re not accurate or no longer accurate. And we would look at this perhaps but it would carry incredibly little weight.

And as far as the v6 geolocation, some people have rolled their own. Some not. But I can tell you that I can track a v6 address and a v4 address just fine. Thank you.

And the people who are telling you that there is no v6 geolocation, it’s providers aren’t ready to sell v6 geolocation yet because they’re not sure on the accuracy of their data.

When v6 penetration gets above 0.229 percent, they will get more signal. The data will get more accurate, and then they will actually say, hey, I’m pretty confident that this is actual real data.

So something like this, I just don’t see people who use geo data actually use.

You might as well put up a web forum that you submit into it, hey, you people have me in the wrong place and it would email the seven people who actually maintain the database. It would be just as much use. In fact, it would probably be more useful. So thank you.

John Curran: Okay. And last speaker, center rear.

David Farmer: I’m not sure I really support this, but the one thing that I would say as a plus to it is – and adding something along these lines into Whois. David Farmer, University of Minnesota. Sorry.

Right now a lot of people overload, or take data for the registration data and use that for some kind of geolocation stuff, or as an input or whatever. This would be a new piece of data that is explicitly where the network is located, not where the person that responds to subpoenas and the person that will answer email or all of those kind of things is located. It’s where the network is located.

I could see — whether it’s for geolocation or not, I could see this having some — an operational plus just as a network operator, when I’m trying to figure out what the heck’s going on, some clue about where this thing that’s bothering me is could be helpful.

John Curran: Thank you very much. Microphones are closed. That’s our last speaker. Thank you, Richard, for coming up and bravely presenting that.

[Applause]

OPEN MICROPHONE

John Curran: Okay. We still have open mic. This is the evening that we have no planned social, so we can be here until 11:00 or 12:00, whatever you guys want. Microphones are open for a short time. Yes, far left mic.

Kevin Blumberg: Kevin Blumberg, The Wire. Back to my 2011-4 clarification earlier. I was curious if when we originally proposed the policy we all thought that we would be out of space within a year, and that three years was plenty of time for this policy.

Would it be better to add or to write a policy that was very simply stated: Three years after run-out, or seven years from implementation, whichever is later?

John Curran: I’ll just say if you want a policy that does a particular task based on run-out, the best way to make sure that happens is to tie it to run-out. Because doing it by date is quite questionable.

Right now, we — ARIN doesn’t provide a forecast of when it thinks its pool is out. I have actually begun telling people end of 2012 because the most recent run rate is much slower than we’ve had before.

Geoff, who is around here somewhere and the wizard — and the wizard of forecasting, will tell me the end of 2012 is probably wildly pessimistic and we have much more time.

So if you want a policy that ties to run-out, tie it to run-out and that’s the way you’ll be certain.

Kevin Blumberg: My concern is that ARIN might not ever declare run-out, in that there’s a little bit left over so we haven’t really — we have, but we haven’t run out. That’s why I was saying: If it was tied to run-out plus just a hard stop that was far enough in advance to give people time, but at this point I don’t feel that that time is there. That’s why I was curious.

John Curran: We maintain a counter, and you could say it’s run out when it’s half a /8, .5 /8s, and that counter will drop down. It’s on the web page.

Kevin Blumberg: Is that what you would consider to be run-out?

John Curran: I’m not here. I’m moderating the mics. It’s what you consider run-out that matters. Okay?

Anyone who wants to speak about that in particular?

Geoff?

Geoff Huston: I would like to respond to that because the issue about trying to predict run-out is extraordinarily hard because of the nature of this industry.

What we actually do is we have a small number of extremely large providers and a very large number of very small folk.

But, interestingly, the large providers consume most of the address space. Prediction methods are actually based on the law of very large numbers because people in bulk are very predictable, but individually we’re very random.

When you start doing this prediction exercise on address space, I’m actually trying to predict the behavior of a very, very small number of folk. And the uncertainties are dramatic.

What we found certainly in our experience with rundown is when large folk panic, it’s all over extremely quickly. And that panic was simply unpredictable.

So I do not understand how these other regions will react once they feel the end is close. At the moment you’re reacting to business pressures. This whole economic malaise has actually slowed down the address out-the-door rate and your three-month windows have actually suppressed demand at this point. People are hanging on a bit because of uncertainty.

But as soon as the big P word, “panic,” infects you, I’d actually say you’re into a random area. If you want policies to be predictable, if you want policies to give you a sense of the future, it would be unwise, I think, to base them on an arbitrary event that will occur at almost any time like run-out.

Kevin Blumberg: I’m more than happy to say when ARIN goes below one /8 in the free pool, that the policy is effective for the next three years. Is the community — because we originally — we spent a lot of time saying, no, we wanted three years, we don’t want this, we don’t want that, is that acceptable to the community, or should this just go and run out in three years and be done with it?

John Curran: I think if I heard Geoff, Geoff is saying more certainty is provided for purpose of business planning by not tying it to the depth of the pool, whether that’s 0 or half or 1, because that pool could very quickly change and that doesn’t provide anyone planning certainty as opposed to a date.

Kevin Blumberg: But it does, because you have three years from when that pool is depleted, you have this reserved pool that you’ve got three years. And we said that was enough time for that group of people.

Geoff Huston: I honestly don’t think — if I could interject here. The statistics that we have, the issue is you’re tracking the very, very leading edge of the high-volume market which is actually down there in the mobiles and the tablet world. That world is an extremely different world to a world which has a high-capital infrastructure like DSL and so on.

We rolled out DSL slowly and deliberately and it had pace. The world that sits in your pocket is an amazingly different world, extremely volatile. It sort of ramps up quickly and then comes sliding back down and the market pressures are very different.

My point is I suppose behind that, a bit like the financial markets over the last six months: Volatility is the keyword when looking at address exhaustion. It’s really difficult to actually predict in any meaningful way at this point.

Kevin Blumberg: So we have a policy that has an expiration date that means that the policy might or might not be used. We don’t know how long we will have with that policy when it does eventually come into effect or not effect. It might expire before.

So I’m just trying to come up with a way to give some clarity to that.

John Curran: People have strong views. Seek him out. Okay.

Thank you. Center front.

Jason Schiller: Jason Schiller, Google, NRO NC. I’d like to ask the community to provide advice on whether or not the Interop space should be returned to the IANA given that the policy we discussed here today is passed and ratified by the ICANN board.

John Curran: So if we have a global policy that will prevent address space from being stranded at the IANA, should the Interop block be returned as has been an ARIN tradition, or should it not be returned and used within the region?

People who wish to speak to this matter approach the mics.

David Farmer: Yes, please.

John Curran: Yes please?

David Farmer: Yes, please return it. David Farmer, University of Minnesota.

John Curran: Anyone else want to speak on the matter of whether the Board should designate that space for return? Microphones are open.

Matthew Kaufman: Matthew Kaufman. I think that we should return it. But if I was any of the RIRs that were out of space, I would hate to have that happen.

John Curran: Could you elaborate some?

Matthew Kaufman: Yes. Because if you’re already at run-out and you don’t have any to give out, a disrupting event like, oh, actually we do have a little more, oh, actually it’s gone is really, really complicated.

John Curran: And you believe that they would see that disrupting event as being more desirable than none additional at all?

Matthew Kaufman: No, I think they wouldn’t want it to happen, but we should do it to them.

John Curran: Okay. Got it. Front and center.

[Laughter]

Vint Cerf: Vint Cerf, also from Google. Jason, I’m not sure I would know how to respond to that question without having some sense of the demand that might be facing the ARIN staff.

So I wouldn’t have any ability to answer that question yes or no without having a lot better sense for what you’re currently faced with, John.

John Curran: So at the present rate, again, recognizing the recent events of the last six months or last year or last two years don’t necessarily handle the wildly discrete events of very large ISPs coming in.

But it would be unlikely for us to run out of space on v4 at the current allocation rate prior to the end of 2012. It is unlikely. It’s not impossible, but it’s unlikely. At the end of 2013 it is probable we will be out of space.

So we have a little more time. This is not counting the Interop block. So if we add the Interop block in and we don’t get a disproportionate set of requests from the very large ISPs, as Geoff was noting, then it could materially add about a year to us pushing us into 2013 or ‘14.

Kevin Blumberg: Quick question. Leslie mentioned earlier that that block had been brought into the resource pool. You’re saying that it is not currently counted on the ARIN numbers?

John Curran: It is. It is the final block to be tapped into if — when the pool goes dry, the last block we’ll allocate from is there.

I will bring forth the matter of whether that block should be used to the ARIN Board if we get to the point where it’s time to use that block and we have a pending policy before us which we currently do.

We have a policy that states that that block should be used in region and we have a pending policy that talks about global churn. Obviously we won’t touch that block without bringing the matter to the Board unless this policy’s adopted.

Kevin Blumberg: Right, and the global policy states that it is optional for us to return it, correct?

John Curran: The global policy states that it’s optional to return it. We have a present policy that says shall be used in region unless a global policy is adopted.

Kevin Blumberg: So my comment on this — it’s Kevin Blumberg from The Wire — is that while I agree it should be returned, at the same time I want to make sure that it’s loud and clear this is not a precedent that we are setting in terms of the return of space after that.

I think it is a very good goodwill gesture, but at the same time I want to make sure it doesn’t set a precedent that the optional portion really isn’t optional.

John Curran: Recognized.

Anyone else want to speak to this?

Mike Joseph: Mike Joseph, Google. Does ARIN interpret the language of 2011-6 to imply that if a global policy did exist to distribute that space from IANA, that ARIN would then be directed by membership to return it?

John Curran: No, presently we have a local policy that precludes us from returning address space unless a global policy is adopted.

If a global policy is adopted, then we’ll follow the global policy and the global policy that we have doesn’t mandate return. So it would be a matter for the Board to designate.

Mike Joseph: Thank you.

John Curran: Anyone else who wants to speak regarding the Interop return or non-return? Okay. I got one up here and I’ve got one over there. Go ahead. Chris doesn’t want to speak on that.

Scott Leibrand: Scott Leibrand, ARIN AC, Limelight. Given the history of this Interop block where it came from, what it’s been used for, I believe that it is probably most appropriately considered a global resource.

Given the pressures on the RIR system and given the pressures of economics on where addresses are and where they’re needed, I believe it would be beneficial to the global community, to the RIR system, to us as operators, to go ahead and return that block.

I have no particular opinion as to whether it would be good to return blocks past that. That would be a case-by-case thing. But my opinion to the Board would be it would be a good idea to return it.

John Curran: Geoff.

Geoff Huston: Geoff Huston, APNIC. Let me just give you some numbers here to, I suppose, put some scale on the issue.

In 2010, the five RIRs between them collectively handed out approximately 250 million addresses, thereabouts, give or take a couple.

John Curran: That was APNIC or all?

Geoff Huston: That was global. APNIC, I was going to come to that, did a little over half, around 60 percent of that. So the demand within that region — that was before the great panic at the start of this year.

The pre-panic demand was significant. Up around 125-, 150 million addresses. You seem to be discussing the return of 17 million, whereas the last full-year demand was 170 million.

I go back to that talk I said about on Wednesday about how difficult this problem is. Because if you think about it, you’re talking about a very small block, but the industry is trying to deal with much larger numbers than that.

And I’m not sure that one address here or one address there alters the severity of the problem, the complexity and difficulty of the problem, and I’m not sure it provides us with paths through that are clear.

Now, I don’t know what the answer is. I didn’t know on Wednesday and I still don’t know. But I’d just like to say don’t fixate on the little problems.

John Curran: Thank you. On this topic, go ahead, far left mic.

Dani Roisman: On this topic. One quick note, back to Geoff’s point. 17 million addresses makes a huge difference for a very large number of small businesses where 2,000, 4,000, 16,000, 65,000 IPs actually can mean their success or demise. So that’s one of the reasons why we’re fixated on this.

But my question was, very simple question regarding the Interop block, does the number of free /8s on the front page of ARIN’s website include or not include the Interop block?

John Curran: It includes it.

Dani Roisman: I’d like to recommend that we do not include that since we don’t yet know the disposition of that block.

John Curran: We know the disposition of that block according to local policy passed in this region. That block will be used because we have a local policy to that effect. Unless we have a global policy that would take place with that.

Dani Roisman: Okay.

John Curran: Okay. At such time if there was a global policy, then the matter would go before the Board and very quickly would result in an updated counter one way or another. But we’re not there.

Anyone else want to speak on this?

Yes, Scott.

Scott Leibrand: I have a question. If any of the APNIC folks know the answer, that would be wonderful. If you don’t, I understand.

If we return this almost /8, and assuming we have the global policy in place to allow one-fifth of it to be distributed to each RIR, would — I’ve heard that the APNIC policy now is for that to go into the pool of /22 rationed space, the last /8.

Is that true? And does that change anything from your perspective as to how you see that?

That’s my own personal opinion, if that is true, is that we should still go ahead and do it, and APNIC, LACNIC, AFRINIC and RIPE can each make local decisions as to what they want to do with their one-fifth of one /8, but it’s an interesting data point anyway.

John Curran: Briefly, because if it doesn’t matter and you still think we should do it anyway, then it’s a dilutive question and really isn’t — go ahead, Geoff.

Geoff Huston: We meet twice a year. We have mailing lists. We have a whole bunch of folk who love creating policy and discussing policy.

It seems to be something we share in common with the ARIN community. Currently — currently the policy relating to v4 is, as you say, a last /8 policy because that’s where we are today.

If that situation were to alter through some further delegation of resources from the IANA, I’m sure the policy folk in the APNIC community would love to discuss this problem and sort out some solutions.

You should not necessarily assume that we would continue to press on with this policy in such an eventuality. I think you can assume we’d love to figure out how to do something with it, yes.

John Curran: Yes. You don’t say that we all share a penchant for policy development. I didn’t hear a sense of pride behind that.

[Laughter]

Geoff Huston: Is there anyone around who would like to add a sense of pride on this matter?

John Curran: Anything else? I’m closing the microphones. Any other open mic topic? Last chance.

Sandra Murphy: Sandra Murphy, SPARTA. I’m sorry, it was just the deadline that forced me to the mic. With respect to Andy’s presentation earlier today, I thank the staff for getting the slides up. Thank you very much.

Some of us at lunch realized that we had some confusion about various points which I was able to talk to Andy about and get clarification on, but I thought maybe others might want to hear the clarifications.

So I’ll speak to the points and Andy can speak the clarification. First was the private key that’s being generated in on the user end. What is it being used for? Some confusion there.

The HSM, what’s being stored in the HSM? Is it big enough to hold thousands and thousands of keys? These are sort of crypto questions. And then the answer and private key must be retained, should be retained, could be retained, all of that?

John Curran: Okay. I’ll let Andy answer this briefly, then people who want more detail should hunt him down in the hallways. Go ahead, Andy.

Andy Newton: The first question was the private key in the browser? I just want to be clear that’s what you’re asking?

Sandra Murphy: Yes.

Andy Newton: Okay. So the way that process works is the private key is loaded via an HTML 5 file API into the browser and there’s JavaScript RSA signing code in there which takes the I want to sign — I want a ROA signed, signs that, and then the next few steps in the process are to ship it off to us.

That is a private key which is supposed to be kept by the individual and not — well, it’s private. So there is also another process you could use in that which we kind of glossed over.

In the browser, you can click on the other tab and you can just cut and paste a signed request that you just did via OpenSSL or some other signing engine that’s not in the browser and ship that off to us.

That’s a separate private key than one used for the hosted CA. In the hosted CA, we actually keep the private key. So that was your second question was where is that private key kept with regard to the HSM.

There are a certain class of HSMs that keep private keys within their internal storage.

Unfortunately, they do not keep — they don’t have a capacity for any type of real application where you could do hosted CAs or so forth.

There’s another class of HSMs that are basically PCI cards which go into a host. They’re still Level 4 HSMs. The way it works, you ask the HSM to generate a private key. It then takes that private key and signs it with what’s a called a master key, which is usually an AES key, and that is kept on the HSM. The HSM’s job in life is to keep private keys private.

You can take that blob — did I say sign? Encrypted. You can take that encrypted blob and you could do anything you want with it, because the only one thing that knows how to do anything with an encrypted blob is the HSM.

And what was the third question? I missed it.

Sandra Murphy: The private key that’s generated, is it should be retained for the next use, could be retained for the next use, must be retained for the next use?

John Curran: The browser —

Sandra Murphy: When you’re at the user end signing something.

Andy Newton: You should retain that.

Sandra Murphy: And the part that, the first question, the part that I had not realized or had missed was that you’re signing a request for a ROA.

Andy Newton: Correct. You’re signing a request for us to sign a ROA.

John Curran: Right. That way we know it came from you, because you’re the one with the private key. If you give the private key to someone and they sign someone and send it to us, you’ll find out it’s equally good and you’re responsible for that.

Sandra Murphy: Yes.

John Curran: Thank you.

Okay. I’m going to close the mics. I see two people. Last two topics. Go ahead.

Ruediger Volk: Ruediger Volk, Deutsche Telekom. Just to add to the RPKI topic a little bit, John, you mentioned during that talk — well, okay, impressive numbers in pilot users.

We should actually be careful what kind of fruits we are comparing when we are looking at the stats with the RIPE RPKI.

We are using — we are looking at numbers. We’re relying parties for real-life application actually we’ll make use of it. With the ARIN pilot, it is just sandbox and please don’t use it.

John Curran: Right. Very much so. You are correct.

Final speaker.

Marla Azinger: I’m sorry if this was said, but I had to step out for a couple of minutes. But, Tim, you did an awesome job today. And you would —

[Applause]

Marla Azinger: So I wanted to say thank you. And I know I’m one of the people that jumped on you, and I’m sorry. I will try to glue my butt to the chair next time. But you did an awesome job. Thanks.

Closing Announcements and Adjournment

John Curran: Okay. And on that note that concludes our meeting for today. You are on your own for dinner. We resume tomorrow with the Members Meeting at 9:00 a.m. Everyone is welcome.

Let’s see. Important details: If you happen to be missing glasses, I happen to have a pair here. Please find me. These were in the lunchroom. Okay. Additionally, I’d like to thank our sponsor, Comcast.

[Applause]

John Curran: Thank you. Very important, without connectivity, I’m sure you would all sit through this, but it’s still very important to have good network connectivity.

Okay. Again, you’re on your own for dinner tonight. Tomorrow we’ll start at 9:00. We’re done with the policies.

Tomorrow will be the departmental reports, the Board of Trustees report, and the Advisory Council report. It should be a good day. Thank you.

[Meeting adjourned at 5:40 p.m.]

Network Sponsor