ARIN 32 Public Policy Meeting Transcript - Thursday, 10 October 2013
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting. "
Table of Contents
- Opening and Announcements
- AC On-Docket Proposals Report
- Regional PDP Report
- ARIN Customer Survey
- ARIN-2013-4: RIR Principles
- ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors
- Future ARIN Meetings
- IANA Activities Report
- RIR Reports:
- ARIN Board, Advisory Council, and NRO NC Election Procedures
- Candidate Speeches
- ARIN-2013-7: Merge IPv4 ISP and End-User Requirements
- NRO Activities Report
- NRO NC Report
- Policy Implementation and Experience Report
- Open Policy Hour and Open Microphone
- Closing Announcements and Adjournment
John Curran: Good morning. If people will come in and be seated, we'll get started shortly. Okay. Welcome, everyone, to ARIN 32 in Phoenix. I'm John Curran. I'm the president and CEO of ARIN. And we're going to conduct the ARIN meeting today and tomorrow, spend a lot of time talking about Policy Proposals and ARIN as an organization.
I'd like to welcome everyone to Phoenix. And let me see if I have my next slide. No slide? No? Let's try that button. Look at that. So we'd like to note in attendance here at the meeting we have the ARIN Board of Trustees, including Paul Andersen, our treasurer; myself; Vint Cerf, our chairman; Tim Denton, Aaron Hughes, all smeared together. Tim Denton, who is in the audience there. Aaron Hughes. Aaron's here. I've seen him. He's hiding. And Paul Vixie, our secretary. Hiding out there somewhere. There he is. Bill Woodcock is not here, though we just spoke to him shortly. Bill's the seventh member of the ARIN Board of Trustees.
Okay. We also have our Advisory Council present. I'd ask the members of the Advisory Council to raise your hand. Up here, there, and in the audience, the ARIN Advisory Council. Thank you. The ARIN Advisory Council is the body, which helps the community with the policy development. This includes listening to the input at these meetings and on the Mailing List, doing editorial work on the policies themselves, and shepherding the policies through the process.
We have John Sweeting, our chair, and Dan Alexander, our vice chair, up here as well.
The NRO Number Council is attendance Ron da Silva and Louie Lee and Jason Schiller, somewhere. There. Thank you. And the NRO Number Council, of which there's an election open right now, is the body that works with the ICANN structure and the other RIRs on global policy development. And so it's an important position, making sure that when we do have global policy that's used by the IANA in administration of numbers, helping it get coordinated among the regions.
We have a number of RIR colleagues here. AFRINIC, Anne‑Rachel somewhere out there. Yes. The RIPE NCC, Andrew is here. From LACNIC, Elisa Peirano. Yes. And from APNIC, Geoff Huston, Vivek, and Paul Wilson. Yes, yes, and yes. Very good. Welcome our RIR colleagues to the ARIN meeting. The ARIN management team is in attendance. Most importantly Nate Davis, our COO, the one who actually keeps things running. Cathy Handley is not here, unfortunately. She's off doing Internet governance. And I'll give her report tomorrow. She's our Executive Director of Government Affairs.
A re‑join to the ARIN team, Richard Jimmerson. Stand up, Richard. A round of applause for Richard.
John Curran: Coming home to ARIN. I'd like to announce Erin Alligood. Are you here? Stand up, Erin. Erin is our director of HR and administration.
As people are aware, we ended up having Erin come on board. And she's the one who is handling all of our HR needs. Of course, Susan Hamlin is here. Responsible for, amongst other, things this meeting. Thank you, Susan.
Mark Kosters, our CTO, in charge of engineering. Applause for Mark.
Registration Services headed by Leslie Nobile. Are you there, Leslie? Thank you, Leslie. And Val Winkelman who heads up our Financial Services. Way in the back, Val. These are the folks who help keep ARIN running on a day‑to‑day basis. Okay. Our Fellowship Program. We have a number of Fellowship recipients who are here. Each Fellowship recipient is given the ability to attend, travel, and so they also are assigned a mentor from the AC who helps them get acclimated from ARIN. I'd like to congratulate the Fellowship recipients, Darlene Thompson. Where are you, Darlene?
Susan Hamlin: On her way.
John Curran: Okay. Roger Caruth. Roger, are you here somewhere? Way in back. There's Roger.
John Curran: And Vernon O'Brien. Yes, Vernon, good to see you.
John Curran: The Fellowship Program is an important program. It helps get our message out to organizations that might not otherwise be able to participate in ARIN. They bring the message back to their communities and help them get involved with our organization and the policy development. Okay. We have our Postel Network Operations Scholar, and that is Humberto Galiza.
John Curran: NANOG has two scholarships, and that is the Operator of Tomorrow, Leah Ungstad. Leah? Yes, the Operator of Tomorrow. Here today, though. And the Abha Ahuja Fellowship with Te‑Yuan Huang. Yes.
John Curran: Very good. I'd like to welcome the first‑timers; first‑timers' breakfast attendees met this morning and met with some of the ARIN staff and some of the members of the elected Board and AC ‑‑ elected AC. And they learned about ARIN.
We do a prize for first‑timers, and that's right here. So we're going to need someone to come up. I see Owen. Come on up. And he will draw one of these surveys. Thank you, sir. The winner of the first‑timer breakfast attendees survey prize, a $100 gift certificate to ThinkGeek, Inc., is Leah Ungstad. We'll send it to you via email. Thank you, Leah.
I'd like to welcome everyone to our meeting. We also have remote participants who are not here. Remote participants have the ability to get the webcast, the live transcript. Oh, yes, the live transcript, very important. We have a live transcript of the proceedings. Because we do that, people like me need to speak slowly and clearly. We have downloadable meeting materials, chat rooms. Remote participants can actually participate in the virtual microphone through the chat room and they can be represented in the show of hands when we're counting that via, again, the remote chat room.
Attendance stats. We have 15 attendees from Canada, 124 from the United States, three in the Caribbean. There are 22 remote participants and 31 participating from outside the ARIN region. I'd like to thank our sponsors, the network connectivity provided by PhoenixNAP and Gila River Telecommunications. At this time I'd like to invite up Derek White from the Gila River Telecommunications. He's a member of the Gila River Indian community. He spent over 30 years in the industry, and he's on Board‑‑ Board‑‑ director of national and local telecommunications agencies. He's currently the general manager of Gila River Telecommunications.
As our sponsor, I'd like him to say a few words. Come on up, Derek.
Derek White: Good morning, everyone. Good day. My name is Derek White, and I am a Gila River Indian community member. And I have been with the telephone company for 23 years now. We are an incumbent local exchange carrier that provides voice data and advanced services to the Gila River Indian community. There's been a lot of development in our community, and part of that success has been because of the infrastructure that we have built throughout the community.
We actually have built subsidiaries to support the local exchange carrier in a low‑voltage enterprise solutions company and also a competitive local exchange carrier, CLEC. So through all three organizations, we're able to work with PhoenixNAP and your organization and get your connectivity here to the hotel.
So we hope you've been enjoying the speeds. And I thank you for your time. And I would say Musapo [phonetic]. That says thank you in our language. And enjoy your conference. Have a good day.
John Curran: I'd also like to thank in addition to our connectivity sponsors, a small start‑up that's helping us with our webcast, Google.
John Curran: Okay. So we're going to move into our policy block. We have first a report of the policy proposal statuses. That will be given by the AC Chair, John Sweeting, and then we'll have discussion of some of the upcoming Draft Policies. I want to remind people that the chair will moderate discussions of the Draft Policies so that everyone can speak and be heard. Please clearly state your name and affiliation each time you're at the microphone.
It would helpful if when you come up to the mic you can say whether you're speaking in favor or opposition to a policy proposal since that helps the AC understand your remarks. There are rules and courtesies outlined in your program, so you can go to the online program or the paper copy and you'll see those.
So today's agenda. AC On‑Docket Proposal Report given by the Chair. We'll have the Regional Policy Development Report talking about policy development in all of the regions. We're going to have an AC Customer Survey report by Richard Jimmerson. I will talk about future ARIN meetings, the structure of our meetings. There will be an IANA Activities Report. I presume Leo's hiding out there somewhere. And we'll have some RIR reports.
We'll also have, of course, a discussion of a couple of the policies.
So we will have the NRO Advisory Council, Board and NRO NC election procedure review. We'll hear from the candidates who are running for those positions. We'll have an NRO activities report presented and the NRO Number Council Report.
We have an IPv6 IAB/IETF Activities Report, ARIN Consultation and Suggestion Process Report, Policy Implementation and Experience Report, and then an Open
Policy Hour. We have a very busy day today, so let me start right in.
The three policy proposals we'll be talking about are the RIR Principles, the Allocation of IPv4 and IPv6 Space to Out‑of‑Region Requesters, and the merge of IPv4 ISP and End‑user Requirements.
Tonight we're going to have a social at Octane Raceway. Buses leave starting at 6:00. Pickup location is at the conference center entrance outside the Ballroom E. Please note you have to bring your name badge. Very important. It should be a fun time. I look forward to seeing everyone.
You have to turn in a safety waiver, so you'll see you've either pre-signed it or you're going to sign it on site. If you're not going to race, you don't need a waiver. You must sign the pre-signed waiver and the one on site to go cart and other high‑risk activities. Sounds like a fun time. Okay. You have until 1:30 today to get the safety waiver to the registration desk.
Okay. So at the head table: Myself; Chairman Vint Cerf; Vice Chair and Treasurer Paul Andersen; John Sweeting, Advisory Council Chair; Dan Alexander Advisory Council Vice Chair; David Farmer of the ARIN AC; Chris Grundemann will be up shortly. And Cathy Aronson's over there, who is doing our jabber moderation and also of the ARIN AC.
So the first report up is the AC Policy Report, and I'm going to have Chairman John Sweeting come up and give it.
John Sweeting: Good morning, everyone. I'm John Sweeting with the ARIN Advisory Council. I'm going to give you a quick update on what's on our docket, what the AC is currently working on. Which one, John?
So the current proposals and Draft Policies on the AC Docket, right now we have no proposals. There's nothing that's come in that's waiting for us to take any action to move it on to a Draft Policy. So I don't know if that's good or bad. But it is what it is.
We have three Draft Policies, which we're bringing here to ask for your feedback and help us to turn them into useful policy. And some of the criteria we use: Are they fair, technically sound, and supported by you, the community.
So at the AC meeting on Friday, we're going to be looking at ‑‑ we're going to take all that input and feedback that you provide to us and we're going to discuss each one of these policies. One of them is a Recommended Draft Policy, which means that the AC can determine to send that to Last Call after our meeting on Friday. We will take a vote and based on what we hear here today, what we heard Tuesday at the PPC and what we've been reading on PPML and we'll make a determination one way or another whether to send that to Last Call or not.
The other two, the Draft Policy 2013‑6, the Allocation of IPv4 and IPv6 Address Space to Out‑of‑Region Requesters, is still a work in progress, and we're really looking for all the input we can get. If you have an opinion on that, please get up and share that with us today.
Also the Draft Policy‑7, merging IPv4 ISP and End‑user Requirements, that as well is a work in progress. And, again, we're looking for input on that and your thoughts and opinions.
Those two, since they're not Recommended Draft Policy for this meeting, cannot be sent to Last Call. However, we can move them between now and the PPC at NANOG in February. We can move them to Recommended Draft Policy for that meeting and they would be able to go to last call after that.
We also have lunch table topics today. You're going to find ‑‑ I believe there will be little banners on the tables that will tell you what the topic that will be discussed at that table.
We have the AC members. We'll host those tables and we'll take notes and stir up conversation and take note of your observations and pass them back to the AC.
I'm not going to read through all this, because you can all read. So try and check that out and look for the table that you really have an interest in. And if that happens to be full, find the next one.
I'm sure a couple of these are going to be very, very well attended. We've even had to put tables together before for some of these topics. And some of these topics we visit over and over because it's a changing, dynamic situation.
So, all right, that's it. Any questions? As we said, we're going to keep this short. Don't see any questions. So thank you very much. And I hope you all enjoy the next day and a half here with us at ARIN. Thanks.
John Curran: Thank you, John. We're almost right on time. There may be a few people who are running a minute or two late, because at 9:25 is when we start ‑‑ I'm sorry, I thought we were going into policy. Regional Policy Development report with Einar. Thank you, Einar.
Einar Bohlin: I'm Einar Bohlin, Senior Policy Analyst at ARIN. This is the Regional PDP Report. And we'll be right on time momentarily. All right. About this time every ARIN meeting I take a look at all the proposals at the five RIRs, which are AFRINIC, APNIC, ARIN, LACNIC, and the RIPE Network Coordination Center, and I try to get a sense, first of all, how many proposals there are and what categories do those proposals fall under.
Right now we're in the fourth quarter of 2013. There are 33 proposals. If you went to all five RIR sites and counted them all up, you'd see 33. A little more than half are still on the topic of IPv4; we have a little bit on IPv6, a couple on directory services. And what looks to be like a growing "other" category is other.
And you notice there was a spike in 2011 when IANA ran out. There were a great deal of proposals and the bulk of them were on the topic of v4. So why do we look at other RIRs' proposals? For one thing, it's a heads up what might come to our region. What's being discussed today, for example, at LACNIC might be on the agenda at the next ARIN meeting. That's one reason. Another reason is we do have a policy that's dependent on other RIRs having a similar or compatible policy.
And that one specifically is the first of the IPv4 proposals that I'm highlighting here. It's the Inter‑RIR IPv4 Address Transfers proposal, which is being discussed at AFRINIC, LACNIC, and RIPE. Right now ARIN and APNIC have a compatible inter‑RIR transfer policy, and there have been transfers of v4 space between APNIC and ARIN.
And we're watching to see what happens at those other RIRs. There's a post depletion policy still in their policy process. LACNIC has an interesting proposal that will affect their last /8. They set aside two pools for special use, one for new members and one for existing members that have v4 resources, and they set them at /12s. And they're looking to bump them both up to /11s.
In the RIPE region there's a proposal that would unify v6 policy for end-users and ISPs. Just take the two policy sets and align them to make one single policy for v6. And then in that category of others, there are a couple of proposals about RPKI and an AS proposal. And APNIC is working on their PDP.
At these URLs you can get all of the proposals at the RIRs. And there's a link here to the NRO, which has the comparative overview, which has a high‑level look of all the RIRs' policies. For example, if you wanted to see which RIR had a v4 transfer policy, you could go to this document and at a high level see, yes, APNIC and ARIN do, the other RIRs don't, as an example. Any questions?
Vint Cerf: It's Vint. I wonder whether you are thinking of adding categories, given that the other turned out to have, whatever it was, ten different proposals in it. Does it help to think about additional categorization?
Einar Bohlin: I suppose if maybe a category has at least three items, something like that. I'll watch the RPKI and the other ones, yes.
Vint Cerf: Thank you.
Einar Bohlin: Thank you.
John Curran: Okay. Thank you very much.
John Curran: Very good. We don't want to start too early. We have the Customer Survey, so I'll have Richard Jimmerson come up and give the ARIN Customer Survey presentation.
Richard Jimmerson: I'm Richard Jimmerson with ARIN, and I'd like to introduce the subject of the ARIN Customer Survey with you. And forward is on the top. So we're going to be doing an ARIN Customer Survey. This is going to be completely open for anyone to participate in that receives services from ARIN. You don't necessarily have to be a member to participate in this. You could be someone that came in and requested information services, someone who uses Whois, someone who does those type of things.
But this is going to be our first‑ever completely open customer satisfaction survey, and you're going to see this customer service survey come out around the January timeframe of next year. On the next slide I'm going to describe a little bit about what the timeline's like. But first I want to talk to you a little bit about the objectives.
The objective of doing this customer survey is to create a proactive channel for customer feedback, first of all. Many customers do not currently use our existing feedback mechanisms.
They don't necessarily come to these meetings and go to the microphone and give us feedback. They don't post things to Mailing Lists. We do right now do a Customer Satisfaction Response Survey. When we actually satisfy a request that someone has interacted with us, we ask them to give us feedback on how our services were. But many organizations just haven't interacted with us this way. We want to hear what they think about our services.
We also want to increase engagement with ARIN customers. We want to get a better understanding of the customers' needs. Right now we hear from all of you, you're very vocal at these meetings and on the Mailing List, but there's just so many ‑‑ there are thousands of organizations that don't participate in those channels, and we want to hear what they think and what they need from this organization.
We also want to build a stronger relationship with ARIN's diverse customer base. There are many, many thousands of customers that use our services for different reasons, some just for Whois, some just for routing registry, some just to get address space or an AS number.
And we want to use this customer survey as part of the things that we're doing to inform some upcoming enhancements to customer service‑focused programs at ARIN.
Now, the timeline for the survey, right now we have RFP out to five contractors that are building proposals to conduct this survey for the ARIN organization.
Later this month is the deadline for those proposals. We'll be reviewing those and we'll be selecting a contractor, and we'll be holding a kickoff meeting with that contractor. In November and December of this year, that contractor is going to be contacting many of you to do a telephone interview.
And basically the telephone interview will be 30 minutes or less and they're going to have lots of questions about your thoughts on ARIN's services. Following those interviews, we're going to work with them to create the survey questions, the survey question set that we'll use in the open survey.
And in January we'll actually publish that survey through the contractor. And we're going to heavily promote that survey and we're going to get as many people as we can to actually fill that thing out. In March and April, we're going to get the final report back from our contractor on this survey and we're going to share that information with this community.
And ARIN staff is then going to deliver the results to this community and actually prepare and build our response to how we're going to respond to the things that you've asked us to do or the things that you've told us.
So how do you participate in this? I have a lunch table that I'll be sitting at today that's on this topic of the Customer Survey. If you're interested in this, I would love to have some conversation with you at the table at lunch today. You can also send me email at email@example.com, and certainly look for upcoming announcements for the ARIN Customer Survey in the coming months. And with that, thank you very much.
John Curran: Any questions for Richard?
Vint Cerf: I have one. You said, but I'm not sure that I got it straight, when we use your services online, is there a way to generate feedback on the spot? Because that's the time when you have a reaction to something either you like or didn't like. There's an answer over there.
John Curran: I just want to say we're actually ‑‑ we received that request earlier, and we're in the process of adding to ARIN Online a "feedback" button on every page. Actually, one of our Board members suggested that earlier.
Leslie Nobile: Additionally, in Registration Services we do a transactional survey, which is what you're speaking about. When you come to ARIN for resources and you use the services, ARIN Online, we send you a link using SurveyMonkey to tell us about your experience and we have ten questions and we have you rank the various aspects.
Vint Cerf: I actually want to react to that. Because I get a lot of those, too, on many other services, and by the time I get to that point, I'm done. I don't want to spend yet more time interacting with everything, which is why the feedback button is so important. Because when I'm in the middle of filling out a form and it does something stupid, that's when I want to hit the feedback button and say this is stupid.
John Curran: We're doing that. Yes. Okay.
John Curran: Finally we get to the exciting part. Although that was pretty exciting, too. We're coming up to do the policy section. Block one, Draft Policies. The first policy up is the Recommended Draft Policy 2013‑4. I will do the introduction of the policy, and then we'll have the AC present. And then when the AC is done presenting, we'll have an open discussion, which will be moderated by the chair.
First the policy introduction. The RIR Principle Policy originated in April 2013 as ARIN Policy Proposal 187. The shepherds are Chris Grundemann, Cathy Aronson, and Owen DeLong. It was accepted as a Draft Policy in May. It was presented at ARIN PPC and NANOG 58 and again earlier this week at NANOG at the Policy Consultation that we had on Tuesday morning.
It's been revised in July and August. The staff assessment was done in September. The AC has recommended adoption of this. So this policy could be sent to the Board for ratification after this meeting. The Recommended Draft Policy is online and in the Discussion Guide.
It adds text to NRPM, which codifies the guiding principles of the registry system such as registration, conservation, routability, and stewardship. There's a similar policy proposal actually, as Einar noted, at LACNIC, LAC‑2013‑02, Principles Governing Number Resources.
Staff comments or issues: We note it doesn't appear to change any existing processes or procedures. Its inclusion in the policy manual will make it more clear to the community the principles under which we've operated. We note that some of the points, registration, conservation and routability are already in the NRPM.
The ARIN PDP contains some principles as well. And the Policy Development Process indicates that Internet Number Resource Policy must satisfy three principles: Enabling fair and impartial resource, technically sound, and supported by the community. Also RFC 2050, now revised to RFC 7020, has some principles in it of allocation pool management, hierarchical allocation, and registration accuracy.
Resource impact is minimal. The text of the policy does not create any material legal issue for ARIN. It is any effort to accurately incorporate writing the concepts that animate ARIN's activity is positive.
PPML discussion. There was discussion indicating that the three principles must be balanced with one another and the stewardship is the principle that informs the balancing act. Maybe we don't want to call it stewardship, call it what you want, balance, or, better yet, cribbed from an existing section in NRPM 6.3.8, which talks about how to weigh the three principles. There's also a question of whether this is intended to be a global policy. That came up on the list as well. That concludes the staff introduction to Recommended Draft Policy 2013‑4, RIR Principles. I'll now have Owen DeLong of the ARIN AC come up and do the AC presentation.
Owen DeLong: Good morning. I apologize if I kind of stumble through this a little bit. I wasn't expecting to give this presentation this morning. Pinch-hitting for Chris, who I'm not sure ‑‑ how do I ‑‑ there we go.
So the intent of this is to incorporate into ARIN policy a set of guiding principles that were previously in RFC 2050 with some updates to bring them more in line with the modern world we're in. RFC 2050 became somewhat dated.
The point of putting it in the NRPM is to have it owned by the ARIN community and bring it under the change management of the existing policy process within ARIN and also to provide additional clarity and communicating and community control.
The principles we strive to instill in this case are registration, conservation, routability, and stewardship. Registration is ensuring the uniqueness of Number Resources and accurate documentation of who is supposed to be using them, widespread agreement that this is the most critical aspect of stewardship of the resources, and it was moved to being the first principle in the list because of that.
Routability is about having the ability to have a routing system that can continue to scale. While ARIN doesn't have a role in the actual routing of packets and ARIN policy thus needs not to focus too much on the actual routing of packets, we do need to make sure that the policies we produce do not have such a negative impact on the ability to produce a routing system as to cause detriment to the Internet as a whole.
In terms of conservation defined, we found a few different definitions, of which I think the Science Dictionary is the one that most applies to Number Resource management: The protection, preservation, management or restoration of natural environments and the ecological communities that inhabit them. Conservation is generally held to include the management of human use of natural resources for current public benefit and sustainable social and economic utilization.
I think that is by and large what we're trying to do with Number Resources here. Sustainability, since that's referenced in the conservation definition as well, the ability to be sustained, supported, upheld or confirmed. And in terms of environmental science, the quality of not being harmful to the environment or depleting natural resources and thereby supporting long‑term ecological balance. The committee is developing sustainability standards for products that use energy, as an example usage of the word.
While sustainability does not necessarily mean the preservation of an IPv4 free pool, because that is clearly not sustainable at this point, it does include management of the distribution and redistribution of IPv4 resources in such a way as to maximize the public benefit.
Conservation versus sustainability. The objection that came up on the list, conservation only makes sense when ARIN is giving out virtually free resource from a common pool. Post‑ARIN depletion, we're talking about sustainability which means getting resources to people who need them.
In general, the policy authors and the shepherds have come to the conclusion that sustainability is a property of the resource and conservation is the act of providing sustainability. We're not conserving only the free pool. The free pool actually is a buffer against abuse. And IP addresses are a public good. Stewardship means protection, preservation, and management of the public good, which is basically the definition of conservation.
Stewardship defined from dictionary.com: The responsible overseeing and protection of something considered worth caring for and preserving. Which I think we can all agree Number Resources fall into that category or there's not much point of us being here.
So we see stewardship as kind of an overarching principle that encompasses all of the others. It requires and allows balancing of the other three principles. The balance will be somewhat different for each resource type and how to balance all principles in each section is what the remainder of the NRPM is for, not a goal of these principles.
In terms of changing the principles, we're not creating new principles. We're putting principles in a place that can be owned and managed by the community. We're putting the principles in a place that can be easily referenced.
And as per the staff assessment, this does not change current ARIN practices. It merely documents what we've been doing and why we've been doing it. If the principles need to be changed, let's first agree on the current principles as they are and then work from these to change them.
There have been some minor changes proposed to be made after the meeting. Principles and goals of the Internet Registry System should possibly be changed to principles and goals of ARIN. And then in stewardship, there was an example down at the bottom of the bullet points that is being suggested to be deleted. With that, I believe we open it up to discussion.
Vint Cerf: Could I, before we begin, let me make one observation: That when we run out of a resource, conserving it gets to be really hard. So one thing we should be thinking about is how to assure that the Internet continues to operate despite the fact that we're running out of additional v4 addresses. That should be one of our important issues.
Don't forget to announce yourself and don't forget to speak slowly enough that the scribes can keep up and, I mention this also to the folks here at the head table. Please.
Milton Mueller: Hello, this is Milton Mueller, Syracuse University, and I'm a member of the Advisory Council. So I reluctantly rise to speak against this proposal. I've been consistently opposing it within the Advisory Council. It's not that I think there's anything terrible going on here. As I've made clear in our AC discussions, I think this is kind of an unnecessary thing and the parts of it that are good are pretty much already embedded in other documents and the parts that are not embedded in other documents might cause trouble.
So let me begin with my first critique, which is that this is indeed, as I said, a set of principles globally applicable. It should not be an ARIN policy; it should indeed be something global. In other words, the principles guiding the Registry System should be universal, not just applicable to ARIN. Why are we doing this as an ARIN policy.
Secondly, I believe that the need for any kind of a global statement of principles is pretty much met by the new 7020, RFC 7020.
The only thing that's missing from that is this concept of stewardship. And I really find the concept as articulated in both the presentation and the document to be vacuous. It tells us you could have conflicts between registration, routability and conservation and stewards just somehow magically resolve these conflicts. It doesn't tell you how. Doesn't tell you what the principles are for resolving the conflicts.
So what is it telling you exactly? It's sort of inserting a word in there that makes some people feel good, but doesn't really do anything. By the way, Owen, IP addresses are not public goods. This is just economic science. Public goods are non‑exclusively held, and IP addresses must be exclusively held by a user. You can consider them a common pool resource in the economic terms, which is a class of resource which you might want to manage collectively but which do need to be individually appropriated.
So, again, some of the rationale behind this seems to be not that well thought out. So, again, I'm not hostile to this. I think I could actually just go along with it if you got rid of the stewardship section. But I don't think it accomplishes anything good, and I think it's duplicating what's already been done with 7020. Thank you.
Vint Cerf: Thank you, Martin. Are there any other speakers on this subject? Mr. Vixie.
By the way, in case anyone's wondering, I'm wearing the headset not to listen to a football game. It's allowing me to hear what's going on and as opposed to the acoustics. As many of you know, I'm hearing impaired, so this is helping me.
Paul Vixie: Can you hear me now?
Vint Cerf: Wait. Let me get my mobile out.
Paul Vixie: I want to speak in favor of this proposal, no specifics except to say that we were informed in the bright shining light of RFC 2050. I think that given that 2050 has been obsoleted, we need to move the founding principles that matter to us into our own documents, and I think this proposal does that. Thank you.
Vint Cerf: Thank you, Paul.
Bill Darte: I'm Bill Darte, retired from the University of Washington. I'm on the Advisory Council. I speak in support of this proposal. I echo what Paul has just said. But, in addition, I'd like to speak to, you know, the way global policy and things work is most often a policy emerges out of one region and it's considered by other regions. So there's no reason why this couldn't be global policy. In fact, I would encourage that kind of discussion in other regions and for everyone to embrace these principles, which I think are important.
The other thing I would take issue of is the issue of stewardship. I think there is a magic that makes stewardship work, and I think it's what's going on in this room right now. I think stewardship is the debate over how things need to be done and how balances amongst the various principles must be arbitrated. And I think it's the principles of bottom‑up, open, and transparent organization that all of the Regional Internet Registries enjoy is what is the magic that makes stewardship really work.
Vint Cerf: Thank you very much. I think that's very well put. Next.
Chris Tacit: Thank you. My name's Chris Tacit and I'm here representing TekSavvy Solutions, a Canadian ISP. My concern is merely with clarity, as a lawyer. And so I've got two major concerns. So I think TekSavvy would support this in principle, but it's just a matter of how this would translate operationally. So the two concerns I have, the first is that a lot of the terms that define the specific areas of policy statement that this Draft Policy seeks to introduce or discuss, which is registration conservation, routability and so on, are already used in the NRPM.
And I would want to see a little more thought given to ensuring that there is either some overriding statement that for the purpose of the policy statement those terms are unique or some better attempt to reconcile the use of the terminology between what's inside the NRPM and the policy statement.
That's number one. Number two is the concern that the first speaker outlined, which is in the case of a conflict between the objectives, what process is used to break that deadlock? We don't want to know exactly how it will be done on a case‑by‑case basis. But systemically, what would it look like.
So I don't want to get overly prescriptive, because we don't want to handcuff staff completely, but we need some sort of a guide. Otherwise we run the risk that a very well‑intentioned policy statement could actually create more confusion, and that's really my concern.
So the bottom line: I think the policy needs more work and I'd like to see those two things addressed before it comes back for a final sort of vote on it. But I love the thrust of it. I love the intent. So thank you very much.
Vint Cerf: May I make the assumption that the scribes are keeping track of these comments? Go ahead. Actually let me switch back and forth. Let me get the microphone to the right of the room, please.
Matt Pounsett: Matt Pounsett from Afilias. I'd like to speak in favor of the proposal. Excuse me. As Paul said, these are all things that were essentially enshrined in 2050. As we're losing that document, I think it's important that especially the sections of it that are disappearing in the update be enshrined somewhere, and in our own documents is a good place to do that so we can maintain it.
As a policy, it doesn't necessarily need just to comment on some of the other comments. As a policy it doesn't need to give us procedure for things. These principles are meant to guide how we generate the rest of the policy document. It's meant to inform the debate. And, as was said earlier, it's that debate, that discussion that actually leads us to the balance. It's not the policy that tells us how to have the balance.
Vint Cerf: Thank you.
Jason Schiller: Jason Schiller, Google and NRO NC. I want to talk for a minute on the question of should this be a global policy proposal. I want to be very clear: This was set on the list ‑‑ for those of you who read the list, you know this, but I want it to be very clear: This policy does not qualify to be a global policy proposal because it does not instruct the IANA to take a particular action.
However, one could imagine that you could easily rewrite this policy to make it applicable to IANA that they should apply these principles when giving resources to the RIRs. And such a policy could be submitted in all five regions and potentially passed. And that could be a global policy proposal.
The question I was trying to ask at the very bottom of this policy proposal in saying should this be a global policy proposal, was to try to get people to think about whether we're really talking about ARIN principles or RIR principles and whether we should try to just pass them here in this region or if we should try to work globally with our colleagues in the other four regions and try and pass something consistent across all of them.
There is a policy proposal in LACNIC. I've been in touch with some authors in other regions. Tommy Huro [phonetic] in APNIC has been spearheading a movement to try and put together a global policy. But everyone decided it would be best to see what this community does with this policy first.
The only other thing I'd like to point out on the topic of a global policy is the LACNIC text is much more similar to where this discussion started, which was more of a cut and paste of text from RFC 2050, which this community found to be problematic because events had overtaken some of that text. But it is more in line with the text that's already in the LACNIC policy manual. So it will be interesting to see what this community does as well as what LACNIC does, and it would certainly be useful to know if people think it should be RIR principles and if we should move forward with a global policy after we discuss this one.
Vint Cerf: Thank you, Jason. John and then Bill.
John Curran: Okay. On the topic of global policies. Jason is correct in that the definition of a global policy per the NRO ICANN MoU is that a global policy provides guidance to the IANA. And so this would normally not qualify as a global policy if it's in fact simply RIR principles. That's not that it couldn't be rewritten to be guidance to the IANA as noted. But it would not on the face of it be normally considered a global policy. It is true that even if it were considered a global policy it would need to pass in all five regions in order for the ASO, AKA the NRO Number Council, to do its magic and make it a global policy.
So the principles still need to be discussed in all five regions if that's the goal and need to get converged. I'm going to open up a tiny little hole, and I want people not to get excited by it but I want people to see it. While the NRO ICANN agreement says a global policy is instructions for the IANA, there is one Internet consensus policy, ICP-2, which is an overarching one, which provides more information and would not meet a global policy definition.
It is possible, if there were consensus that this was necessary and all the RIRs agreed, that ICANN and NRO could agree on something to go and become global policy that was not instructions to the IANA. But the first basis of that would have to first be showing that these principles were supported in every RIR.
I want to make sure Jason heard me. Got it. So one way or another, if we want a global policy, you have to discuss it in all the RIRs. It doesn't necessarily have to become IANA guidance if indeed there is real consensus on it.
Vint Cerf: Thank you, John. That sounds like the beginnings of ICP-3. Bill.
Bill Darte: Bill Darte, AC again. I'd like to respond to an earlier comment in bringing this back to what's really important in the ARIN region is this proposal as opposed to its globalization.
I think it was pointed out that some of these principles and terms are sprinkled about throughout the other portions of the NRPM, and I agree with that. And all the more I think, in concert with what Owen said, it's time to sort of enshrine these principles in our documentation at the head of this documentation and then, in subsequent rounds, we can either modify them, as we do with any policy going forward, or we can then use that enshrinement as an overarching set of principles to go back and redact all these other incidental and embedded sort of principle statements that are part of other policies that need not be sprinkled about in there, and it would just make it a better document overall, in my opinion.
Vint Cerf: Thanks, Bill. Central microphone, please.
Matt Petach: Matt Petach from Yahoo! I currently oppose this proposal. I read this and realize these are great overarching principles. These are principles that have guided ARIN in the past. But these are principles that guide us in the development of policy, and as such I think these are better indicated in the Policy Development Process as these are guidelines that we should be following when developing policies, rather than putting it into the Number Resources policy itself.
So I oppose its inclusion in the NRPM. But I would propose back to Bill that probably the Policy Development Process is a better meta place for this. Thank you.
Vint Cerf: Jason. I have to look to the side to realize that people want to say something. Please remember to announce yourself.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Sorry about that, too close to the mic. To respond to Matt's comment, the inclusion in the NRPM brings it under community control, which I think is a desirable thing. While these policies are intended not to change a lot over time and to be guiding principles, I think it's important to bring the change of those principles under the sphere of community policy development and community control.
If we place it in the PDP, it goes under the control of the ARIN Board of Trustees who has exclusive control over the development and changes to the Policy Development Process. And while it's not a terrible thing, I think it's far better to have these principles under the control of the community. Thank you.
Vint Cerf: Now Jason.
Jason Schiller: Jason Schiller, Google. I support this policy. I wanted to speak for a moment with regard to stewardship. If we could back up one or two slides to the text that we're planning on dropping.
So the text we're planning on dropping says: For example, conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on registration because they come from a moderately-sized pool that are not subject to aggregation.
I think it's important text and helps to give guidance to how someone would go about balancing the different principles. But I believe the community has decided that it's not really a principle in and of itself, and that's why it should be stricken.
I would recommend that we don't actually lose this text by deleting it but rather put it into the rationale for the statement so it is recorded somewhere, because I think it is useful guidance.
The point here is that you really do need to balance the different principles. And based on the resource that you're using, that balance might be different. And I think we don't want to give instructions to say, you know, this is a numbered list and the first principle is more important than the second. Or when the first and second are in conflict, go with the first.
That's not the right approach here. The right approach here is for us to be reasonable when making policy to go back and reference the principles and to discuss them here in this forum and through that discussion we should find the right balance, as Matt suggested.
So I think that the stewardship text is valuable. It notes that the principles are in conflict with each other and we have to strike the appropriate balance and that may be different for a different resource. Thank you.
Vint Cerf: Thank you, Jason. Milton.
Milton Mueller: Yeah, I'm Milton Mueller, Syracuse University. Still not convinced that we need to do this at all. I've noticed that several of the speakers have noted that 2050 has been expired, and I brought up the subject of 7020, and it doesn't seem like anybody has really addressed that. So I just want to direct your attention to this.
It is an IETF document, which means it's globally applicable, which I think it's very clear that it should be. If you look at their three goals, which are the same as principles, they talk about allocation pool management. And if you read the text, it's clear it's conservation. It's actually more carefully phrased, I think.
Number two is hierarchical allocation, and that's the same as routability. Although the term "hierarchical allocation" was rejected in the ARIN region in the discussions of this document, which raises questions about whether we're actually diverging in our principles from what is in this IETF document, which is one of the problems associated with doing this on a regional basis.
And the third one is registration accuracy, which, of course, corresponds perfectly well to the registration part of the document we're discussing here. The only thing that's missing is stewardship. And as we've seen, basically Bill Darte gave a very good discussion of what he thinks stewardship means. If what he said was actually in the document, it might be a little better. But basically what he said was that stewardship means we debate these three principles here in the policy‑making process. Which is true.
And, again, I don't think we need to state that. I think that's implicit in the PDP and maybe even explicit in the PDP. In other words, stewardship is the policy‑making process. It's where we make the balance of equities between different goals of the system. I still haven't heard anything that makes me think we actually need this document. Thanks.
Vint Cerf: Thank you, Milton. Let me get this. First of all, now double‑checking.
Mike Joseph: Mike Joseph, Google. I support this policy. I think it's certainly reasonable in the ARIN region to pass policy language that applies to what the members of the ARIN region believe capture our guiding policy principles. The fact that it may at some point become a global policy or a globally coordinated policy does not necessarily preclude us from capturing our own policy interests in the NRPM.
Furthermore, I reiterate Owen's point that this is a ‑‑ the NRPM is the primary area in which the community of ARIN gets to exercise control and to articulate what we believe as a community, and I don't think it's all unreasonable to capture at the beginning of the NRPM the principles under which the rest of the document should operate.
So I believe that this policy does a good job to capture that and, furthermore, I think that capturing the principle of stewardship is important. It's the basis on which ARIN has historically operated, and I think it's the basis on which most of the members of the community continue to operate. So, again, I support this policy as written.
Vint Cerf: Thank you. Let's get the right mic. I'll get you in a minute, John. Right microphone, please.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I generally support it, this policy. I've had a bit of a hard time with it because my inquisitive mind has been always asking why, why does this policy exist. It doesn't really serve a purpose, but at the same time it does. And then I realized that this policy is very different from others in that it's not dealing with an issue today. It's a long‑game policy. It's for us to remember and to remind ourselves continually of where we came from and where we need to be and the key and core issues.
My only concern with this is we are adding in definitions for many years from now and will conservation mean the same thing ten years from now or five years from now, I don't know. But, then again, we have this process. We can change this policy, then. So overall I do support this. If there are concerns for down the road, we as the community can fix this down the road. I don't see any issue with it today.
Vint Cerf: Thank you very much. John Curran and then right microphone. John.
John Curran: So these principles and whether the community supports them is a very important question. And it's a question for the community, not for staff. Where these principles end up ‑‑ I've heard two speakers indicate their desire to be in the Number Resource Policy Manual, because that's something that's under the control of the community, unlike the Policy Development Process.
And that is an interesting point, actually. So if the Policy Development Process and the principles by which it operates isn't under the control of the community and these principles are felt important, so thus they need to go into the Number Resource Policy Manual, that is one of two options. The other option is to take aspects of the Policy Development Process, like its basic principles, and put them in a place where the community or the membership have control over them rather than just the Board.
So I raise this because the discussion of what principles are important is very important. But it's also not inevitable that the NRPM is the right place if this community really converges. It could ask the Board to make these more durable than simply other Board documents and not subject to being changed without a similar community process. This is something that's come up in the discussion of the accountability of the organization to the membership, and we'll be looking at a little more of it later this year.
Vint Cerf: Thank you, John. Let's take the right microphone then a comment from the head table. Please go ahead.
Lea Roberts: Lea Roberts from Stanford University. I spent a few years on the AC as well, though I'm not there anymore. I think this captures very well what I understood the principles we were operating under the many years that I was participating, and I see no ‑‑ I have no objection to putting them in the NRPM as a sort of explanation of what underscores policy decisions. But I certainly would support John's alteration if that went forward as well. But I do support this policy as written to go ahead at this time.
Vint Cerf: Comment from the head table.
Cathy Aronson: Marla Azinger, Frontier Communications: Anything that removes the global connections this currently contains would not be true to what is done. There are policies ARIN executes that are global touching, so I do not support removing the words "global" or anything changing RIR to ARIN.
Vint Cerf: That's an interesting comment. Let me take the central microphone now.
Heather Schiller: Heather Schiller, Google Fiber. A couple of years ago ‑‑ ARIN has a mission statement, and a couple of years ago the word "stewardship" was a part of their mission statement. And it mysteriously disappeared. I think the ‑‑ I'm not sure whether staff or the Board of Trustees modified the mission statement. But the word "stewardship" no longer is part of that.
So I agree with Owen's statement about having these principles and trying in the NRPM in a place where the community has control over it. And I understand the community has say over the PDP as well. But it was a very surprising thing to me to see the word "stewardship" be removed from ARIN's mission statement. I think putting it back in place where the community has control over it is a good thing.
Vint Cerf: That might actually reinforce the point that there is a stewardship responsibility by putting that in the community context. Are there any other comments at this point? So now I have a question for Mr. Curran. At this point, am I going to try to figure out whether we should proceed with this? Is the typical mechanism by this a show of hands as opposed to humming or otherwise singing arias?
Vint Cerf: Well, in that case, since I see no other comments waiting, let me ask for a show of hands for moving this ‑‑
John Curran: I'd like the tabulation mechanism to get ready and indicate you're good to go. Tabulation is ready.
Vint Cerf: Why does this feel like the launch of a spaceship? Should I do a countdown?
All right. I'll first ask for a show of hands in favor of moving ahead with this proposal, which will, in fact, unless I misunderstood, take it to Last Call. That's not correct. What will happen to it?
John Curran: Advise the AC. This is advice to the AC.
Vint Cerf: Only advice to the AC, then subsequently you decide whether to take it to Last Call. All right. So those in favor of advancing the proposal as advice to the AC, please raise your hand. Please keep them up as the counting mechanism has executed. Keep your hands up, please. We really need those paddle things, don't we? It would be much more efficient. This is part of our health plan to see if you can actually hold your arms up this long.
Let me see those who are not in favor of advancing the proposal. Even I could do this count. Keep your hands up, please. Would the counting committee report your results? I think they're obvious, but I think we have to have the results.
Susan Hamlin: They're checking the remote.
John Curran: Adding that in, too.
Vint Cerf: I'm waiting for either white or black smoke at this point.
Vint Cerf: Is this the part where I get an envelope to tear open? This is a really fascinating process. Do we have an anthropologist anywhere that could ‑‑?
Vint Cerf: And the answer is: We had a total number of 130 people voting ‑‑ I'm sorry, in the room. 51 people voted in favor to move forward to the AC and six voted against. I therefore declare that it moves to the AC for further consideration. I thank all of you for your time, and we now move to the next item on the agenda.
John Curran: Excellent. Okay. I'd like to now at this time start on the next policy proposal, which is Draft Policy 2013‑6: Allocation of IPv4 and IPv6 Address Space to Out‑of‑Region Requesters. And there we go. Thank you. Originated in May 2013. The AC shepherds are David Farmer, Bill Darte, and Milton Mueller. Accepted as a Draft Policy in June. It was revised in September of a staff assessment and it was revised again. The Draft Policy is online and in your guide.
Policy would require requesters to provide proof of legal presence within the ARIN region and to demonstrate that a majority or a plurality of their technical infrastructure and customers are within the ARIN region in order to qualify and receive IPv4 and IPv6 addresses.
Status at other RIRs. In the AFRINIC region, AFRINIC resources for AFRINIC region and use outside the region should be solely in support of connectivity back. No specific text in the APNIC region. In LACNIC, there is a proposal, principles governing distribution of Number Resources, which say the number and resources under stewardship of LACNIC must be distributed among organizations legally constituted within its service region and mainly serving networks and services in the region.
RIPE, no specific text. In fact, the other side, membership is open without conditions.
Staff assessment: Staff and legal assessment from the September 4th version is still applicable. This formalizes staff comments. It formalizes ARIN's existing practices with respect to requiring the requesters to have a legal presence in the ARIN region and to operate a network in the region. It creates new practice and processes via the inclusion of plurality of resources requested from ARIN and must be justified by technical infrastructure and customers located within the ARIN service region.
This could create a scenario where a network cannot get IPv4 or IPv6 addresses from any RIR. The location of hosting customers is hard to define. You have to think about the fact that the customer's one place and his service is actually another.
There's potential implications ‑‑ the whole virtual aspect comes up. There are potential implications with respect to IPv6 and proposed policy text, in particular. Does the community want an organization to be able to get all the space from one RIR when it comes to v6? Presently that's a practice that's often used.
Legal assessment. Long. It fills the gap in ARIN's policies, and as such is good because it makes plain the policy behind some of the existing processes. We want to avoid the extremes. We want to avoid the extreme of too little policy where it's entirely subject to staff interpretation, or overly specific prescriptive policy that would be insufficiently flexible for business entities.
The current policy uses the text "plurality of infrastructure and customers within the ARIN service region," and that may provide still a significant bar and make it possible for an organization not to get Number Resources if they have significant presence outside the ARIN region and don't meet that bar.
Note that policy language that does provide for reasonable restrictions is actually useful and does not create serious legal risk. Still underway, it's a Draft Policy, not a Recommended Draft Policy. So it will not be sent for adoption without coming forth again to the community at a Public Policy Consultation. The question is how to work the policy in so that it is fair and impartial, technically sound and supported. And there will be another staff assessment when the policy text changes.
Recent discussion on the PPML. "Plurality" is a precisely defined mathematical concept. The part I have a problem with is network located in the ARIN service region. As far as law enforcement agencies are concerned, the problem is not so much a question of depletion of the pool but traceability back to the attacker. Maybe ARIN's policy should be consistent regarding the allocation of both v4 and v6 addresses requesting that stakeholders have sufficient attachment to the region prior to getting addresses.
ARIN 2013‑6 would make a change to the existing policy as it would make it clear that customer growth in region would be necessary to justify requests, whereas presently we have some folks requesting resources using nominal equipment within the region and backed by extensive customer growth external to the region. That concludes the staff introduction to Draft Policy 2013‑6. I'll now turn it over for the AC presentation.
David Farmer: So what's the problem? There's really no policy in the NRPM for who is eligible to receive sources from ARIN. The only thing there really is a definition in Section 2.2, defining what an RIR is. The text is there.
But that really isn't policy. It's just a definition. It says what an RIR is. But this is the only thing staff has for guidance in this issue at the moment. For the most part, the intent here is to formalize existing operational practices, but as we've discussed this, at least to me it's not entirely clear we have consensus over whether the existing operational practice is what we want.
Many people assume they can't use ARIN resources outside the region or can use them only within the region, but there's no clear policy one way or the other. But to some people you can interpret Section 2.2 as saying that.
So also, from ARIN 31's Policy Experience Report, there are a number of hosting companies that are adding a majority of their customers that are out of region and the equipment's in the region and it's creating some conflict here. From PPML, John provided some information that since June 2013 there's been 52 requests that sum up to about an /11, and is this what the community wants? Is this okay? Not okay?
So this is the current text we have. I'll give everybody a moment to look at it. It's in your pamphlets as well. Four major parts to the policy, presence within the region, both legal and technical, some amount, more than trivial, within the region right now it's a plurality. And maybe we could do minimum percentage, because plurality is a fairly high bar.
Out‑of‑region use is explicitly allowed but needs to be interconnected back to the region. The same customers or technical infrastructure cannot be used to justify overlapping requests to multiple RIRs. This is self‑explanatory. So presence in the region. We are looking at requiring an active legal business, active business entity legally operating within the ARIN service region.
The current operational practice is, my understanding, a business entity formed within the region. The current language relaxes this a little bit, allowing external entities that have a legal presence to get results as well. This was a concern in the discussion on PPML.
And then we have a technical requirement of operating a network located within the ARIN service region. Fairly self‑explanatory, if you don't need something that needs numbers in the ARIN region, why you are asking ARIN for resources, shouldn't you be asking somebody else.
Minimum justification in the region. The current text requires a plurality. We could look at relaxing that to a percentage. There's a problem, though, with ‑‑ as discussions on Tuesday and on the list since then, there's significant issues with how do we ‑‑ this is a new requirement, as mentioned. And how do we determine location of some of these things? What is the location of a virtual server, is it where the user ‑‑ the customer of the service? Is it where the infrastructure is? This gets kind of complicated and creates all sorts of edge conditions and corner cases.
So plurality versus minimum percentage. Plurality means you have more resources used in the ARIN region than any of the other individual regions, but obviously you can have more total resources used outside the region than you're using inside the region.
Minimum percentage would simply require there's some minimum threshold to ensure you have something real in the region and not just something meeting some trivial amount of resources needed in the region and, you know, 99 percent being used outside in some other region.
So out‑of‑region use. This policy explicitly allows that again. And it needs to be interconnected. And I personally think this is a real big problem that many people assume they can only use the resources inside the region. This is particularly, in my opinion, a problem for v6. And on PPML there's conversation that occurred at the last ISOC event in Denver that sort of exemplifies this, and I've been involved in a number of other conversations.
So overlapping request to other RIRs. This is fairly explanatory. You shouldn't be asking ARIN and another RIR for resources at the same time for the same customers and the same infrastructure. You shouldn't get double dipping.
So there are some other issues that have come up. One is individuals, disallows individuals. This is the current operational practice. But is this what we want? Is it at least a small minority that said no? But we need to know what the consensus of the community is. There's no intent for retroactive effects here. This is not intended to make all the allocations that were made in good faith previously suddenly vanish and go away.
The policy is not intended ‑‑ the current policy with plurality is not intended to be an overall plurality; it's meant to be evaluated on the new request. And its intent is to disallow requests almost entirely based on need outside the region. So the big question is using ARIN‑issued resources almost entirely outside of the region okay with the community. In other words, is what's been occurring okay? If it is, okay, great. If it's not, okay, then we have to figure out a way to fix it. And then I would ask is the cure worse than the disease. Your thoughts, please. Discussion.
Vint Cerf: Let me preface with an interesting observation. I wonder whether anyone is capable of producing a kind of canonical set of models of what networks look like today. What occurred to me is infrastructure as a service, which is creating some confusion about where assets actually physically are and how they're interconnected with each other.
I am beginning to wonder whether we're going to need such a catalog of canonical examples in order to sort out what makes sense. Let me give you one example. Companies that offer virtual private networking capability may actually have most of their users outside of the region for precisely the reason that they're offing VPNs. This is not intended as a justification for anything in particular; it's just an interesting observation about where we are. Encapsulation has been our friend for a long time, and now it may turn out to be a confusing factor.
Let me begin ‑‑ I'm going to alternate for the moment between the center and right‑hand microphones. I'll begin with the center. Speak deliberately and announce yourself, please.
David Huberman: Hi. Good morning. I'm David Huberman from Microsoft. I have a few things to say. To the main question that Mr. Farmer asks is reuse outside of the region okay, I say no. We have for 20 years lived under a registry system that's regional. The reality is some continents are out of space or in their last /8 policy. ARIN is not.
As an ARIN‑based network, I wish to be able to continue to receive sources from the free pool and shared with the operators in my region and not shared with those outside.
Now, I'm in support of this policy in general, mechanics aside. If we can go back a few slides ‑‑ go back one slide. You asked a bunch of questions.
Vint Cerf: I'll leave you with the control. There it is.
David Huberman: Next one back. Allocations or assignments to individuals disallowed. I submit this is a red herring ‑‑ a bill herring. Sorry. There's only one or two people who feel this way. In my 14 years of experience in this arena, I do not believe this is a real issue. ARIN as a corporation has the right to decide who and with whom they will not ‑‑ will and will not do business. I do not believe this individual should be allowed to obtain resources from the registry. I want to say something else that hasn't come up here. As Microsoft, we've been approached by a gentleman who is going around to all the RIRs ‑‑
Steve Ryan: Hold on. There are anti-trust considerations. What you address, please, when you're talking about ‑‑
Vint Cerf: I'm sorry, come to the microphone. This is an intervention by ARIN Counsel.
Steve Ryan: I would ask you don't discuss particular business plans. In other words, make your policy point using an example but be very careful, that's all. Thank you.
David Huberman: There's an example. I appreciate that, Counselor. There's a business out there, there's an example out there of organizations that are petitioning ARIN and other RIRs for address space. And they're taking that address space and they're immediately turning it around and selling it. We're talking large amounts of space and we're talking large amounts of dollars.
ARIN has a bit of an issue because this kind of scam is very difficult to detect and it's very difficult to fight. Law enforcement has put this policy proposal, as I understand it from talking with them and from seeing what they've written publicly, to ensure that when we ‑‑ when ARIN issues IP addresses and Number Resources, it's doing so to organizations that are bona fide or identifiable or recognizable, are reachable. And with an enormous, a /11 and growing, amount of address space being issued outside of the region, this becomes a significant problem both for ARIN and for law enforcement.
So while you may have problems with some of the specifics and the mechanics, while you may completely disagree with me on my feeling on the out‑of‑region use, I'd like you to please at least think about and recognize that both ARIN and law enforcement are trying to stop a lot of abuse that's occurring at ARIN from outside the region. That's the point I wanted to make.
Vint Cerf: Thank you very much. Let me take a comment now from Bill over on the right‑hand side.
Bill Darte: Bill Darte from the ARIN AC. And I would just like to emphasize sort of David's last point. I think that he was saying that if you believe ‑‑ and I don't necessarily believe this, that there's a real problem that this addresses, this Draft Policy, then you need to do something like move this forward now. Because there's a certain urgency about this. And while it's applicable to IPv6, I think it's particularly important to the IPv4 issue. And we're being overtaken by the end game of that even in this region.
So aside all of the details that you might not agree with, if you're in favor of the overarching principles of this policy, then you need to get guidance to the AC to move this forward, because it's already going to take at least one more cycle of discussion and time's important.
Vint Cerf: Thank you, Bill. Center microphone.
Leif Sawyer: Leif Sawyer, GCI. I actually don't have a problem with this, but I do have sort of a thought experiment. And that's if this is really to buckle down on IPv4 allocations, why are we throwing another speed bump as the bus is hurtling towards the cliff?
Vint Cerf: Interesting. What a metaphor. From the right microphone. I'm sorry. Paul? We have a jabber comment. Go ahead.
Cathy Aronson: I have two jabber comments. Bear with me because I don't have my reading glasses.
Vint Cerf: Would you like to borrow my cheap pair?
Cathy Aronson: Marla Azinger, Frontier Communications. She says: I don't support this. This was discussed at the last conference and not supported; yet here is the topic again. Additionally, at the last conference, the staff provided numbers that didn't support a concern for this actually being a problem. However, six months ago staff did provide a certain ‑‑ provide a certain that the sky could fall due to out‑of‑region use of ARIN address space and that this could empty the IPv4 bank, a problem that doesn't exist, and if implemented could actually cause harm to North America and North American companies. Not having a hardened policy is not a reason to create policy when there isn't actually a problem or need. To date all of this has been handled efficiently by ARIN staff and existing policy.
And then Christoph Blecker of Walt Disney Company says: I'm not in favor or against this policy at this time. My understanding is reading the proposed text is that either your customers need to be located in the region or your technical infrastructure is in the region. Such as if your customer is out of region and the server itself is in region, then this would be acceptable and count as utilized. Is this the correct interpretation? Does anybody want to answer that?
John Curran: Could you repeat the final question portion.
Cathy Aronson: It says: My understanding in reading the proposed text is that either your customers need to be located in region or your technical infrastructure is in region, such as if your customer is out of region and the server itself is in region, then this would be acceptable and count as utilized. Is this the correct interpretation?
John Curran: That's a staff interpretation of a policy proposal question, so I think it's actually to me. And I'll say: Recognize that if you're an ISP, your customers have to be in region, because that is the basis for ISP extension. So we covered that on the PPML pretty clearly.
Vint Cerf: Take a comment from the right‑hand microphone then center.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I support. I don't support. The problem is that there are many different facets of this proposal, and I'm trying to delineate what those are.
In one hand we have part of the proposal, which is we really want to know that you're a verified, bona fide organization and you're legitimate and we know who you are, and that's great. I absolutely support having a registry with accurate and valid data in it. I don't know if we need another policy on that or if ARIN as an organization has the authority to do its own due diligence and make sure what it's giving out is to legitimate people. That's a business, a day‑to‑day business course that whom you are dealing with is legitimate. We don't need policy for that. We just need ARIN to step up ‑‑ and maybe that's what I'll say at the mic: Step up and get harder on these guys.
In regards to in‑region/out‑of‑region use, we have 8.4 already. We have the go to the transfer market and you can transfer it out of the region as long as it's on reciprocal policy. We're allowing that today. And yet we're saying on the free side, on the free pool side, I should say, that that's not acceptable. But unfortunately what it does is it opens up so many edge cases, so many unbelievably ridiculous edge cases that the companies that have been going to ARIN for many years legitimately are going to get caught in the backwash of this.
And I think at this point, with the end of days with v4, I think changing the game so radically because we're navigating at 180 miles an hour towards the end isn't worth it, not today. Thank you.
Vint Cerf: Center microphone.
Matt Petach: Good morning. Matt Petach from Yahoo! I strenuously object and do not support this proposal. I see the point up on the slide there saying allocations or assignments to individuals disallowed. We have to be very careful about the road to hell being paved with good intentions. I'm staring at Section 4.3 of the NRPM saying end-users, assignments to end-users; that we have a very clearly delineated section of our policy which talks about making allocations to end-users to saying in a slide, well, existing operational practices is that we're not actually going to do allocations to end-users.
If you're going to make claims like that in a policy, then you should say we strike Section 4.3 from the NRPM and make it official that ARIN isn't going work with end-uses anymore. But to hide it in vague language like this and say suddenly we're requiring you to be a legal active business entity only, without actually changing the NRPM to match, that's a bad precedent. I do not support this policy as written.
Vint Cerf: We have a comment ‑‑ you ought to bat me on the butt when you need to talk, John. How's that?
John Curran: If that is the Chair's request.
John Curran: I want to be clear. In order to request space from ARIN, you're going to end up having to sign an RSA, which we ask you ‑‑ we tell you it's your organization you're requesting on behalf. Even if it's a DBA. So you have to be able to legally enter an agreement that's a legal presence and you have to be an organization even if it's the DBA. That's a business practice.
The term you see that says end-users, you should read as end‑user organizations because that's all ARIN deals with. I believe that that title should be changed if you have a problem with it. The context that ARIN only deals with organizations probably is not sufficiently clear in the NRPM, but this policy doesn't change it either way.
Vint Cerf: Counsel, I hope you'll note that observation with regard to end‑user and its organizational component. I have a comment from the right‑hand microphone.
Matt Pounsett: Matt Pounsett from Afilias. To expand on what John just said: Don't confuse the term "end-user" with the term "individual." They're not the same thing, necessarily.
So the comments I originally intended to make, I'm generally in favor of the stated goal of this policy. But I am not in favor of the policy as written. I have some serious problems with the language. In particular, the combination of the requirement for a plurality of new resources to be used within the ARIN region combined with the interconnection requirement that will cause a serious problem for several networks that I'm familiar with.
To use ourselves as an example, we're an any-casted DNS operator. By design we do not have a plurality of equipment in any particular region. We are based in the ARIN region. That's where most of our people are and that's where our business is. But our equipment is spread out globally. They're discrete networks, and any particular address space that we get is announced from all of them.
So as a result of this, even though we're based in the ARIN region, we would have serious problems getting address space from ARIN for anything. If language like this was passed in every region, we'd be unable to get address space, period. And so I think that really needs to be rethought, the way this is written out.
Vint Cerf: If you don't mind my intervening, this is another example of the modeling problem. You look at very complex models of how IP addresses are used and routed.
Matt Pounsett: This is not an uncommon network design.
Vint Cerf: Very useful example. Let me take a comment from the ‑‑ two jabber comments and the center microphone.
Cathy Aronson: Christoph Blecker from Walt Disney had a follow on from his previous comment: My understanding from reading the PPML is that it depends on whether you're using infrastructure or the customers to justify space. If you have virtual infrastructure, VMs, or VPNs, you have to use the customers to justify it as virtual infrastructure itself, can't justify space, or could just spin up an almost infinite number of VNs or VPNs. That's his follow on.
And Marla Azinger from Frontier Communications says: I've always supported law enforcement, but this is not going to solve the issues. This is naive and a red herring to think this would solve it. Thanks.
Vint Cerf: I predict we'll have multicolored ‑‑ I'm aware we're well past our break time. Let me quickly ask everybody who would like to continue to finish this particular conversation before we take a break? Are there any objections to that? Then I'm going to proceed center microphone.
Dani Roisman: Dani Roisman, SoftLayer. We're a provider and we encourage customers to contact their RIRs if they have large IP needs on our infrastructure that don't meet with our business priorities and technical justifications.
When I first read this, I was originally opposed to the draft. But based on something that actually Leslie took her time to explain to me a couple months ago in an email and John earlier during the NANOG presentation, I'm changing my mind. I'm actually in favor of this proposal, specifically because the ARIN practice, as I understand it, is to only do business with entities operating within the ARIN service region. And I think if that is their practice and consistently their practice, it should be reflected in a policy so that they're not necessarily subjected to arguments saying that they're operating contrary to policy or not necessarily consistent with the written policy.
I do agree with the gentleman earlier who said that if we are going to move on this, we should move on it with some urgency, because if we dilly‑dally for the next eight to 12 months, a lot of ‑‑ some of what the policy is intending to complete might not be relevant anymore as far as the IPv4 land grab that's happening right now.
I do also agree that we shouldn't necessarily be doing anything to try to slow down IPv4, but especially as far as law enforcement concerns arise, they do rely upon the RIR information to identify owners or operators of IPs, and I think we need to stay true to that.
The one comment I wanted to make was that in the language where it does say operating a network located within the ARIN service region ‑‑ I believe Dave and I discussed this ‑‑ I'd like to propose that instead of operating a network located within the service region the language be changed to be a little bit more open to saying that they can demonstrate a technical justification for need within the ARIN service region. Because network is fairly specific. And if you don't have routers but you have servers, is that still a network, but that's still justification.
And as far as the comment regarding needing to be interconnected, I agree that's questionable. I put some question marks. I don't know how I feel about that, but I do agree that that last part of interconnection needs to be determined. Thank you.
Vint Cerf: Let me explain how this works. I feel compelled to explain. I have a set of hearing aids that have four different settings, and one setting is called T‑switch, which is how I can use these. But if you come and try to talk to me while I have these on and I'm on T‑switch, I can't hear a goddamned thing. And I have to recycle the thing through four different settings in order to get to the point where I get acoustic input.
So in case you're trying to get my attention, batting me on the butt usually works better.
Vint Cerf: Okay. I'm back online, and I think we're over at the right microphone.
Rob Seastrom: Rob Seastrom, ARIN Advisory Council, Time Warner Cable, former co‑worker of Matt Pounsett's, and speaking on my own behalf. I'd like to echo Matt's comments about the danger to anycast TLD operators. I think that's an important thing that needs reinforcement.
David asked at the conclusion of his slide deck whether you generally supported things. And I think that we all sort of generally support the intention of sort of the RIR system and Regional Address Registries, but as always the devil is in the details. And I believe that this policy, while well intentioned, had sort of two major thrusts ‑‑ one is support of law enforcement, and the other is support ‑‑ sort of codify existing ARIN practices ‑‑ and does not do either exceptionally well.
And so apropos a discussion I was having with Ben Edelman over breakfast, one of my concerns at looking at many policies coming down the road is do they violate the principle of predictability in the end days of IPv4? And the rearranging deck chairs metaphor has been used before, but I believe we may be past that. I believe this policy goes to the level of grasping at straws and I cannot support it as a stance (it stands). Thank you.
Vint Cerf: Center microphone.
Mike Joseph: Mike Joseph, Google. Prior to making my comments, I'd like to request further clarification from staff. At the PPC held during NANOG, one of the topics that came up was the concept of virtual hosting. So I'd like, John, if you would, to please reiterate ARIN's interpretation of this Draft Policy. If a cloud provider is offering virtual machines and seeks to justify a new allocation based on this policy for their operation of those virtual machines, would such a provider be able to count customers, which are not based in the ARIN region?
John Curran: There are two policies for obtaining additional allocations. The end‑user policy for end‑user organizations and the ISP policy for service providers obtaining additional allocations. The service provider policy to obtain an additional allocation requires justification based on customer growth. If those customers ‑‑ if this policy is not passed, those customers can be anywhere. If this policy is passed, a service provider requesting an additional block would have to be based on customers within the service region.
Mike Joseph: Thank you. I oppose this policy for a number of reasons, not the least of which it imposes a whole new set of restrictions on the way in which businesses based in the North American region can operate. Under this policy regime, businesses would be required to not only account for the location of their customers but would have to limit the number of customers they can take on based on where those customers are located.
Furthermore, it's unclear what the customer location is in a hosting environment. Is the customer location, as has been pointed out during the PPC, the mailing address of that customer, where the customer conducts its primary business operations, or where the customer's company is headquartered? All of these questions are unclear.
This policy attempts to codify what ARIN's current practices are. But it falls far short of that. Instead, it imposes not only new restrictions but introduces less clarity. For example, the policy includes language that refers to interconnection and that you may use resources obtained in the ARIN region outside of that region so long as they're interconnected, but what the policy does not clarify is even those interconnected resources do not count for your utilization.
The policy indicates it will not be applied retroactively, but we all know your address pools are made up of all the assignments you've ever gotten, not just the ones you're getting in the future. It would require two tiers of addresses, the ones you've gotten since this policy, which you have to manage in this careful manner, and all the ones you got prior to this policy.
Quite frankly, I support the idea of preventing the wholesale exodus of space from the ARIN free pool, but not by these means. So I oppose this policy.
Cathy Aronson: Can I ‑‑ I want to apologize to Marla. Apparently I missed a whole sentence in what she said earlier, and I also read Scott's comment to Christoph and didn't realize that it wasn't Christoph. So I guess I'm kind of lame at this. And the text is like six‑point font. So bear with me. But, anyway, Marla said: I don't support this. This was discussed at the last conference and not supported ‑‑ God, I can't even read this.
Vint Cerf: Are you sure you don't want to borrow my glasses?
Paul Andersen: I don't support this. This was discussed at the last conference and not supported; yet here is the topic yet again. Additionally, at the last conference staff provided numbers that didn't support a concern for this actually being a problem. However, six months ago staff did provide a concern that the sky could fall due to out‑of‑region use of ARIN address space and that this could empty the IPv4 bank within a likely four months. Clearly this did not come true and the problem does not exist and only fear discussions exist. This is attempting to solve a problem that doesn't exist and if implemented could actually cause harm to some North American companies. Not having a hardened policy is not a reason to create a policy when there isn't actually a problem or need. To date, all of this has been handled effectively by ARIN staff and existing policy. And, yes, it is a small font.
Cathy Aronson: Thank you. Sorry about that.
Vint Cerf: Right‑hand microphone.
John Springer: John Springer, Inland Telephone, ARIN AC, speaking for myself. One of the concerns I have about this is the arc that this policy has taken. In May, shortly after Barbados, law enforcement came forward; responding to staff concerns and proposed the policy with like three major justifications. And the arc that the AC's efforts have taken have followed some of the least pertinent justifications presented by law enforcement and ones that may in fact not have been too great of a concern of theirs at all.
I don't support it as written. Questions like this need to be addressed, I think, on their own. And they don't directly impact the law enforcement thing. And the reason that this has had legs, I think many of us like to support law enforcement in their efforts to do their jobs. So we may work a little longer on some of these things than they might otherwise deserve. So don't support it as written, but as far as the components, yeah, sure, we need to work on this question, but I think it's kind of orthogonal to where this policy proposal originated.
Vint Cerf: Thank you. Strikes me that goals and problem characterization would be helpful here. Sometimes problems are solvable because they get expressed the right way. That's certainly true for a lot of engineering situations. Comments from the center microphone.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I oppose the policy as written. I've gone through various cycles of supporting and opposing this in its development, mostly in opposition. The minimum percentage and the plurality and all of the other attempts we've made at quantifying what constitutes a sufficient level of in region‑ness to qualify for ARIN resources have pretty well proven that there's just no good way to address that issue.
And I think we just need to accept that organizations within the region or operating within the region need to be able to apply for address space and that the Internet doesn't really recognize regional boundaries and addresses are going to get deployed where they get deployed.
Further, as to the question of individuals versus organizations, I don't think that's particularly relevant to this particular policy. But I will say as an organization holding resources as an end-user, DeLong Consulting is a sole proprietorship that today would have a hard time convincing ARIN that I was a real business, though the IRS has no trouble believing me and collecting my taxes. So I got my resources fortunately before ARIN was clamping down on this as much as today.
So, anyhow, I'll wrap up there, but I oppose the policy as written. I think if we did delete most of the provisions having to do with minimum percentage or plurality or any of that, the remaining policy that's left could be somewhat beneficial, though I don't think it goes far enough in creating additional flexibility and I think it still might do a fair amount of harm.
If you are considering this policy in the context of IPv4, I think that's largely silly because this policy has at least a six to eight‑month‑implementation time horizon, and ARIN has optimistically a maybe 14, 15‑month supply of IPv4 addresses. So the amount of free pool, which you're trying to manage, if you're trying to apply this policy to v4, is so rapidly dwindling I don't think it matters.
Vint Cerf(I am pretty sure that John Curran may have said this and not Vint. I sent John an IM with this information directly and I believe he then responded at the mic with this information.): If ARIN does recognize that there are such things as DBA, doing business as, if you are an organization and you can contract with ARIN, that's fine. I also want to point out that the definition of end-user is in the NRPM. Clearly says an organization. It's in NRPM Section 2.6 in the definition. It may be an organization of one, but your resources are going to be registered to your organization.
Vint Cerf: Thank you. Let me take the right microphone, please.
Terri Stumme: Terri Stumme, US Drug Enforcement Administration. I'd like to thank the shepherds that worked with me on this policy. The original intent, I've been asked to kind of communicate or try to articulate what the purpose was for submitting this proposal. What is currently written was ‑‑ has really morphed from my original text. But I'd like to just point out I guess what set off alarms for me at the last ARIN meeting, and that was this statement we're seeing cases where foreign entities are creating shell companies in the ARIN region. These guys are coming back every few weeks and every time they come back they get a larger prefix allocated to them. In particular, for me, difficult to verify whether the space is being used efficiently.
So for law enforcement, when you hear foreign entities coming in, setting up shell companies to solely acquire IP resources from the region and you work on Internet investigation as I do and you see cyber criminals doing this, then you have to step up.
So I guess in a moment of insanity I thought that I would put forth this policy, and our intent is really simple; that we want ARIN staff and believe ARIN staff should be able to ‑‑ have to be able to verify these entities or individuals. It doesn't matter really to us, as long as they can verify who these people are. If you're setting up a shell company domestically in the US just to say we have a legal presence here, you know, that's okay.
But when the space is reallocated ‑‑ because it will be, because clearly ARIN staff has identified, well, these people are just coming in here to get IP space. So what stops a criminal organization from coming in acquiring the IP space? So that was the concern. And I appreciate the support from the shepherds and the ‑‑ we've had many conversations, but it really has morphed into where we are today, where we have lines of people standing up and all we really want is verification and that if I have to or ‑‑ it's not just me or DEA, we have really specific and focused things we do, but there's so many ‑‑ I think every criminal, anything criminal you could think of is happening on the Internet. Anything. We're talking child pornography, talking credit card fraud. If you haven't, I would really ‑‑ you should take the opportunity to go online and just look up what's going on with criminals, how are they using the Internet.
And we have challenges. Law enforcement has real challenges. That's why we came to these things to be educated by you folks that really know what's going on. It's not our intention to prevent any legal organization doing legal business from conducting business. We just really need support in being able to identify the nefarious activity and those people conducting the nefarious activity on the Internet.
I hope that clarifies a little bit what the intention was from the beginning. I'm not saying that I do believe some of these issues do need attention. I personally don't think that outside entities outside the ARIN region should be able to come in and suck up what's left of the IPv4 space. That's my personal opinion. But that's for the community to decide. I just want to be able to ‑‑ be able to do my job effectively.
It's a scary world out there. The changes that are coming, the transition from IPv4 to IPv6, carrier grade NATs, those all pose significant issues for law enforcement. So we're just asking ‑‑ we're open to suggestions, how we can fix this, but definitely ARIN staff has to be able to verify who these folks are and should I come in with a subpoena saying where do I go, I need to get there quickly, I need to identify these folks quickly, we need to be able to get an answer. Thank you.
Vint Cerf: These are real problems. I have to say there's a difference between identifying parties with whom a contract is being arranged and the way in which they make use of the resources which have been allocated. Historically ARIN hasn't had the responsibility or even the ability to go and ask exactly what applications are you running with the IP addresses you've been allocated, and I don't think it's in a position to do that.
The only thing I can see so far in this discussion is that the fraudulent acquisition of IP addresses that you turn around and resell isn't within the ambit of ARIN's intent.
I think this is a very complicated problem. John?
John Curran: So to make sure everyone's clear on the problem, the typical circumstance ‑‑ and we've had some 52 or more at this point request space. The typical example would be a shell corporation in the ARIN region but still a legal corporation. That's the organization requesting resources with a nominal amount of infrastructure connected in the region, which when explaining what happened to their last block of addresses, because that's what you have to do to get your next block, they provide a spreadsheet that contains hundreds of customer names to whom those addresses have been assigned. Traditionally those customer names are things in our region and we can deal with them pretty well.
If they're in another region, in another language, sometimes the street address formats we aren't even really used to seeing and you have several hundred of them, you do your best you can to verify. We actually have partnerships with four other Internet registry organizations and occasionally use people in other RIRs who can say, yeah, that's what a street address looks like over there.
But at the end of the day we're not able to perform the same level of validation that we could on that list if the customers were within our service region. We just aren't. The level we can do, the spot-checking is greatly reduced. That doesn't mean they're not valid. But the possibility of them not being valid and not being detected or for them to have been greatly exaggerated is higher.
Additionally, the possibility that when all the validation is done, all those customers disappear and the addresses are then used in some other way that we don't necessarily notice is higher. It's ‑‑ as someone said; ARIN staff should get on the ball. Okay. I want to be clear. We're doing everything we can to verify the policies being met without creating side effects for organizations that are clearly meeting policy. So at the end of the day I want people to understand we are performing verification and there are requesters who meet this profile who are being approved. And as long as the policy remains the way it is, they'll be approved. That may not be a problem, but it is in compliance with policy as it's written today.
Vint Cerf: John, at the risk of intervening inappropriately, I wonder whether the problem can be turned around in a different direction and if you believe you've received a request from a suspicious organization for whatever, by whatever definition you might apply to that, can you go to law enforcement and say: Who are these people and are they a legitimate company and blah, blah, blah.
John Curran: We actually have some great tools that let us see how a company is incorporated and we can actually get information and we'll go and say: You resemble a corporation that just a little while ago we took address space back from. And we actually do ask for identification. We have people send us actual documents, copies of passports, driver's license to do that.
So we're actually really good at knowing the organization, because that's actually an entity contracting to us. It's the customers behind that which we're getting in the count of thousands to justify address lists. That's very difficult to validate out of region. And it just has to be an understood fact. Is that a problem? That's for this community to decide.
Vint Cerf: Center microphone.
Andrew Sullivan: Andrew Sullivan. I work for Dyn. Despite the fact I have a fair amount of sympathy for law enforcement and contractual issues here, the truth is hard cases make bad law, and this would be a bad law. I'm completely opposed to this policy proposal. And I don't think we should work on it anymore.
We also operate an anycast network. We're not a TLD operator and yet we have exactly the problem that Matt Pounsett would have. And I really, really think it's going to be impossible to write a policy here that is simple enough for anybody to understand and that doesn't create a million corner cases, all of which we think: Oh, yeah, that should have an address. You'll end up with a policy you can't actually implement, and therefore we shouldn't pursue this.
Vint Cerf: Right‑hand microphone, please.
David Conrad: David Conrad, wearer of many different hats, currently in this context wearing the hat of contractor to the Department of Justice, although not in any way representing the Department of Justice. I have three issues associated with this particular proposal. One is my understanding of the intent or desire of law enforcement in this context is that they simply need and want registration data accuracy. And they need a way of gaining access to that particularly under subpoena and that sort of thing.
And one of the challenges that the current policy regime allows for is exactly what John was describing, where ARIN is not able to obtain the submission information to document where particular individuals are for law enforcement in the cases that they have some need of that information.
This boils down to a problem that I know you, Vint, are somewhat familiar with, which is basically the Whois problem that has infected ICANN for a zillion years. I fear that's where this is going to end up if there's intent to focus on the accuracy of the data, with what all that entails. The second issue is the question of parity of Regional Internet Registry policies. Right now, as was noted in the staff report, there is a policy in AFRINIC that disallows out‑of‑region use of address space. There's a proposal at LACNIC that is moving the same way AFRINIC is heading. And ARIN is unique in the three remaining RIRs with space in that it doesn't have currently any policy‑described limitations on out‑of‑region use.
I know from personal experience, when I'm wearing a different hat, the one of CloudFare, having obtained address space in all five regions, we have to go through some significant hoops and deploy stuff in far‑off places in order to obtain resources in other regions whereas within the ARIN region obviously that's not really a problem.
I believe and have mentioned on the PPML that this is going to result in an unstable situation with regards to how the address space is going to be consumed and I believe it will probably result in consumption of address space within the ARIN region faster than would be otherwise done.
Whether or not that's an issue is something for this community to determine. I don't actually have that strong of an opinion. I do have a fairly strong opinion on the accuracy of the registration databases. Many people within this community will know.
The third issue is I haven't been involved in this community for a number of years, and I have to admit a certain level of surprise in how a policy proposal can go from an initiator through the AC process and turn out to be something that the initiator may not actually even recognize.
It seems that there might be a way of improving the policy process such that at least the requester and the AC are sort of in full agreement before it actually comes to the community. I'm not sure how that would actually be pursued within the context of ARIN policy stuff, because I, frankly, have lost those memory cells, thank God. However, something that ‑‑ I mean, it was surprising to see in talking with folks within Department of Justice and their desires and intents and compared to what actually came out in the policy was somewhat different. And there's no intent to blame any party here. I'm sure blame can be spread pretty much everywhere. It just was somewhat surprising to see the end result of the sausage‑making process and compare it to the initial meat chunks that went in.
Vint Cerf: I have to say that anyone who has ever been involved in community processes of any kind shouldn't be too surprised at that outcome. If you've ever done anything with protocol in IETF, you might have a similar experience. Mr. Mueller? By the way, before you start, I realize that we're now coming up to 11:15. No more ‑‑ there are only three people left. That's it. We may either forego our break or if we have a break we'll have to push a bunch of things into the next part of the session.
How many of you people here would be willing to forego a formal break and just leave when you need to? Can I have a show of hands how many are willing to do that? A fair number. Okay. We're going to proceed. If you need to leave the room for some reason, please do so you won't embarrass us? And we have a jabber comment and then we'll get to you, Milton.
Milton Mueller: Milton Mueller, Syracuse University and one of the shepherds on this policy proposal. I appreciate the extension of the discussion here. I think there are fundamental issues raised by this proposal and the reason for the sort of ‑‑ the length of the discussion and the complexity is because these are fundamental issues that do need to be discussed. So to summarize my opinion, this policy is not ready for adoption, but I don't think we should abandon it. I think we should work out what these issues are.
Now, let me begin by agreeing with David Conrad. The fundamental confusion here is that we have conflated the identification and accuracy of registration issue with the question of the territoriality of ARIN resources. And with respect to the accuracy of registration, I believe that one of the reasons that the law enforcement agencies got such a strange proposal was that they had made fundamentally the same confusion, perhaps drawing on their experience with national jurisdictions, thinking that if they tied address allocation to a particular region that they would have a better time of verifying the addresses.
When I hear John talking, I hear that's actually not the case. Your problem is with verifying the customers that it's the organizations, and I don't hear that criminality is really the fundamental problem. In other words, if you can actually tell whether this organization is real and where it is and who it is, you just can't tell whether they're gaming the system to get more resources. That's a different issue than criminality. And you're not going to stop the criminality by restricting the flow of resources in that way.
Indeed, that brings me to the issue of the territoriality of the RIRs. I think that's something that I feel very strongly about. I think that the Internet is global. And that RIRs were created to facilitate the distribution of resources. We did not distribute resources in order to maintain the exclusivity of regional Internet addresses.
It's funny to me to hear people frequently complain about property rights and IP addresses talk about the ARIN region as if their presence in the ARIN region gives them an exclusive right to ARIN resources, which are actually just IANA resources and just Internet resources.
So I totally don't support the idea of that because you happen to be in North America that you have a special claim on the remaining resources simply because by accident ARIN has more of them left than other people. Indeed, I believe it's a serious problem, this unevenness of the depletion, and we need to get rid of the remaining IP resources as quick as possible.
That being said, I don't think it's fair for an Asian entity to, let's say, draw down these resources simply because they're free and since we do have a transfer market, you know, this is basically a problem of unpriced resources from an economic standpoint. And these entities should and could get these resources through a transfer market. The local RIR would do the needs assessment. Therefore they would be possibly better able to assess need.
So I think we have a lot of things to work out here, but I want to make two points fundamentally clear again. Number one, identification for purposes of law enforcement have nothing to do with the territoriality of address allocation and should be completely separated.
Number two; I don't believe that we should look upon the RIRs as little region nation states that have territorial jurisdiction. I think we should view the Internet as a whole and view the regions as a facilitating device to get information to people who need them and use them, and I hope our new policy will reiterate that policy.
Vint Cerf: Thank you, Milton. Comment from the right‑hand microphone, then jabber.
David Connell: David Connell from Rogers Cable from Canada. I do agree with the need for this policy. I do not ‑‑ or I object to some aspects of it. I think it's a very difficult policy to develop. There are so many scenarios that need to be considered. And it will take some time to be developed. But I don't think it should be abandoned. I think we should continue to work and develop it.
We need that level of guideline so that we can prevent the misuse of these IPs or the allocation of IPs from an entity that's not real. So something needs to be done. And we should continue to develop this policy. Thank you.
Vint Cerf: Thank you. Jason, we have a jabber comment, and Jason will have the last word.
Cathy Aronson: So Paul made this so big it's like one of those phones with the really huge numbers. It's pretty awesome. Christoph Blecker from the Disney Company said: I do not support this policy as written. The policy as written and interpreted imposes restrictions on infrastructure providers that say they cannot take on customers from out of the region for risk of not having those addresses counted as utilized. It's one thing to say that organizations that request space directly from ARIN need to be within the ARIN region, but if a virtual infrastructure provider's physical equipment sits inside the ARIN region, I disagree that ‑‑ I'm sorry ‑‑ that their space ‑‑ I'm missing a line. Where did it go? Disagree that ‑‑ it's like the line in between's gone away. I disagree that their customers need to be in region, too. I would be in favor if this policy was reduced to codify the current practice. Sorry about that.
Vint Cerf: Thank you. Jason.
Jason Schiller: Jason Schiller, Google. I wanted to be very clear. I wanted to be very clear that everyone understands that this is not simply codifying the current ARIN practice; that this is creating new requirements that could cause an organization that even is corporate headquartered in the ARIN service region, that has a significant network in the ARIN service region as well as elsewhere, has a significant customer base in the ARIN service region as well as elsewhere, and is known to ARIN in the community to be in a situation where they cannot qualify to get addresses from anywhere.
Matt Pounsett talked about the issues this has with anycast. Two other people have said, yes, they echo those comments. I do as well. But it's not just anycast. It's also virtualized hosting. Even if it's not virtualized, even if it's a physical server, if the physical server is in the ARIN service region but the customer is billed outside of the ARIN service region, does that count?
So it's problematic for anycasting. It's problematic for hosting. It's also problematic for transit providers. If the transit provider runs a physical circuit to their customer and the customer location is in the US but the bill is sent outside of the US, is the customer where the bill is sent? Is the customer where the circuit goes?
What if the circuit starts off on the transit provider's router in the US but terminates outside the US, say, in London, does that customer count as inside the US or outside the US? How do you number point‑to‑point links that are intercontinental? There are issues for anycasters, for transit providers, for virtual hosters, for hosters, and there's issues for any network that legitimately runs a global network.
Today, if you run a global network, you have customers inside the US, outside of the US; you have infrastructure inside the US, outside of the U.S. That all qualifies for address space. And that all counts as utilized. I don't know how you can write a policy that will prevent someone from trying to game the system by putting one router in the US, hair pinning all of their traffic through it, claiming that they have a network in the US and asking for IP addresses that are nearly exclusively used outside of the US, without negatively impacting all of these other what I think are legitimate use cases.
If the concern here really is fraud and being able to know where the folks using the addresses are, then let's address that. Let's require organizations to provide whatever information is required to show that they are a legal entity, that they exist, that it's not a shell company, who the company belongs to, whatever, trace it all the way back. If the concern is about the customers of that company, then let's require them to provide that information.
Let's make people SWIP all the way down to a /32. Even if you're a transit provider, even if you're an end-site. If mailing address isn't good enough, let's collect additional information. If there's a government ID number, a taxpayer ID number, Social Security number, whatever you need to collect, let's ask for that. But this policy doesn't help us reduce the fraud and it negatively impacts people that are legitimately doing business, so I oppose it.
Vint Cerf: Thank you, Jason. You were about to slap my butt; is that right? No? All right. This is the new communication tool between the Chair and the CEO. Let me make one final comment on this. It's clear work is needed. There's a great deal of diversity here. To the shepherds, a suggestion: Let's go back and look at what the problems are that the policy is intended to address. Can we codify that? Is it possible that we're trying to do too much with one policy? Is it possible that you can in fact split this out into different policies for different purposes? I don't know the answer to that. But I think you might find it useful to spend a little time working along those lines.
We have enough time, presumably, to finish before lunch if we do the remaining elements. I thank you for your willingness to forego your break. So let's go now to John Curran and future ARIN meetings unless I missed anything.
John Curran: Hold one moment.
Vint Cerf: There will be a brief conference. This reminds me of "What's My Line" where John Q. Daly has to talk to one of the panelists. That's for those who are old enough to remember, "What's My Line." What would you like to do?
John Curran: It would be helpful to the AC to know whether they should continue work on the policy. So a poll for everyone in favor of working on the policy, continuing to work on the policy, would be helpful. Clearly if there's no support for that, they'll know what to do with it.
Vint Cerf: Show of hands in favor of continuing to work on the policy, which might mean potential restart. How many people want to continue this work? Hands up, please. Keep them up while the pollster's poll.
Milton, you're waving your hand in several directions. You seemed to say earlier you wanted to continue working on this. Put your hand up.
Vint Cerf: Let's be consistent. I'll arrange for a little cord to come down and trap your thumb to keep your hand up.
John Curran: Okay.
Vint Cerf: How many people do not want to continue working on this policy? One, two, three, four, five, six, seven...
John Curran: Hold your hand high. Your elbow should be straight.
Vint Cerf: We're going to do yoga exercises at lunch, right? We really need to get those electronic paddles. This is a silly time‑consuming way of doing polls. Or get an app.
John Curran: Thank you.
Vint Cerf: All right. We will await for a moment the results. But we can continue in parallel with future meetings. At least I think I got that right. Am I not right?
John Curran: I think we should take a 15‑minute break.
Vint Cerf: You really think we should ‑‑
John Curran: Yes.
Vint Cerf: This is the CEO saying he really needs to go. Well, the only reason for wondering about that is the 15‑minute break takes us to quarter to 12:00, and then you try to get a bunch of stuff done. Okay. The poll results are: 135 people in the room, 20 in favor, 29 against. That's advice to the AC. I think the AC should analyze that result as opposed to taking that as an absolute conclusion. All right. Thank you. We're taking now a 15‑minute break thanks to the CEO. Return here at quarter to noon, please.
Vint Cerf: Well, ladies and gentlemen, I declare we have a quorum so we can continue.
At this point we're going to hear from John Curran, our CEO, about future meetings planned for ARIN. John.
John Curran: Thank you. Okay, everyone, I'd like to talk about future ARIN meetings. And this is pretty important. People might have noticed that we've successfully done some integration of ARIN and NANOG. We have Public Policy Consultations at the NANOG meetings.
This opens us up to some interesting possibilities. The ARIN plan of record calls for two meetings per year through the end of 2014, but we haven't really set something beyond that point. We've successfully obtained a three‑hour Tuesday morning ARIN track in the standard NANOG program in order to hold Public Policy Consultations. The ARIN track is now opposite tutorials, not any other conference tracks. Which is good, because trying to run a session opposite, say, peering is way too fun.
So we now have a good track in the NANOG program, and we had a very successful policy consultation earlier this week, in fact. We've conducted three PPCs during NANOG meetings so far, and the input has been useful. The participation has been a little less than the ARIN typical Public Policy Meeting. We have slightly more people in the room here than we did earlier this week, but we had very good attendance. But I'll also note that the people in the room earlier this week, more had enable‑on routers than the people in the room right now, which might matter to some people in terms of how close you are to networks.
So this brings up some interesting questions. We have spring and fall meetings. Are the spring and fall meetings still desirable given that we're also holding NANOG Public Policy Consultations? So let's talk a little bit. Here's what's happening by default, this beautiful little graphic. In February NANOG holds a meeting, and there's an ARIN PPC. In June NANOG holds a meeting, and there's an ARIN PPC on Tuesday. And then on October this year, there was an ARIN PPC in the middle on Tuesday, and then Thursday and Friday is more ARIN, another consultation, and the ARIN Members Meeting tomorrow.
I'll also note this year we did have a spring meeting, which isn't on this. I'm just showing the NANOG blocks. So if we don't do anything else, the question is this will happen by default and potentially a spring meeting. Here's what we could do, one example. And there's a lot of examples. I could come up with ten, 15 different ways to work together.
We could have a Members Meeting adjacent or after the ARIN PPC, or that evening. So we could have just ARIN meeting at NANOGs and do the member component, the reports that we do, the staff reports, the operational reports, spread throughout the year, co‑joined with NANOG. This actually reassembles a little bit what happens in some other RIRs, where there's a track which is pretty much registry oriented.
Another option would be let the Public Policy consultations happen at NANOG and maybe have a meeting or two meetings which are completely separate or one of them co‑joined. So this would be a distinct ARIN member meeting. This is what our spring meeting looks like, for example. And in 2015 we could have PPCs at NANOG and a spring or fall ARIN meeting that was distinct at some point in time.
This one shows the spring meeting. The ARIN Board of Trustees talked a bit about this, because it's one community. And so we decided it would be worth trying to come up with a plan. Every now and then the NANOG steering committee and program committee asks us ‑‑ I'll phrase it politely ‑‑ what are you doing and where are you going, because they want to know the same thing. Particularly because we need to book hotels years in advance.
So the Board mulled this over, staff mulled this over; we came up with a bunch of possibilities, some of which you saw on the slides. We're going out for survey because, look, you're the ones attending the meeting. It's been announced on ARIN Announce. It's up here on SurveyMonkey, /s/future meetings. And it's open to everyone, ARIN members, NANOG members, members of the community. There are some questions about who you are, what meetings you usually attend, and then what you want to have happen to the ARIN meetings in terms of how many, location, and adjacency to other meetings. Lots of also open fields to fill in your insights, because you all have lots of insights.
This is pretty important, folks. We'd really like people to fill out the survey and give us your views, because we need to settle this. Now that we have the opportunity of doing policy consultations at NANOG, we want to make sure we're making the most effective use of it. So that's all I was going to say. But it's open for questions, if anyone has any questions now.
Louie Lee: Louie Lee, Equinix, chair of ASO Address Council. For people considering which way to say in their survey for themselves, if the cost of attending a NANOG meeting is prohibitive for you, there is now an option to do a day pass. And I don't know if there are any thoughts on the ARIN Board to subsidize ARIN members to attend.
John Curran: To highlight something, because of the good, tight working relationship we have with NANOG, it's actually possible to attend the ARIN session, the Public Policy Consultation, just that. That's open to everyone. There are no fees. You don't need to register for NANOG. But the advantage is true that you can register for the day and get a whole day's worth of good stuff, or half a day's out of NANOG, or register if you want to go to the whole meeting.
Steve Feldman: Steve Feldman for NANOG. Actually there isn't a day pass available. Not really relevant. But the day pass is only for specific sets of sponsors who are flying in for the day, setting up a table and then leaving again. But it's what he said about ARIN people.
John Curran: You can attend the ARIN PPC without paying for NANOG registration if you're not attending NANOG. That's definitely the case.
Kevin Blumberg: Kevin Blumberg, The Wire. We have a unique moment right now in regards to this. Is it possible to have a show of hands who attended NANOG?
John Curran: Sure. If you attended NANOG, raise your hand. Okay. So that's good to know. So the counterpoint, if you're only attending ARIN, raise your hand. Those who just attending ARIN. Okay. Good to know. Okay. No other questions, we'll move ahead to the next presentation. Thank you. Next up is the IANA and DNS update with Leo Vegoda. Come on up, Leo.
Leo Vegoda: Hello, everyone. I'm Leo Vegoda, and I'm from ICANN. I've got an update on IANA stuff. So going to go through our Portfolio Management System, deliverables for the IANA functions contract, root zone key signing key rollover, and our business excellence work.
So we have this new project in Portfolio Management System, which on the face of it is not very exciting, not something to report. But we are publishing drilled‑down information on myicann.org based on the four top‑level objectives. You can go and click into them and go and see what we're doing.
Now, we've been doing this since the start of the year, and you can go and see in those October pictures there, we've got the green stuff that's complete, the blue stuff in progress, yellow at risk, and red in trouble. And there's not too much yellow and red, which is good.
This is for everything that ICANN does. Obviously if you're interested in IANA activities you can go and pick out the relevant IANA activities and you can drill down and see what we're doing. And there's a transparency improvement. You can go and see where your money is being spent.
So there's the URL. myicann.org/plan, and you obviously don't need to have a myicann.org account, but if you want to you can sign up and get all sorts of interesting daily mails if you're interested in that kind of thing or weekly or monthly or whatever. So update on the IANA functions contract deliverables. The contract was awarded and started last year. And there are month‑by‑month deliverables that we have to ‑‑ we have to deliver on.
As you can see, on this slide we've got lots of green, which is good. Means we've been completing stuff. We did consultations on things like the customer service complaint resolution process. Performance standards, secure notification process, and we deployed an update to the root zone automation functions.
Now, on the performance standards, I've got some graphs to show you in a minute, but here we've got some more deliverables. We have started ‑‑ we've started producing very detailed monthly reports on the performance standards stuff. The structure of the reports has been approved and they're going to be going on to the website very soon. And this is the overview of those reports. This is a prototype. This is basically an extract from what was approved.
And when it goes on the website I'm sure it will have all sorts of wonderful CSS to make it look pretty. But what you can see here is we've got a key performance indicator for each of these areas in each of the different functions and we've got a statement of whether we met the target or we didn't meet the target. So if you just want to have a quick look and see how are we doing, you can go and see in one quick shot that for that reporting period, all the targets were met.
Here we've got something a little bit more detailed. I picked out the Internet Number Resources because of course we're ARIN. Last month we received two requests for an AS number allocations and we made those allocations, and this is a detailed report which identifies the key performance indicators and whether we met them but it also goes and says who sent in the request and what was it for and when did they send it in and when did we do all our stuff and all the rest of it. And it's a little bit of an audit trail so you can see how well are we performing.
Now, as it happens, the requests we received last month were for AS numbers, and we are really scraping the bottom of the barrel for AS numbers. I think there's going to be more on that later on. So watch out for that. But we're coming towards the end of the 16‑bit space. We've got the same thing here for root management. There's one for delegations and redelegations. I've picked out the one here for the regular requests. You can go and see how many regular requests we get and how long do we take when we do them, and hopefully this is useful information for anyone who is involved in, for instance, providing DNS services to top‑level domains or just wants to go and see how we're doing.
So there are more deliverables. We've got stuff that's still in progress. There's a consultation with root zone partners on the contingency and continuity plan. We're preparing an update to our security plan, and there's a customer service survey, which is going to be our second one.
And that's going to happen over the next couple of months. So if you are someone who directly interacts with us as a customer, there's a good chance you'll be hearing from us and we'll be saying please complete this survey. The difference in this survey from the one we did last year was last year we didn't segment by customer group. This year we're going to be segmenting by customer group. So we'll be asking you to let us know how you're doing for your specific kind of request.
It will be anonymous. It will be conducted by a third‑party organization, and they will just be giving us the aggregated results and any of the comments, but we won't know who made any comment and we won't know who gave any particular rating. So another consultation we've been doing also related to a contract deliverable, root zone key signing key rollover. Root DNSSEC started just over three years ago, and one of the requirements is that we do a rollover for the key-signing key within five years of the root being signed.
Earlier this year we did the first step of a consultation on root zone KSK rollover. There's more coming. Basically we got a lot of good input, and that is now being worked up into something that is a little bit more specific and that will be consulted on. There are people in this room who are obviously interested in that. We're going to be asking you to watch out for that. It will be announced in all the usual places and I'm sure it will make rounds of all the usual DNS community groups, and we want your input so that when we go and do it we do it the right way.
Finally, we've been working on business excellence over the last four and a bit years, and up until now what we've been doing is every January we did a self‑assessment. We've been using a framework called EFQM, which is managed by an organization in Belgium. The main reason we selected EFQM is the framework. It's not that other frameworks aren't as good, it's more that we have customers in literally every single country in the world, and some territories that aren't countries, and EFQM is used in a lot of countries and it's not tied to any single country as a framework. So it has some recognition in quite a lot of our customers' businesses.
After our fourth self‑assessment in January, we felt we made enough progress that it was actually worth getting an external organization to come in and go and say, well, you think you're good at this, but actually you need to work a little bit harder at that and you're actually better at this and so on.
We had an external assessment in August. As a result of that we were awarded the Committed to Excellence recognition, which is the first step on the ladder towards excellence. And we're quite happy with that and we found out we were a bit better than we thought at some things and we need to work a little bit harder than we were at other things. It's a very useful experience for us and it's helping us develop and improve the way we deliver our services. That is everything that I have to report. But I'm happy to take any questions if people have any.
John Curran: Thank you. Any other questions for Leo? Thank you very much.
John Curran: Okay. We're now back on track and we're going to go to lunch because we want to give everyone time to eat. When we come back we will pick up the reports. Lunch runs to 1:30. I'll see everyone back here promptly at 1:30. Thank you.
(Break at 12:30 p.m.)
John Curran: Okay, everyone, we are resumed. It is now 1:30 in the afternoon. Welcome back. I hope everyone enjoyed lunch. We're going to pick up where we left off at the RIR reports, and we'll go through those and then we'll move on to the election work that we have this afternoon. So with the RIR reports, we're going to have four reports. The first one is from AFRINIC. And Anne‑Rachel, come on up.
Anne‑Rachel Inne: Good afternoon, everybody. My name is Anne‑Rachel Inne, as John said, and I work for AFRINIC. First of all, I want to say I'm really glad to be here. The discussions this morning were absolutely eye opening and interesting, because we do have quite a few things that are very similar in our region coming up. So I'm going to give you just a little bit of the things that we're doing in AFRINIC. I will be happy to respond to questions.
So we've grown and grown quite fast, about 40 staff that Vint got to meet lately because he was in Mauritius. And some of the things we're trying to do right now as the region is growing ‑‑ just to give you a little bit of perspective, Africa is about a billion people right now. There are only 200 million Internet users. We have – AFRINIC serves about 1200 organizations. So we're growing in kind of phases, depending on which region is having which cable, which means broadband is coming, connectivity is coming.
So these are the number of IP addresses that we issued since the beginning of the year. And as you can see, there's plenty of v4 going away. And part of the discussion that you guys had this morning on 2013‑6 is also coming to our region, interestingly.
Some of the things we're doing right now. So we have a New Member Registration Portal. One of the things that we have realized is that when people come to ask for addresses and resources in general at AFRINIC, they ‑‑ for some they're savvy in some of the things they have to provide, for others not.
So a lot of the improvements that we're making to the portal is making sure that it can be also intuitive in finding out if people know what to provide next or not.
Extension of ‑‑ we are doing a Whois database cleanup. This is something that has actually been raised by in not only governments but also law enforcement but also our members in the region.
We are extending our my AFRINIC services to our associate members now. People can be associate members. And I'm happy to say that Vint is actually one of ‑‑ he's the first honoree associate member we have at AFRINIC. Members Contacts Update is ongoing. We have contacted 100 percent of them right now. But we are barely up to about 45 to 50 percent view update, because people don't come regularly to that.
We're trying to improve service delivery to members, service delivery meaning, you know, things like telling them when the technical people come to ask for resources to make sure that the rest of their organization is aware, because one of the things that we're suffering is, for example, a lot of people end up in the queue with a lot of delay because their bills are not paid because their accountants or their financial services were unaware they were asking for IP addresses and lots of times they don't really know what it means and they have no idea what it is to become an AFRINIC member.
So we're reorganizing our core infrastructure. We're going virtual. Right now we're finished with the Mauritius datacenter. We're done with the Cape Town one. Hopefully by the end of the year we'll finish the Johannesburg one. And basically we'll continue migrating around the continent, because we want infrastructure to be as close as possible to our members.
We're continuing RPKI DNSSEC, the implementation of an environment where we can have full development tests, quality and production stuff done. We're also going through right now an ISO certification, really mostly because as we're growing and AFRINIC is kind of, as you know, the youngest organization of the RIRs, we need really processes and procedures documented and done properly.
We're hoping to launch also a development area inside the organization very soon.
So these are some of the things that we're doing with partners on the ground. So with the African Union and ISOC, we're into helping countries and ISPs and basically the community members establish understandings on how to install and establish ISPs.
We have a DNS infrastructure where we're helping some of the ccTLDs, for example, host their secondaries.
We're partnering with some of the root server operators that are here to take the instances in the region. And we're also working with RIPE NCC on the measurement program that you may know, Atlas. Policies under discussion. So the Inter‑RIR IPv4 address transfer is one that's still under discussion. It was sent back to the list. But most of the others have been ‑‑ oh. Actually, the IPv4 allocation for academic network was at the Last Call but finally was sent back to the list because they didn't have enough consensus.
Community development. We have done workshops. The latest one for policy makers was two days ago at the Commonwealth Telecommunication Organization in Abuja, Nigeria, where Tamon, our training manager, gave a really good ‑‑ I got some feedback that people really enjoyed hearing about transition from v4 to v6. Training on new services. We're partnering with intergovernmental organizations. So CTO is one of them, the Commonwealth Telecommunications Organization, but also the African Telecommunications Union and the regulators, African Regulators Forum and others.
We do have local meetings that we do on request by governments or communities. One of the latest ones was in Tunisia, where we had clusters of trainings on IPv4, IPv6, on IXP, DNSSEC and all of that, and we did that with ISOC and ICANN. We announced that the African Internet Summit last year. And it went really great. I'll show you numbers later on. And we have some new IPv6 training portals that people can use and also ‑‑ what do you call them? ‑‑ virtual labs up to the ‑‑ on IPv6 that are being finished right now for most of them.
Community development. So promoting Africa in the Internet ecosystem, so we work with the RIRs, we work with and ATU, as I said, African Union. We're an observer at the African Union at their ministerial meeting. So on things that are typically technical, for example, they ask us to give them a little bit of feedback when they're going to talk about that and they invite us during the ministerial meetings also to come talk about that.
We go to ITU just like a lot of our other colleagues at the RIRs. And we run high‑level workshops. Some of the challenges that we face are really right now as someone who takes care of the operations engine, well, it's conducting a smooth organization structure from basically a small to a medium‑sized or even greater business.
As I told you, the African continent is right now gearing up to have more networks. By the end of this year we should have available about 34.5 terabytes of data. So we're really expecting to see quite a few networks popping up by next year. So taking care of that is going to be quite a challenge, taking care of that smoothly. Push for a better understanding of Internet Number Resources at all levels, but really mostly we don't have that many government networks, for example. But right now everybody, when you go on the continent, you can hear people talking about we want e‑government, we want e‑citizenship, we want e‑ ‑‑ but they don't really know how to do it.
As much as we're doing trainings right now, we'll have to accommodate that part also in terms of working with government network operators and things like that. We have the same pressure. We've seen the same pressure due to v4 exhaustion, just like other regions. So people coming into our region to set up shop because they want v4 addresses.
And hiring talent is a little bit of an issue. Mauritius is a great place. AFRINIC is headquartered in Mauritius, but for our African people it's like really far away from everything. So people don't like coming to Mauritius. So hiring people is a bit of a challenge. These are the numbers of our last event in Lusaka, so the African Internet Summit. We had 407 people coming from basically everywhere. This is the next one. AFRINIC19 is in Côte d'Ivoire, West Africa. And this is it. Thank you very much.
Vint Cerf: I just wanted to report that I really had a remarkable visit with AFRINIC in Mauritius, a team of very energetic people. And Adiel Akplogan, who runs the operation, is equally energetic and very, very determined to do everything possible to help Africa become increasingly connected. One area of real interest to me was Internet exchange points in order to encourage more networking connectivity on continent so we don't have things leaving the continent and coming back just to interconnect different parts of Africa. I wanted to reinforce the sense that AFRINIC is a very vibrant part of our community.
Anne‑Rachel Inne: Thanks, Vint.
John Curran: Any questions for Anne‑Rachel?
Dan Alexander: You mentioned in your slide because of v4 depletion you're starting to see people trying to get resources from AFRINIC. Have you seen ‑‑ we just had the conversation this morning about people trying to game the system or coming up with creative ways to get resources from ARIN. Are you seeing that uptick in AFRINIC as well?
Anne‑Rachel Inne: It's really the exact same thing we're seeing, yes, people trying to game the system. So we have policies that say, for example, to have IP addresses from AFRINIC you have to be established in the region to have legal presence. Right now there are two places where you can get legal presence in three hours, Mauritius and Curacoa. So basically they do that, and the next thing is then you have to demonstrate that about 80 percent of the space is going to stay in region.
Yeah, as we talked about this morning, how do you make sure that happens if somebody just says, for example, they're going into a datacenter in Johannesburg or Cape Town and they have all their infrastructure there, and they kind of show you that, yeah, most of what I'm going to do is going to be here, but you know that in the back it's not, really.
Dan Alexander: Interesting to see that others are having a similar problem.
Anne‑Rachel Inne: We are.
John Curran: Anything else for Anne? Thank you very much.
John Curran: We'll proceed to our next report, and that will be APNIC with Paul Wilson. Yes, very good.
Paul Wilson: Good afternoon, everyone. I'm Paul Wilson, the head of APNIC. Very nice to be here. An update from APNIC. I've been given a lot of slides. Too many for the slot, so I'll try and race through these and trust you all to bring me back to anything interesting that I race through too fast.
APNIC just recently has revamped our vision and our mission. The vision is for global, open, stable, and secure Internet that serves the entire Asia‑Pacific community.
And what we do is we report according to our vision and our mission and according to a number of areas of activity that we've organized and identified, which are serving our members, supporting Internet development in the Asia‑Pacific region, collaborating with the Internet community and our internal corporate infrastructure.
All of this comes out of our vision and our mission, and all of that comes from actually the bylaws under which APNIC was established in the first place a good 20 years ago.
We've done some work also on this kind of trendy info graphic as they call it, which is a picture of APNIC's position in the ecosystem. That multicolored circle in the middle represents those three things ‑‑ our members, the region, and the globe ‑‑ and we sit inside this ecosystem at the top left, which is Internet users in the middle surrounded by service providers surrounded by enablers, and we regard, in our view of the world, the Regional Internet Registries as part of that enabling structure.
It's a useful way to describe to people outside of our region, outside of our community what we think we look like. And you can drill down a bit further. You probably can't see the fine print there, but it's all on the diagram in terms of how we break all that down. The mission has got several different aspects to it: Being an RIR to a high level of quality, providing training, supporting infrastructure, providing leadership and advocacy and facilitating regional Internet development.
I'll mention we don't put Internet governance in there because I think actually Internet governance is what ‑‑ is everything that we do in a sense. APNIC fulfills one particular slot of the Internet governance framework globally, which is as the Regional Internet Registry. And everything else we do supports that and supports different aspects of ARIN interactions with the community. So we're just part of the Internet governance scenario. It's not that we can split off what is and isn't Internet governance in what we do.
So under this area of serving APNIC members, I've got a few things to mention here about our resources and membership and services update. On IPv4, to start with, there are two different IPv4 activities these days. One is to continue delegating IPv4 under the last /8 policy. And what this shows is the monthly rate of those delegations. They're up to a /22 maximum per organization but as small as a /24 if someone can't justify the need for the full /22. We're doing, as you see there, say 150 a month, round figures, ongoing. And with the whole /8 available to us, that's going to last for another 20 years or so at this rate. So the idea, of course, is not to run out of this. This space is there to support v6 transition primarily.
The second thing we do with IPv4 is to support address transfers. So we now have fully operationalized intra‑ and inter‑RIR transfers. The only people we play with on the intra‑RIR side is, of course, ARIN, and we're looking forward to other RIRs willing to play with us as well in the near future, I hope.
The way transfers work is that we do assess the need. We assess the need that is of the recipient. We assess the need in exactly the same way as we used to assess the need for an IPv4 allocation. What we give if the member comes along in advance is we give them what we call preapproval for a transfer that they can then go out and get.
So the preapproval lasts for a year, and if they then go out and find a willing source for the address space within region or outside of the region, then we've already given them the approval for up to a certain amount of space and we can process the transfer quite quickly.
Other aspects of that, we've got quite a few sets of supporting structures. We recognize and deal with address brokers providing they will sign a practice statement with us and providing they'll also sign up as an APNIC member. The reason they sign up as a member, from our point of view, is they indemnify APNIC against legal action in connection in any way with their activities, which is quite useful, I think you'd agree.
We log all the transfers, Mailing List for people to match up with each other. We also have a listing service, an opt‑in anonymous listing service for the pre-approvals we've made. I think if you go to the APNIC website you can see the URL there. You'll see 20 or 30, I think at last count, pre-approvals; that if you've got address space, you could get in touch with those people who have approval for that transfer and make a deal.
We do charge transfer fees, which are equal to 20 percent of the transferred block's annual fee. That is our annual fee is set according to the address space holdings of the member, and so we do the assessment for the annual fee on the basis of the block and charge 20 percent.
Inter‑RIR transfers. We've completed ten or so, 11 so far, all with ARIN. I think all but one in our direction and one from us to ARIN. We've successfully completed those transfers in one or two weeks each. We've successfully transferred a live network. That's not such a big achievement these days, but it will be when there's live RPKI going at the same time. We've got ‑‑ just a note there is that the ARIN and APNIC Whois and stats can overlap for a transfer block for about a day after the transfer due to the time zone difference. That's the way it works at the moment.
We call these market transfers as opposed to what we call administrative transfers, which happen when you have a merger and acquisition, something along those lines. So the stats here show about six to eight per month being processed at the moment. You can see all the details in the public log if you're interested to see where those addresses have come from, where they've gone to in terms of country codes, what specific addresses are involved so on.
We're doing a fair amount of tracking of transfer patents. For instance, if there have been allocations made by APNIC followed by a transfer of the same address space or if there's attempts to do multiple transfers of addresses. On to IPv6. Not much to say here. We're continuing to make allocations. They've slowed down a bit since the peak in 2010, but it's still something that we do regularly. Likewise, ASNs, the chart here shows 2‑byte, 16‑bit, and 4‑byte 32‑bit ASNs, and so far total we've allocated about 1500 4‑byte 32‑bit ASNs, that is.
We do have a system where if someone who doesn't like their 4‑byte number can come back and try and get a 2‑byte instead. That's always possible. So we presume that these numbers are out there either in use or being prepared to be put in use.
Membership growth. Contrary to expectations, membership growth is accelerating now. It's accelerating because people are coming directly to us to receive their small final /8s blocks. They're being turned away from their upstream ISPs who will no longer give them address space. I guess that was predictable. You can see a sort of fairly clear exponential path going on there.
News on Whois. We deployed some new functionality for geolocation and language attributes on Number Resource records. We will also have WhoWas functionality, that is the historical functionality, deployed as soon as we get the historical data into the database before the end of this year. We've also got a test bed pilot for RDAP, the outcome of the WEIRDS working group at IETF.
This all is based on the RIPE Whois server, of course, and we've been working with RIPE NCC. We contributed the code for RDAP to ‑‑ into the ‑‑ into the RIPE code base.
And we have achieved something else this year, which is to go through the laborious process of ISO 9001 certification. We received that earlier this year without too much headache, actually. We've always taken a very systematic view of APNIC processes to make them as predictable, as robust, and as quality oriented as possible. So it was really for us a matter of documenting those processes and getting them expressed in the form that the ISO people expected. And we got top marks, too, which was nice to see. I'll wait for John to call for a round of applause for that.
Paul Wilson: No need, no need. Moving on. Supporting Internet development in the region. We put policy development under here, and I'll spend most of this section, short section, on policy development. A few things, which have changed. We have implemented policies which are known as clarifying demonstrated needs requirements in IPv4 transfer policies which actually was the ability for a transfer to satisfy 24‑month need instead of a 12‑month need. We've removed the multi‑homing requirement for IPv6 portable assignments. Those two have both been implemented as of earlier this year.
The consensus decisions made at the last meeting in August were for the establishment of a new pool of returned addresses for returned IPv4 address blocks, sitting in a new pool which will be made available as a second sort of final /8 allocation to people who have already received one. We'll be running multiple pools and allowing some people, when they qualify, to receive a second /22.
There is now an agreement on AS number transfers, intra and interregional, and also some changes to the comment period on our Policy Development Process. These reached consensus in August. They've got a two‑month comment period, and they'll be implemented pretty soon after that period is over.
We have a couple of activities in the Internet development area, which are small grants and awards for Internet‑related R&D projects. We've received some pretty substantial funding from this region, actually, from IDRC in Canada for something that's called ISIF Asia, the Information Society Innovation Fund. We've put out about 1.2 million to 38 projects in 17 economies of the region. We've been doing that for a while. And it's expanded in the last year to something called the Seed Alliance, which is a joint project involving APNIC, AFRINIC, and LACNIC, with three similar regional small grant projects. We received another one and a half million from SIDA, the Swedish International Development Agency, to support that over three years.
The conferences which happened recently, I listed here, we had Singapore earlier this season and China just last month. And the meeting in China was our opportunity to celebrate APNIC's 20th birthday, which was a lot of fun, for those of you who knew about that. The third point: Collaborating with the Internet community. We've got a lot of work going on under collaboration under Geoff Huston's management at APNIC Labs. I won't go into this because I think most have seen it and I don't have time in any case. And Geoff's the guy to talk.
But we've been doing the very comprehensive IPv6 measurements and have extended that process to DNSSEC as well. So visit labs.apnic.net and you can see all the info about that. Also on the external side, we've got a lot of stuff going on in external relations involving governments and intergovernmental organizations, which we refer to as public affairs. So, again, I won't go into all of this.
We might describe this as Internet governance. But I prefer to call it just the normal but accelerated level of outreach and engagement that we actually need to do with a pretty broad community of people of interest, people who are interested in APNIC that is, to make sure that people understand the work we do, the work we all do, understand the Internet technical community generally as much as they can.
One thing that is under the Internet governance banner is the IGF itself. We've all been engaged in the IGF for the last eight years. And for APNIC this year it's quite significant because they have the IGF in our region, in Bali, in Indonesia, which is quite close to home and obviously a central point for being in our region for the regional Internet governance community for coming together. Bali is quite a nice place. If any of you can be there a week after next, you'll find IGF happening there at the same time.
And you're also invited to three coming APNIC meetings. We've got 37 in Bangkok next year with APRICOT, and number 38 in Noumea, New Caledonia, nice place. And August next year with the dates to be announced. We have APNIC 39 in Japan, which is a joint meeting with APRICOT and with APAN, Asia Pacific Regional Academic Networking Organization. You're all invited to those meetings and to ask any questions now or later. Thanks.
Leo Vegoda: Leo Vegoda from ICANN. Congratulations on the certification. I have a question about the WhoWas. How far back are you planning to make the history available, and are there any conditions for regular folks off the street to just get the information, restrictions, that kind of thing?
Paul Wilson: We are going all the way through our Whois transaction log files. At least ten years. I was hoping we'd go right to the beginning of RWhois installation, but I think some of that early data is lost. It's at least a year's worth. As I'm aware there has never been any call or suggestion there should be restrictions on access. This was all public data at the time. And I think the general practice is that data, which has been public, can still be regarded as public data. So it will all be available.
Leo Vegoda: Thank you very much.
Kevin Blumberg: Kevin Blumberg, The Wire, AC. You mentioned if an Org wants to come back with a 4‑byte, you're happy to give a 2‑byte to them. Is that in policy or just practice, the first part of it? Second part, is that because you currently today have 2‑bytes still left and will that still apply if there wasn't 2‑byte?
Paul Wilson: Second question, first, no, we couldn't replace with a 2‑byte if we had nothing left. At some point we might start a more energetic reclamation process in our region, because there would an opportunity to receive more 2‑bytes later but obviously we can only provide what we have on hand.
It's not exactly a no‑questions asked to replace a 4‑byte with a 2‑byte. But if someone comes back with a reasonable case that they can't deal with a 4‑byte at the moment, we'll replace it. It's not in policy. It's just a practice we've adopted.
Milton Mueller: A question about your statistics on the transfer process. As you know, we did a study of that. And we had real trouble with APNIC statistics because you did not distinguish originally between market transfers an unmarket transfers. So I understand now your statistics are systematically separating out these internal corporate transfers from market transfers.
Paul Wilson: To be honest, I don't know. I wasn't aware of that particular issue, I'm afraid.
Milton Mueller: I thought you were responding to our study in which we pointed this out. And I was going to take credit for that. But I guess we ‑‑
Paul Wilson: Good try.
Milton Mueller: But you're clear it's separated from the internal ‑‑
Paul Wilson: No, we are reporting ‑‑ internally we're tracking and we're reporting the difference between a market transfer and a normal administrative transfer. But to be honest, what we're including ‑‑ the transfer log, the policy ‑‑ the transfer log included the transfers taking place under that policy, as I understood it.
Milton Mueller: Good show if you're doing that. If you're not ‑‑
Paul Wilson: I'll take a look.
Milton Mueller: Thanks.
John Curran: Thank you, Paul. Thank you very much.
John Curran: We'll continue with the Internet Registry Reports with LACNIC and Elisa.
Elisa Peirano: Hi everyone. I'm Elisa Peirano. I work as a resource analyst at LACNIC. I'll present the update for our region. The topics will include membership and resources update; IPv4 and IPv6 allocation and assignment; resource certification; Frida program; Ayitic; Certiv6; and finally previous and upcoming meetings.
As for membership update, until the first of October, LACNIC had 3,212 members. As you can see in the chart, we've grown 433 since last year. Mostly in the small micro ISPs. Currently LACNIC is responsible for the registry allocation and assignment of 11.13 /8s. You can see the use of this space in the graph. We've estimated 233 days until we reach the last /10. And when the pool reaches the last /11 we will switch to policies related to the accession of IPv4.
In this slide you can see the number of IPv4 plus IPv6 allocations and assignments from the period of October 2012 to September 2013. Regarding IPv4 resources, the first graph shows how much of a /8 we've consumed for the last year. And the second graph shows the accumulated consumption of a /8 in the same period.
Full LACNIC members, 1,847, have IPv6 allocated or assigned, which represents a 57.5 percent of the total. In 2012 we've allocated or assigned 578. And until now we've allocated 461. As far as resource certification for full IPv4 addresses assigned or allocated: The graph on the ‑‑ sorry. The graph on the left shows the number of prefixes assigned and the graph on the right shows the percentage of IPv4 space covered by ROAs and takes into account the announced space.
In order to raise awareness about resource certification we've helped the community in carrying out workshops which we explained RPKI and how does it work. From the 3rd to the 5th of September we were in Ecuador working with NAP.ec members. And before the event only 15 prefixes were signed and after the event there were 277 prefixes signed. And since then more certifications have been made.
And I think almost all the resources of NAP.ec were certified. Now we'll talk about different projects we're involved in. First up is the Frida program. The Regional Fund for Digital Innovation in the Latin America and the Caribbean is dedicated to contributing to the development of the Information Society in our region.
There are three sides to Frida: The award calls, which recognize and reward different approaches in the use of the ICTs. And then the grant calls, which provides small grants to promote research. And I think this year's grants finished close on the 30th of September and now the projects are being evaluated. And the last side is the escalating projects, which are meant to empower successful initiatives.
Frida is a proud member of the SEED alliance, as Paul was saying before. The next project is Ayitic, a program specifically designed for Haiti and geared toward the country's needs. It seeks to directly contribute to building capacity for Haitian technicians and professionals in the field of ICTs. This year's workshop was held in Port‑au‑Prince from 12th through the 16th of August, with very satisfying results. 100 Haitians attended the workshop, which was more than we expected. And LACNIC developed a survey for professionals and students to know more what were the interests of the community. This is a picture taken during the workshop.
The newest of our projects is Certiv6. Based on ten years of experience, training, developing ideas and putting together material for IPv6 deployment in our region, LACNIC develops Certiv6. It's a methodology that certifies that a certain software application runs properly over IPv6. It was launched in Uruguay the 16th of April and then in Colombia and Argentina the 10th of May and 4th of September. You are more than welcome to visit the website, shown in the slide.
Finally, as for previous meetings: In May, LACNIC 19 was held in Medellin, Colombia back to back with LACTLD. And three policy proposals were discussed and one reached consensus, which referred to modifying the requirements for ASO nominees.
Mr. Jorge Villa was elected a member of ASO. On October the 28th, the 20th LACNIC meeting in Curacao, back to back with LACNOG.
And we had great speakers and tutorials, IPv6, DNSSEC, RPKI security and more. And five policies are to be discussed: To eliminate the use of the term dial up, to publish information on reassigned IP addresses, blocks via STP; the principles governing the distribution of number resources; the adapting the allocation assignment policy of IPv4 exhaustion. And I forgot the inter‑IPv4 address transfers. And that's it. Do you have any questions?
John Curran: Thank you.
Vint Cerf: First of all, thank you for another comprehensive report. One question that occurs to me: In the Caribbean, the islands are variously connected, and the responsibility for managing IP address allocation in the area is shared by ARIN and LACNIC. Is there a potential for working together, and maybe I just don't know about it, to improve development of Internet access in the region? Is there a collaborative activity that ARIN and LACNIC are both engaged in? I should know this but I don't know the answer.
Elisa Peirano: Unfortunately, not that I know of either, for now.
Vint Cerf: Thank you. That's something I will undertake to pursue. Thank you.
Aaron Hughes: Aaron Hughes, ARIN Board. On the RPKI training you had in September, looks like it was a very successful prefix count increase. Would you mind sharing the number of organizations that generated the 250 prefixes?
Elisa Peirano: The number of organizations, I don't have it right now. I have to check my computer and maybe later I can show you.
Aaron Hughes: Okay. Just curious if it's like close to one or close to 100, so we know how successful training might apply in this region.
Bill Darte: Bill Darte, ARIN AC. Thank you for a good presentation, for all the good work you're doing in your region, and particularly for the initiatives you're doing in Haiti. I think that's wonderful.
Albert Daniels: Albert Daniels from ICANN, with responsibility for the Caribbean. Perhaps I can make a comment with respect to Vint's question about the responsibility for the Caribbean territories being shipped between LACNIC and ARIN. This is part of the reason why I'm here. And yesterday I had some good meetings with the ARIN staff to try to understand a lot of the history and I got some interesting stories. But the objectives are pretty similar; the problems are the same.
So while there may not be any structured framework for collaboration, the two organizations, based on what I've seen so far, tend to work very well together. And even though the region is split between the two, there's a lot of collaboration with regard to capacity building, for example, both LACNIC and ARIN present at capacity building events. And also there's collaboration with other organizations like ICANN and ISOC. Hopefully that will increase.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I've actually been privileged to work with both ARIN and LACNIC in the Caribbean region at various events. LACNIC has sponsored me to come to one of their events in Haiti. And I was able to join LACNIC for LACNIC in the Caribbean that was held in Aruba just recently because I was down there with ARIN for the CANTO conference. And there is a lot of cross‑pollination and cooperation that occurs even though there isn't any structured collaboration that I'm aware of. And I think the two organizations have been working well together. And I hope it continues.
John Curran: Thank you. Any other questions? Thank you.
John Curran: Now Andrew will come up and give the RIPE report.
Andrew De La Haye: Good afternoon. My name is Andrew De La Haye. I'm the COO at RIPE NCC. I only have 12 slides, and it will be a quick one. Right. So how is our membership doing? We currently have nine and a half thousand members. And we still see an increase. They come from 76 countries all around.
Steady growth. Even after runout, which happened a year ago, almost. We do see an increase in diversity. The nontraditional ISPs becoming members of ours. And that means that we have to give them the feeling that they're part of the system as well. And we're doing our utmost to make them feel part of it and explain them the bottom‑up process we're operating under
We're promoting the RIPE Policy Development Process a lot. For example, if someone comes in for a first allocation, a /22, as we have them now in the last /8 policy, we give them a call and we explain to them the whole system and how the model works, to make sure they feel comfortable with how we operate. Still, it's a challenge keeping all members engaged with the PDP.
We have seen lots of growth over the last couple of years from Russia, mainly, in the membership. And that changed back to Western Europe, where we see the UK and Germany as one of the growing economies or membership areas where we see growth. Russia's still growing but slightly less.
We do have to adapt to our membership needs, especially with the range of new players. And it's difficult to sometimes interact with them, as they also show to have less time than we're used to look at the process and participate. But, again, we're trying to do our utmost to make them part of the system and explain to them how they can participate.
We are also adapting our services towards these new players. And what I already mentioned, we're trying to change the way we interact with them by giving them a call, being more open to their comments as well. And we're, for example, implementing live chat functionalities towards our customer service department. But also for RS, for certain questions that we're receiving. And that's a lower threshold for people to get in contact with us.
Additionally to that, we see an increase in regional presence. That means that we have an office in Dubai, where Paul Rendek is currently working. We'll be hiring somebody from the Middle East who speaks the local language, and we're also hiring somebody in Russia who speaks Russian to make sure that we're able to reach out to all those areas where we see growth coming from.
IPv4 status: Runout was 14th of September 2012. A bit more than a year ago. Went orderly in our region. Of course we saw a bit of a spike in requests. But everything went very smoothly. And currently we're applying RIPE last /8 policy. And out of that /8, we had about 2500 allocations of /22s, which means we have about 14,000 /22s left. And if you would extrapolate that, that would be for another six to seven years to go.
Interestingly enough, people in our region thought that the ticket volume would go down especially in registration services after runout, but we've actually seen an increase in ticket lot. That increase comes from a particular project as well called 2007‑01. It started in 2007. That was getting contracts for OPIE in our region. There are about 30,000. There's a long project, and we're hoping to finalize it Q1 next year.
Out of this project, all these PI holders, of course we now have contracts for them, but it also means that we are getting a lot of changes in those contracts. Something we didn't foresee. But it's about 500 tickets a month. We're working on.
V6: Still going strong, about 100 allocations per month. And it's going slowly down, and it's maybe because 65 percent of our membership already received an IPv6 allocation. Assisted Registry Check is renaming of some of our services we provided. We have audits and additional allocation review. So if somebody would come to us for an additional allocation, we do a certain review of the quality of their data in the database and registration information.
And as we don't see them coming back as much as we did, the LIRs, we wanted to keep up the quality of the registry. What we're going to do is to contact all the LIRs every three years probably as we see foresee it now at 9,000 members, give them an overview how we perceive them. For example, looking at all kinds of RDNS, root object inconsistencies or consistencies. But we also look at registration data thoroughly. And we're in that case helping them to keep the quality of the registry up to date.
RPKI, continued development in the area of RPKI: Our main focus for 2014 will be more resiliency of the system and making sure the system works fine. We have about 1600 members with certificates, which is about 15 percent of our membership. And out of that 1600 members, we see about 1400 ROAs that were created or organizations that created ROAs which is a bit of an extra step, and it really shows people are really interested in the system and model as it is.
We did have some policy issues, especially in the field of legacy address, certifying those, and PI, certifying PI holders. But it seems that there's currently a policy that will reach consensus soon on serving the non‑member‑related addresses. Certification was a member service. And we'll now start certifying those as well.
RIPE Labs: Lots of highlights there. We share statistics per country at the moment. It's based on our Atlas information and the RIPE study information. We're still extending Atlas. I think we have about 6,000 or maybe closer to 7,000 users and about 2,000 probes around the globe, which make the measurements very available. In addition to that, we're trying to be more transparent in the projects we run. For example, we have the RIPE NCC roadmap that shows in certain projects that have high value where we are and what the next stages of development will be.
More services being implemented: IP Analyzer, surface supporting members' address management. RIPE stats, as I already mentioned. I will urge you to go to the website, have a look there. Our database offer was rewritten. It's open source and it's on Github. It's very easy to set up yourself and run your own instance at the moment. And we implemented the protocol and that's what we did together with APNIC, just like Paul mentioned.
The year to come: We had a very positive members survey. And based on that survey we still think we can improve on many areas, and we're currently defining and formulating certain action points. The action points, just very high level, will be an increase into registry accuracy. There's currently a legacy proposal in our region which would allow us to properly register legacy addresses and help manage them, and that would be an increase of the registry quality as well, if that goes through.
We're trying to do more measurements. Lots of Internet governance or outreach, as Paul Wilson just mentioned.
Regional outreach and presence, the office in Dubai and Moscow. And we'll also be replacing all kinds of internal systems that have been very old and need additional and new development. And we're trying to increase transparency and engagement for all of our services towards the new people that are coming to RIPE NCC for services. And that's it. Any questions.
John Curran: Any questions?
John Curran: Moving right along, we'll go into the ARIN Board, Advisory Council, and NRO Number Council election procedures.
Jud Lewis: Hey, everybody. How's it going? Hey, yeah. I like that. So we have a very exciting ‑‑ I think it's exciting. I've been working for a while, me and the rest of the ARIN staff, of a new way to vote, which I'm about to demo to you right now. It's going to be easier. I'm going to share it with you. It just opened up at 5:00 P.M. eastern time, or 2:00 P.M. Arizona time. Here we go.
So what's new? We've got some new stuff. We've got a new election system, like I just mentioned. Now you only have to have one password to remember and that's your ARIN Online password. There's no longer a separate password needed for the election system, which is nice. Yes.
Jud Lewis: They're now more streamlined. Basically all three elections are closing at the same time. A little simpler. And the eligibility cutoff for voters was moved earlier from 14 days to 60 days before the election. Here's the little details: If you are in this room and you've registered for either the NANOG or the ARIN meeting by the 3rd of October, you were able to vote in the NRO NC election. The link to do so went directly to your email on the 7th of October. And you have until ten days from today to cast that vote. Like I mentioned, the other election for the Board of Trustees and the ARIN Advisory Council that opened up on ‑‑ just now.
If you're an eligible DMR, you have received an email with instructions of how to log in and cast your vote, a process I'll soon detail. So, Jud, what makes a DMR eligible? Well, to be an eligible voter, you need to meet these three requirements: You need to be from an ARIN member organization as of the 12th of August.
Your DMR email that we have on file has to be affiliated with your organization's doing business as or domain name, and it needs to be a personal email. No roll accounts. And you need to be in good standing. You have no overdue invoices. Here's a little calendar. Monday, NRO Election opened up for Attendees. Today, voting for the Board, AC and NRO is open for the DMRs.
Tomorrow, the wonderful speeches you're about to witness from these candidates will be posted on line. Ten days later, at 5:00 P.M. eastern time, voting closes.
And later that week, no later than the 27th, we will be posting the results of these elections to ARIN Online. So make sure you're subscribed to arin-announce so you can get that message.
Let me show it to you. You can follow along, play along at home if you're a designated representative. Here, you may have seen this website: arin.net. To vote, you have to log in. Let me backtrack a little bit. There's two methods you'll be able to log in and access your ballot as a DMR. You'll fall into one of two categories. You're going to have an ARIN Online account already, or you don't have an ARIN Online account.
What I'll show you right now is how to log in if you do have an ARIN Online account. You go to arin.net and provide your log‑in information right there. And then after logging in, you're going to proceed to Election Headquarters, at www.arin.net/public/election. And after logging in on this page, if you're eligible to vote, you'll see a "vote now" button. If you're not the eligible DMR, note you're not going to see this vote now button. Click on that. And then you'll be able to access your ballot. I'll show you the ballot in one sec.
Here's the other way to vote. You have been emailed already an email. If you don't have an ARIN Online account, you'll see this email and open the mail. At the bottom you'll have a unique link. Click on that link and here comes your ballot. And your ballot is going to look like this. First off, you'll be able to vote for the Board of Trustees election. There are the candidates. If you click on their names, interestingly, you'll be able to read their entire bio and see their picture as well.
You'll select up to two candidates for the Board. Click submit vote. Then you're going to progress to the Advisory Council election and select up to five candidates. Click submit vote. Next comes last but not least the NRO NC election. You can select up to one candidate for the NRO NC election and click submit vote. And then you're done. You're going to see this thank you for voting screen. If you want, you can click on that little link right there to view your voting receipts. Or alternately and automatically you'll be emailed your voting receipt directly.
Your voting receipt will look like that. It will be emailed to you upon voting, in like about 30 seconds. Now there are some people in this room and on the Web that are listening in that will be able to vote on behalf of more than one ARIN member organization.
What I'm going to mention right now is only applicable to you. You are able to cast ‑‑ instead of having to vote for all of your organizations separately, there's a way you'll be able to cast all those votes at once if you so choose. So let's say in this example here I'm able to vote for six member organizations.
And if I want to vote for all six, there's nothing really special I have to do. I can leave the set the weight field to as it is. And default is six. Just vote just like I showed you in the previous slides. I will have cast all six votes for my six membership organizations the same way for all six. But let's say that I work for, in this example here, I work for, like I said, six organizations and I want to cast three of my votes for Devon Gayle and then three of my votes for Jason Schiller.
This is how you do it: You reduce the vote rate number to three. Default was six. And then I'm going to select the candidate. I'm going to select Jason here. Then I'm going to click "submit vote." I've just submitted three votes. And after clicking "submit," the screen will reappear. With the ‑‑ and you're going to repeat the process. You're going to have three unused vote weights. You put in the three.
And then I'm going to select my other candidate, Devon Gayle. And then I have successfully split my vote. Detailed instructions on how to do that will be on the bottom of that email as well. That's how you do that. And that's the new voting with process. Any questions?
Scott Leibrand: The NRO election was open to attendees and also open to DMRs. If you're both an attendee and DMR, should you vote twice?
Jud Lewis: Well, you shouldn't be able to. That's a great question, Scott. There's no double dipping allowed. So if you are an attendee and also a DMR, you can only vote as DMR not as an attendee, you shouldn't have received an email with the link.
Scott Leibrand: I did receive an email for the link and I did vote for the NRO NC election already. May have been a different address, who knows. But theoretically I shouldn't vote both ways. So I shouldn't vote as a DMR if I already voted.
Jud Lewis: Correct.
John Curran: We're going to double‑check that, but you should do the right thing and we'll double‑check to make sure of that.
Jud Lewis: We'll talk about afterwards at the election help desk. By the way, if you have questions for me, I'll be out there for the remainder of the meeting. Come up and talk, and I can walk you through the process and answer any questions you have. Any other questions?
Jud Lewis: I'll turn it over to John who will introduce the candidates.
John Curran: We're moving into candidates for election. First up are the NRO NC nominees. So we have Devon Gayle, who is not in attendance, but I have a statement. I'd like to read the statement.
"I'm a strong advocate for the advancement of technology for humanity. Therefore, serving on the NRO Number Council would provide me with an opportunity to bring passionate support and dedication in assisting with ensuring that the Internet continue to grow and develop for the benefit of humanity globally. This goal I would be able to achieve while providing visibility and bringing focus to Jamaica and the Caribbean region as a valuable member of the global Internet community."
Okay. Our second candidate is Jason Schiller. And, Jason, if you would like to come up.
Jason Schiller: Good afternoon. I'm Jason Schiller. For those that don't know me, I'll tell you a little bit about myself. At my core, I'm a network engineer. And I bring level‑headed operations and engineering mentality to everything I do. When it comes to problem solving, I generally want to solve problems on their technical merits. I'm currently with Google, which rounds out my experience to include CDN, ISP, enterprise, LAN/WAN.
My current position with Google is in net ops doing production and backbone network engineering, which ranges from carrying a pager being on call, to doing emergency BGP traffic engineering, turning up peers, to architecting, designing, implementing and supporting new networks. For example, one of the projects I worked on recently was providing the live stream of the Olympics for YouTube.
I've also, in the last year, have been doing the numbers administration. So I'm the chief numberista there. Prior to that, I was at UUNET for over 13 years where I did network architecture, engineering and design. I've done a number of projects from re-architecting the BGP design to deploying the multicast network in the Latin America networks.
Before that I was in high speed install in a customer‑facing world turning up 56K leased lines all the way up to OC3s.
I also have some enterprise experience. I worked at Manor Care, which had 230 remote nursing facilities and ran their WAN, as well as Georgetown University and American University and the Georgetown University Medical Center. I've been serving for the last two terms on the NRO NC, which performs the function of the ASO AC., I've served on the ASO AC nominating committee. There my goal was to craft difficult questions that were tailored to the perceived weaknesses of the candidates and let them either confirm our suspicions or correct our understanding of their capabilities.
I've also served on a number of global policy facilitator teams and have written multiple reports to the ICANN Board. I've been attending ARIN meetings since April of 2005, ARIN 15. I have been an active participant and go back and look through the minutes.
I've definitely been involved. I speak at the microphone and from time to time do show up on PPML. I've authored a number of proposals. And I've also helped others to write proposals that are well formed.
I'm also happy to tell you I've been involved in getting Google to sponsor the remote participation, and happy to note that we're doing an experiment streaming live to YouTube. So hopefully more of that to come in the future. I've also been an attendee of NANOG and involved in BCOP. I'd like to thank you all for your time. Thank you to the community for giving me an opportunity to serve on the NRO NC. And also thank you for being involved and participating and making this bottom‑up process work. Thanks for your consideration.
John Curran: Bios are on the website for the NRO NC candidates. Okay. Next up are the members of the ‑‑ candidates ‑‑ nominees for the Advisory Council. We have seven nominees. And the first one up is Cathy Aronson.
Cathy Aronson: If you asked me three years ago if I would be standing up here running again, I probably would have said no. But here I am. I've been on the AC since 1998, maybe. And I thought maybe we would be done with v6 now and the policies would be settled out and there wouldn't be a lot of work left to do. But I think that there is.
So I'm running again, because I feel that we need to go through the policy manual and look at all the policies with respect to runout and the transfer market. And I don't know, it just seems never ending. Anyway, I would appreciate your vote. And that's all I have to say, I guess. Thanks.
John Curran: Owen DeLong.
Owen DeLong: In case someone in the room doesn't yet know me. I'm Owen DeLong. I'm with Hurricane Electric. I'm an IPv6 evangelist. And I've also been on the Advisory Council for six years now. So I'm running for a third term. When I first started running for the AC, I was focused on helping us get through the IPv6 transition, the runout of IPv4 addresses and I still am.
I think there's still work to do. Although I think we've accomplished a lot along the way. I was instrumental in developing both the current IPv6 end‑user and the current IPv6 ISP allocation policies, which I think have helped enable IPv6 development in our region quite a bit. And I want to continue working on that. I hope you'll give me the opportunity to do so. I also want to take a little bit of my time to talk about the Board election.
There's a candidate from the Caribbean running, Bernadette Lewis. And I would like to strongly encourage you all to elect her to the Board. I think it's vital that we get some representation from the Caribbean on our Board. I think Bernadette is one of the most qualified, brightest and most friendly, useful, capable candidates I could imagine electing to the Board. Thank you.
John Curran: Next up, Andrew Dul.
Andrew Dul: Good afternoon. I'm Andrew Dul and I'm running for the Advisory Council this year. A number of years ago I did serve on the Advisory Council for three years and have continued to serve the ARIN community since then. It's been a fun and exciting journey as over the past ten years worrying about how IPv6 is going to turn out. I think the question we all should be asking ourselves during almost all these meetings is: Is this the right way to IPv6?
Everything we do in this meeting with regard to policy and other discussions, we need to continue to ask ourselves this question, because that's the future of our organization, of the Internet as a whole. And I would just like to remind people of that today. So that's one of the reasons why I'm running this year on the Advisory Council is to continue the work and point the way to IPv6.
There's a URL at the bottom of the screen. If you have any questions about what I think about things, I encourage you to go there. It's a blog I've been writing for about two years now on IP address allocations and things, and I thank you very much for your vote. And thank you.
John Curran: Next Advisory Council candidate is Jesse Geddis. And he's not here. His flight is delayed. We'll see if we can get him in front of you at the appropriate time. Next up, Scott Leibrand.
Scott Leibrand: I'm Scott Leibrand. I'm running for re‑election to the Advisory Council. As we've already here there's some work remaining to be done. In my last six years on the AC, I feel like I've been one of the best AC members there is. I have a little bit of a big head, but hopefully you guys can help me deflate that one appropriately. I believe I've facilitated consensus on a number of important issues, helped craft policy that has gone into effect and has had good effect. I believe there's still some work to be done with regards to policies that need to change as we hit IPv4 runout. I'd like to continue to work on those.
I'd encourage those of you who are not DMRs, which I imagine is the majority of the people in this room, please go to the election website at ARIN and submit statements of support for all the candidates that you think are best to represent you as a community member. This election is done by the members, but it really should represent the community. So your input to the DMRs as to whom they should vote for is very valuable.
I would encourage you to go write statements of support. And DMRs, I would encourage you to go read those statements of support as you decide whom to vote for in in this and the other elections. Thank you.
John Curran: And next up for the Advisory Council, nominee Tina Morris.
Tina Morris: Hello. I'm Tina Morris. For those that don't know me, I have some relevant experience as a network engineer. Everything from the US Navy, small mom‑and‑pop businesses, medium, privately‑owned companies, and now I work for an ISP.
In my current role at BrightHouse, I do IP strategy, public/private v6 and v4. I draw up all the allocations internally. Deal with law enforcement requests and end‑users; our customers when they need to make a request and they need help with ARIN.
I've been active with the ARIN community for the last four years. I follow PPML. I find the community‑driven process is really interesting and it often changes my opinion on topics, when I hear it from every aspect. I have a well‑rounded background. I'd like to participate in the advisory committee and I think I would have a good perspective. Thank you.
John Curran: Next nominee for the Advisory Council, Milton Mueller.
Milton Mueller: Hello, everybody. Are you still all awake? So I've been on the Advisory Council for a year now. I filled a slot through a resignation. And I think this is a slot reserved for the wild and crazy people who cause trouble on the Advisory Council.
And I think you should maintain that slot. I have broad exposure to the Internet governance environment. And I think that's valuable for ARIN.
Obviously we don't rule on all these issues, but I do know what's going on in telecommunications policy generally. I know more than I care to admit about what's going on in the ICANN. I participated in the global Internet Governance Forum from its inception. I participated in ITU, the World Summit on Information and Society and so on.
I do it from the perspective of somebody who specializes in the study of communications and information policy, not just the technology.
So I'm a big supporter of non‑state governance, despite what some people in ARIN may think when I make them uncomfortable; I really, really strongly support the idea of independent private sector‑based non‑state governance, and I want to preserve that system. So I'm the new guy on the AC. I think a real three‑year term would be productive. They need the wild and crazy libertarian guy whose first concern is the impact of policies on the users and their autonomy and freedom and rights.
You'll frequently find me on the losing side of AC votes, if you look at the record, the transcript. I'm not worried about that. I think the AC needs alternate voices, and that's one way you can keep one on there.
John Curran: We'd like to move on to the Board of Trustees. And before I actually bring up the nominees for the Board of Trustees, I'd like to bring someone whose name is not on the list as a nominee for election. Our current trustee, Paul Vixie, if you could come up ‑‑ Paul has opted not to run, so I'd like to give him a few words.
Paul Vixie: Thank you. I'm done. Nine years is long enough. I have some thanks to hand out. I thank those of you who voted for me. I think that I have done what you thought I would do. I'm a fixer. The organization has gotten less broken in it now than it did nine years ago. And in that sense my job here is done. I'm very happy with the current leadership, with the organization. The Board s good. The AC is good. The structure is good. The bylaws are fine. You don't need me now.
So as to some thanks. Scott's not here, but I will forever view Board minutes differently as a result of following him as secretary. I do it better now. I want to thank John. And this is kind of interesting ‑‑ there is an annual party that we do with Steve Ryan, where he sits us down and reads us the rules and says this is what a Board member does and does not do. And there's a slide that's in his presentation, which I've now seen eight times, that describes two duties, the duty of loyalty and the duty of care that a Board member has.
And my thoughts upon hearing that, the first time, hearing the description of what is the duty of care, what is the duty of loyalty, is, John, you did not need me on this Board.
At the moment that John and Scott and a bunch of other people founded an organization whose job was to build and then sustain this critical function of the ‑‑ I guess it's the human digital nervous system, you had me on your side. I was undertaking the duty of loyalty and duty of care to this mission long before I came here, and I will continue to do that. Call me anytime.
Just because I'm not here doesn't mean I'm not doing the same thing that you're doing. So thank you, John, for that. I want to read two things. This is not a customary thing. It's very rare for a trustee to recommend a vote for other trustees. It happens from time to time. Since I'm now beyond the reach of the law, I'm going to abuse my position. It's very rare that I will say something about somebody that I wouldn't be willing to say to their face.
So, Vint, since you're a gentleman, you're not going to read your own candidate page, you're not going to find out what I said about you unless I read it here. Working with Vint has been the thrill of a lifetime. He's even better than his reputation. And he provides solid luminary leadership everywhere he goes for ARIN. I urge and request that the voting members return him to the Board for a second term. I still miss John Postel, but Vint is the next best thing.
Here's what I said about Bernadette. I said that she's a voice of intelligent rationality, not just for the Caribbean, but for the ARIN region and also for the Internet's way of doing things. She's one of us who, luckily for us, is highly regarded by the govies and bellheads. She already represents our goals and principles. She already fights our fights. Seating her on our Board is the only logical thing to do. And I could not have asked for a more uplifting successor as I leave the Board after three terms.
John Curran: Thank you.
John Curran: Thank you, Paul. I point out, we still have Paul's wisdom between now and the end of the year. We have the benefit of having him on the Board. And now we need to talk about whom we shall elect to assume the new seats. I'll bring up the Board of Trustee nominees. The first is Dr. Vint Cerf.
Vint Cerf: First of all, let me say I did not influence Paul's comments but I'm deeply touched by them. Let me begin by observing that every Board should have an Internet dinosaur on it. And I certainly qualify. If for no other reason ‑‑ it's the fact that I'm a talking dinosaur that makes it so amazing. Doesn't matter what I say, the fact that I can still talk is truly incredible.
What has turned out to be valuable, though, quite honestly especially as we get into this IPv4 runout period where there's a lot of tension, a lot of monetization efforts and things of that kind, is that having a knowledge of history and the ability to speak to it has turned out to be useful. And since I don't think we're through this period yet, it strikes me as something important to pay attention to and something that I would like very much to continue to serve.
I also believe it's vitally important that we reinforce trust in the Internet ecosystem. And of the various pieces of that system, the RIRs and ARIN have earned a great deal of trust in the community. And my job, in part, if you put me back on the Board, is to continue to reinforce that trust. We are still, as everyone else has said, in this period of IPv4 runout and this period of not adequate uptake in the use of IPv6. So I think we need to continue to focus our efforts on that. Generally speaking, increasing the security and the resilience of the IP allocation and use system is very important.
The biggest challenge I think before all of us who are part of this governance ecosystem is specifically how Internet governance will work going forward. The events of the recent past months have increased the levels of tension, have increased attention among governments to want to exert more governance over the Internet. This is not necessarily a good thing for any of us, either personally or for our businesses. And I think we and ARIN need to contribute strongly to reinforce the multistakeholder model. So I hope you'll see fit to put me back on the Board. If you do, I will serve with all the vigor I have available.
And I look forward to that. If not, I still thank you for putting me on the Board for three years, a period of time that I've felt honored to participate and contribute. Thank you.
John Curran: Next candidate up, David Huberman.
David Huberman: Hello, everyone. I'm David Huberman. I've been participating in ARIN since 1999. I've done so as a member of the community, Telocity and Global Crossing, and now Microsoft. A lot of you are looking at me because you know I've more prominently served ARIN as a member of the staff for more than ten years.
I left the organization this summer when I was presented an opportunity to be part of Vijay Gill's team at Microsoft. It was an opportunity I didn't want to say no to. It was something I believed very strongly in. It was professional growth for me, so I said yes. But the problem is: I have an enormous amount of passion for ARIN. And I believe in every fiber of my being in ARIN's mission and what ARIN does.
I look around the room today, and I'm seeing a lot of people who I've spent the last ten years helping. I've bent over backwards to help a lot of you get your goals accomplished with ARIN with as little bureaucracy and as little hassle as possible. And I hope I've served you well. And in thinking about it this summer, I decided I'm not ready to stop serving. And so I stand before you today, and I'm asking for your vote because as a member of the Board of Trustees, there are a couple of directions I'd like to lead ARIN towards.
One of those is from top to bottom ARIN needs a laser‑like focus on the customer experience. We cannot afford over the next five years to have people, new folks, new players come to ARIN and have to spend months climbing the very steep learning curve and learn how to effectively deal with ARIN. Indeed, it's ARIN who needs to effectively learn how to deal with their customers. And a lot of those new folks are coming from the transfer market, which brings me to my second point.
The truth, my friends, is ARIN is not today and has never been properly set up to facilitate transfers. In a world of IPv4 exhaustion, the bulk of the day‑to‑day work at ARIN is going to focus on transfers, 8.2, 8.3, 8.4. As a member of the Board, I would work with my fellow Board members to set the strategic direction and provide the strategic objectives to the ARIN staff to reshape ARIN completely to bring a completely new approach to transfers: Its attitude, its tools, processes and procedures, and its staff.
When you as a network operator, with your lawyer and broker, you can come to say ARIN and say, hi, ARIN, I'd like to transfer this address block to this company.
ARIN needs to be in a position to say yes as often as it can, and do so in a matter of hours or days, not the weeks and months that it takes today. I bring a very unique set of skills and experience to this candidate for Board of Trustees. Leverage me. Use me. Leverage the knowledge I have, the experience, the passion and the leadership that I can bring to set ARIN up for success in 2014 and beyond so that later on we can look at ARIN and continue to say what we say today, which is it is the best registry in the world. Thank you.
John Curran: The next Board of Trustees candidate is Bernadette Lewis. And Bernadette is unable to be here. So I will take an opportunity to read a brief statement. Her bio:
"In August 2003, I was appointed as the Secretary General of the Caribbean Telecommunications Union. My early work was dedicated to revitalizing the organization and transforming it into a multistakeholder relevant and vibrant ICT organization and putting it at the forefront of regional activities to harmonize policies and practices for the development of the Caribbean ICT sector. In 2005, under my direction, the Caribbean achieved a worldwide first by initiating a regional multistakeholder Internet Governance Forum. The Caribbean IGF has since met annually, and one of the major achievements being the promulgation of the Caribbean Internet Governance Policy Framework."
"The CTO successfully implemented many of the policies in the framework. One of the more significant being the proliferation of Internet exchange points in the Caribbean. I believe that the development of ICTs and the Internet is a collective responsibility. Therefore, since 2005, the CTO has worked in strategic partnerships with many Internet‑related organizations. Of particular importance is the CTO's partnership with ARIN with which it has a cooperation agreement. The two organizations have come together to further the growth and the effective use of the Internet and its resources in the Caribbean. In 2012, the Latin America and Caribbean Internet Registry, LACNIC, conferred on me an outstanding achievement award for my efforts towards developing Internet in the region."
That's from Bernadette. Thank you. Final candidate, Bill Sandiford.
Bill Sandiford: Good afternoon, everyone. I'm cognizantly aware that as the last person to speak today, I'm probably the one keeping you from your break. So I'll try to keep this speech to 30 minutes or less.
Bill Sandiford: I've been involved with the ARIN community for a number of years now, five years, I believe. I'm very passionate about the work that ARIN does and the multistakeholder model and how it's used throughout the world and throughout Internet governance. I have much experience in this regard. I'm involved with other organizations, both as Board members and on committees similar to the work I've done on the Advisory Council over the past four years.
And I think that I have a well‑rounded skill set, both figuratively and literally, that I would be able to bring to the Board and exercise some of my passions there to the benefit of the organization. One of the things I wanted to add, in closing, is that a lot of people have asked me recently: Why is it that you want to move from the Advisory Council to the Board. You don't like the work there? I can assure you that's not the case.
In fact, working with my colleagues on the Advisory Council over the past four and a half bit years has been one of the most rewarding experiences of my life. Prior to getting involved with ARIN, I hadn't been exposed to this sort of a model, the bottoms‑up organization based around community involvement. And it's been thoroughly rewarding. And just like I got an opportunity four years ago to come into the Advisory Council because there was other people that were moving on to other challenges, either inside the ARIN organization or beyond, it's sort of one of my motivations as well too.
I listened and I took a look at all the candidates for the Advisory Council and there's obviously a lot of good choices there with some incumbents that are running. But we know that we're going to have at least one new body on the Advisory Council this year, and I knew that if I am successful in obtaining your votes, for the Board, then it would give opportunity for another person to bring some new fresh blood into the organization.
Which helps with things like member engagement, et cetera, and I think that's really important that the organization continues to evolve and opens its arm to new people.
So with that, I'll just say it's been a pleasure working with everybody and I hope to continue to do that. And I'm asking for your vote.
John Curran: Thank you.
John Curran: Okay. That concludes the candidates, and we're going to take a short break. Elections are opening momentarily. Ask Jud outside if you have any questions.
We'll resume our normal schedule with one minor change. We'll take a break, come back promptly at 3:30, and we'll start the final policy block of the day. After which we'll hear some reports from the NRO Number Council and then Open Policy Hour. So see everyone back here at 3:30. Be prompt, the ice cream is out there melting, I believe.
John Curran: With less people, it's easier to do a show of hands for the policy. Actually, proper order requires discussion of the topic before I move it. But it's tempting.
Everyone, come on in. Okay. Everyone welcome back. We're going to resume. This is our second policy block. We're going to have a discussion of Draft Policy 2013‑7. The policy is Merge IPv4 ISP and End‑user Requirements.
John Curran: The origin of the proposal is 190 in July 2013. The AC shepherds: Scott Leibrand and Bill Sandiford. Let's go back one just in case. It was accepted as a Draft Policy in August. The policy is online and in your Discussion Guide. From the problem statement for the policy: The proposal attempts to reconcile the differences in requirements for obtaining PA, provider assigned, and PI, provider‑independent, IPv4 address resources.
There's a similar proposal at RIPE. RIPE Proposal 2013‑6 PA/PI unification for IPv6 address space. For IPv6, this proposal removes the difference between PI and PA, suballocation and assignment. Comment: I support the general direction of this proposal. If it included IPv4 I would be in favor. That is over at the RIPE region.
This is a work in progress. It's still being developed by the AC and posted to the PPML and presented for community discussion. Their goal is get it to fair and impartial number resource administration. Technically sound and supported by the community.
Staff legal assessment will be performed upon request of the AC when the draft is in what they consider a fully developed form.
Recent PPML discussion. A unified set of requirements is a big step in the right direction and should simplify things. So that concludes the staff introduction for Draft Policy 2013‑7. I'd now like to bring up the Advisory Council to present the Advisory Council discussion. Scott.
Scott Leibrand: I am not the AC. I'm Scott. All right. Don't have a laptop here. We've got a clicker. All right. So as we just discussed, there is some situations with regard to ISP and end‑user definitions that have resulted in a number of organizations desiring to qualify for address space as either an ISP or an end‑user when they may be somewhere in between and they have a decided interest in which one they want to qualify as because the requirements are different.
So that brought up the question: Should the requirements be as different as they are? There's also quite a bit of complexity in the NRPM, as you guys may have noticed trying to read it probably not reading the whole thing. And some of that may be unnecessary.
In addition, the other reason that we're working in this space is there are a number of requirements with regard to who can get space, how much they can get and what they need to use before they can come back for more that may not make any sense in a post‑IPv4 depletion world.
Some of those are addressed in this policy proposal. And as a whole what we're trying to do with this policy proposal is to simplify things in a way that consolidates the requirements to be as similar as they can between ISPs and end‑users, but without eliminating distinctions where they still matter.
So this involves quite a bit of text. There are quite a few changes that would be required to make this work. But it is also limited in the number of things that it tries to address.
So if you ask the question why doesn't this touch on v6, well, that would be yet more things we would need to change and more moving pieces makes for more difficulty in gaining consensus.
This is a Draft Policy. It is not a Recommended Draft Policy. It is not going to Last Call after this meeting. The PDP doesn't allow it to. The AC doesn't feel it's ready. We brought it to this meeting as a Draft Policy because we want to get community feedback on what it is that we should be doing. What it is you want us to do: Is simplification a good thing? Is consolidation of requirements, harmonizing requirements a good thing? Are there some things that we need to do to make things easier to qualify for space to work better in a post‑depletion world where all IPv4 requests have to be filled by a transfer?
This is a brief table that summarizes some of the things that are changing. I'm going to go over it a little bit here now but I'm going to try not to focus on it as much as at the NANOG policy consultation. As you can see here, there are some changes to the minimum initial allocation and assignment values. This is the smallest block that you're allowed to receive from ARIN. It's not a maximum of any sort. It's a minimum. So currently that minimum is a /20 for single-homed in both cases.
It's a /24 for multi‑homed end‑users. /22 for multi‑homed ISPs. This would change that to /22 for single-homed and /24 for multi‑homed. There's a little bit of a substantive change for single-homed and there's consolidating down to /24 for both ISPs and end‑users for multi‑homed. It would also change some of the utilization requirements for initial requests. Currently end‑users have to have 25 percent immediate utilization, 50 percent within a year; whereas, ISPs do something separately different.
They have to fully utilize a single home /20 from a provider. Or, if they're multi‑homed, use 50 percent of previous assignments. So this would simply say that the initial block needs to show that it would be 80 percent utilized within three months. So that's one of those things where it's an attempt to not only harmonize but also to address some of the concerns about being able to get space from an ISP upstream that you then use and then you renumber out of when you get your own space.
Subsequent requests: Consolidating those to be similar with regard to most recent versus all assignments. The timeframe for looking at usage justification for subsequent requests: This would change that to be 12 months across the board. Currently it's three months for ISPs, 12 months for end‑users and 24 months for ISPs for transfer.
So I'm not going to hold that slide up there, because I don't want you to focus on the details as much as I want to get feedback for the AC on some broader questions, which are: Do you like the idea of simplifying and consolidating policy between ISPs and end‑users?
Are there any specific requirements that you think are important to harmonize in a certain way or to set in a certain way? Are there specific distinctions that you think should remain? And another discussion item that came up in discussions today at the lunch table, is which of these things and which other things do you think need to be looked at especially with regard to this issue of being able to get IP addresses in a post‑depletion world via a transfer.
This attempts to address some of them. I believe there are other issues this doesn't address. And part of the feedback that the AC needs is whether or not it's going to be, at the end, part of this policy or not, and which aspects does the community feel are important for us to be working on: How have you seen problems when you try to apply for space where it's pretty obvious that this particular requirement is a problem now and it's going to get worse if you have to get your space from a transfer market as opposed to going back to ARIN.
We'll open it up for discussion. As I step down I'll leave it on another slide that summarizes some of the changes in this policy, and you can think about some of those as we go forward and then we'll move it back to the big question as well.
Vint Cerf: So before I bring people online, let me just make an observation about this. It strikes me that someone has an opportunity to write a new poem called how many ways can you use an IP address. You know, remember how do I love thee, let me count the ways. The number of ways in which IP addresses can be used is really evolving over time. So some of the models we had before don't feel like they quite fit anymore.
Let me take first the question from the center microphone and then I'll take one from the right.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I support having a policy that seeks to address the gaps that exist between current policy and the ability for new entrants and existing entrants to cope with a world where they can't get a previous allocation from an upstream before coming to ARIN.
While that's a tiny piece of what this policy seeks to do, the vast majority of the rest of this policy seeks to do a whole lot of rearranging of all of the furniture below decks on the Titanic that is IPv4, and I don't support that. Let's stop rearranging the furniture. Let's look at the post‑depletion policies that are needed for IPv4, since it is very unlikely this policy could go anywhere near into effect prior to ARIN's IPv4 runout by any significant margin.
And let's build a policy that addresses just those things, simply and easily as possible, and move on. I don't think it's worth spending a whole lot of effort trying to gain consensus and getting wrapped around the axle on where to put the sofas and dinettes and the rocking chairs in the v4 world. v4 is done. Get over it. It's time to move on.
Vint Cerf: Thank you very much. From the right‑hand microphone, please.
Matt Pounsett: Matt Pounsett, Afilias. I agree with Owen. A lot of what this is doing seems like things that are not really a significant change. And there are others that I don't really understand the reason behind. For example, changing the additional request timeframe. We made that three months in order to smooth out runout. Now that we're down to the last 15 months or so, I don't understand why we would suddenly reverse that.
Some of the other things, yeah, they might make things a little cleaner in the document, a little easier to read, make a little bit more sense to people, but like Owen says, I'm not sure it actually has any substantial effect at this point. There are probably other things we can be working on.
Vint Cerf: From the center microphone now.
Leif Sawyer: Leif Sawyer, GCI. I'm mostly in support of this proposal because anything that helps ease the allocation of IPv4 space is a good thing. I'm a little concerned about the three months at 80 percent timeframe. That seems very quick and a lot. A lot of address space to show assignment for smaller ISPs or TPIA, like for the Canadian. So I think that's something that should be looked at.
Vint Cerf: And again from the center microphone.
Matt Petach: Matt Petach, Yahoo, reversing my objection to things. I actually support this policy draft. I like the notion of cleaning things up. I've demonstrated how easily confused I am by the existing NRPM at my earlier moments at the microphone. So simplifying things, awesome idea. I think echoing one of the earlier comments about the three‑year time period that may be a bit aggressive but I think this is a thrust in the right direction and wholeheartedly agree with the sentiment.
Vint Cerf: From the head table.
Dan Alexander: To reply to ‑‑ Dan Alexander, ARIN AC. To reply to the three‑month 80 percent rule. If you look at what that requirement is on in regards to an initial allocation, not a subsequent allocation. And if you look at, say, the existing end‑user policy as it is, if you're a single homed end‑user and you have to, in order to qualify for a minimum allocation of a /20, you have to be able to immediately utilize 25 percent of that, which is essentially a /22, which is what the proposed change would be. So you're actually going from having to meet a bar of justifying a /20 and immediately utilizing all of a /22 to going to be able to justify a /22 and be able to use it to 80 percent.
Vint Cerf: Thank you for that clarification. From the center microphone now.
Mike Joseph: Mike Joseph, Google. I urge everyone to turn to page nine in their Policy Guide, because there are 16 bullet points here that describe the content of this policy.
Now, that slide, that chart that was just up there is certainly nice. But this is what we're being asked to vote on. Omnibus policies of this nature are almost impossible to vote on because no one can understand the scope of these changes. So let's talk about some of the changes that this policy purports to implement under the guise of simplification.
It removes parity between v4 and v6. So it eliminates the distinction. A distinction that's important if you hold both v4 and v6 resources because now you have to figure out are you an LIR when you pay your bill or are you an end-site.
It eviscerates the basis for initial allocation. If this policy is adopted, initial allocation becomes based solely on forward‑looking projections. It complicates requests that are based on future allocations. And it takes the worst of both worlds when you look at the size of minimum allocations and assignments. Quite frankly, this is the kind of policy that is meant to be split up. This is a wholesale rewrite of everything in section four. That's not easily undertaken and it's not something that we should do in a single Draft Policy.
This is something begging to be split into incremental changes as we do with all policy development. I know that when this policy was presented, we were told that we shouldn't complain about there being lack of v6 parity because it would just make this overlaid policy even longer. But there's no reason you can't have v6 parity with this by splitting it into two reasonable sized chunks that you implement both v4 and v6 at each stage. So I strongly oppose this policy as written.
Vint Cerf: Thank you very much. Again, from the center microphone now.
Chris Tacit: Chris Tacit for TekSavvy Solutions. The main concern we have is the allocation change from three months to one year, whether that would in any way restrict coming back for more IP addresses if the forecast proves incorrect and we run out more quickly within the year. It wasn't clear to me that that was looked after; and if it that's true we would oppose this policy on that basis. So can anybody provide clarification on that?
Dan Alexander: I'm sorry, could you say that again?
Chris Tacit: The concern we have is the change from the three months to one year and whether if somebody's forecast turns out to be incorrect and they need more before the year's out, how difficult would it be to get a subsequent allocation?
Dan Alexander: It's the same as the policy that currently exists. The timeframes are the timeframes that you can gauge your previous ‑‑ use your previous growth to gauge what you can justify in a future allocation. Whether you're currently under the existing policy, whether you're an end‑user or an ISP, if you beautifully utilize your allocation prior to that projected timeframe, you can request another or obtain another through transfer. So it's not ‑‑ even under the policies as they currently are, it's not a timeframe in which you're only allowed to ask for or justify an allocation; it's just a gauge to use in what you can justify for your request.
Chris Tacit: So that's not changing at all?
Dan Alexander: Correct.
Chris Tacit: The question then becomes as we get close to the bitter end if there will be enough available that you can get a year's worth as opposed to perhaps getting another one‑ or two‑ three‑month segment. Has there been thought given to that issue?
Dan Alexander: The three‑ to 12‑month timeframe, really at question here is just what existing ISPs would currently ask for. The 12‑month timeframe actually already exists on the end‑user policy. It's actually no change. Whether or not it would dramatically change the runout date, I don't have projections on that. But the one reason these things were written also as well is, even if there's still a free pool, this also applies to not so much as transfers because the transfers are actually at 24 months. But I don't have any data as far as when the free pool would run out, if it would run out any faster.
Chris Tacit: I would urge you to consider perhaps looking at a three‑month rule for both rather than a one‑year rule for both. It just doesn't seem to make sense with runout to go the longer route rather than the shorter. If you had to pick to harmonize, pick the three months, not the 12 months.
Dan Alexander: Which is actually very valuable feedback. I just went in the direction of the least painful change. If it's changing end‑users to three months and we all went to three, that's a completely appropriate parameter.
Chris Tacit: Thank you very much.
Vint Cerf: Thank you very much. Let's take a question now from the right‑hand microphone, please.
John Springer: John Springer, Inland Telephone, ARIN AC. Speaking for myself. I'd like to comment on the context again of this. This is an outgrowth of some policy experience comments at Barbados about the ambiguities in the current policy between the definitions of an end‑user LIR ISP. We took an earlier run at it that went on the rocks; and I'm in favor of working this problem. The situation as it is today, the status quo is either somewhere between broken or suboptimal.
So as we shoot these policies down for varying reasons, we're going to still be left with something that is less than desirable. So I do support the effort. And we couldn't really do carve‑outs for end‑users versus LIRs. This is ‑‑ it's a broad approach. But I applaud the effort to be sure not to take away from the formerly arguably privileged state end‑user and to sweeten the pot for everyone involved. So I support the effort.
Vint Cerf: Jason.
Jason Schiller: Jason Schiller, Google. I oppose as written. On the topic of the general question, do you agree with the idea of this policy and is doing simplification a good idea? Generally I say yes. I'm not in the camp of trying to radically simplify IPv4 policy because IPv4 is done. So I don't agree with that. I do agree in general if we can simplify things and streamline things, especially in the case that some organizations fall in the middle between an ISP and an end site, I think that's a good thing.
However, I think this policy makes a lot of changes. It's very hard actually to read the policy proposal. And I appreciate whoever decided to include the red‑lined version. That's very helpful. Thank you. There's a lot of text moving around and a lot of text has gotten dropped. Slow start no longer exists. That is a big deal. I don't know how ARIN can deal with an organization that's new that claims to have future need with no history to back it up on. Furthermore, I don't know how ARIN can deal with an existing organization that suddenly has a new exponential run rate, because, say, they're offering a new product or service.
It seems to be that your next task can be based solely on a projection of what you're going to need in the future. And I don't see any way to really substantiate that. And that's very frightening to me. There's not a lot of guidance for ARIN's staff to determine whether there's real need here or not. The other thing that concerns me a lot is the move back to 12 months for ISPs. I was opposed to changing it to six months when we did it because I felt like so close to the end of the game, you shouldn't be changing the rules.
And people are depending upon when runout is going to happen in terms of deploying their transition strategies and v6 adoption strategies. For the same reason, I oppose changing it back. We can't be changing it so close to depletion. People need certainty.
There are a number of other things that have changed. The need ‑‑ ISPs need to SWIP for /29 or larger is gone now. As far as I can, tell there's no requirement ‑‑ you're shaking your head. As far as I can see, the text has been deleted and not reinstilled anywhere, based upon the way the policy is written.
Paul Anderson: I'll reply later. Keep on going.
Jason Schiller: The section that talks about how web hosters qualify for additional space which I admit was vague is now completely gone. Seems like we moved from a vague recommendation for how to measure need to not at all. So I think this leaves a lot up to ARIN staff interpretation, and it could be based solely on future projections, which is frightening to me because I've seen how some product managers have put together future projections. They're not necessarily founded in anything real. So I oppose it as written. But in terms of the general questions, I certainly support the effort and think we should keep trying.
Vint Cerf: Thank you, Jason. Did you want to respond?
Dan Alexander: No. Stay here. This is really good conversation. The reason I was shaking ‑‑ Dan Alexander, ARIN AC.
The reason I was shaking my head is one of the things ‑‑ the way the intent of this text, the intent of the policy, was not to eliminate the distinction between end‑users and ISPs.
It was only to eliminate and merge the criteria by which network operators obtained resources. So the focus was only on the sections that laid out the criteria by which people get resources.
The requirements around what they do with them once they have them are all still intact and none of that text was actually changed. So all the reporting requirements, the Whois requirements, the distinctions between utilization from the end‑users or ISPs, those sections of the policy manual weren't changed.
Scott Leibrand: I can be very specific on that. 4.2.3 is the section that has everything about Whois. If you look at the slide here, 4.2.3 is not being removed, rewritten or anything else.
Dan Alexander: Another comment about the 12 months and three months, it was a starting point. I'd be curious of your impression. If we put ‑‑ if we made that three months or six months for everybody where end‑users were brought down to where ISPs were, is that a more favorable situation versus bringing everybody up to where end‑users currently are?
Jason Schiller: If it's going to change I would recommend we change it to one quarter, which is what it is now for ISPs. But I think changing it at all is a bad plan. People are depending upon what the values are currently set, and I don't see a really good reason for why we need to go and tamper with what the values currently are. So my recommendation would be to leave it as a year for an end-site and a quarter for an ISP.
The other text that I thought had gone missing was the demonstration of multihoming guidelines. I'm again working off the red‑lined version, which might not be exactly accurate to the bullets up there on the slide, but I can check that as well.
Dan Alexander: The bullets are misleading, because it's just a very high level list of the changes. The red‑lined would be a more accurate concept of what we're talking about. Because while it says it eliminates the section slow start, the concepts are still there because you still have the similar requirements around ‑‑
Jason Schiller: Where in the NRPM are the concepts of slow start when the section gets removed?
Dan Alexander: Let me ask you. When you think of slow start, from my end it's you ‑‑ your initial requirements for your initial allocation are a little different than your subsequent allocations, and the initial ones are based on what you're currently using from your upstream, not based on future projections.
Jason Schiller: No, but as an ISP, I can be slow started and start with, I think it's a /22, and if I come back in less than a quarter, I can get a /21. If I come back in less than a quarter, I can get a /20, and I can keep doubling like this as long as my growth continues to be exponential.
Dan Alexander: Wouldn't that apply under existing policy?
Jason Schiller: That exists because of the slow start policy from what I understand, which seems to be stricken. Can staff maybe help us out here?
John Curran: Specifically, I was following it but which interpretation?
Jason Schiller: As an ISP, with no history, asking for a /22, using that in less than a quarter and coming back and getting a /21, using that in less than a quarter and coming back and getting a /20, and continuing to do this to double my allocation so long as my growth continues to be exponential; is that the slow start policy that allows me to do this?
John Curran: Yes, the slow start policy that says ‑‑ it's the slow start policy that provides, excuse me, that provides the initial size that you get, regardless of what you claim your actual need is. So you say I need a /20, we say you're a new ISP, you're going to start with a /22 or whatever the criteria is, depending on whether you're multi‑homed. Slow start says you start with something small, you quickly utilize it and you come back; but you don't have to worry about what they can come back for, because it's qualified by the sum of the total blocks. Oh, you're saying how much more –
Jason Schiller: If my growth is exponential, I never have a year's worth of history to justify what I'm going to use in my next quarter.
John Curran: You have to do the math, but you could end up going faster than presently allowed. If you eliminate an explicit slow start policy and you were exponential, you could make a chain of request that could give you addresses faster than today, if that's the question. I have to go look to see how fast you'd have to do the request. But I think it's possible. Slow start limits you because of your history as well.
Jason Schiller: Right. If I'm a new ISP without a year's history and the slow start text is stricken, how would staff fulfill my request?
John Curran: Give me a moment.
Vint Cerf: Can we ‑‑ here we go. Could I make a suggestion, in order to move ahead, would you guys like to consult for a few minutes and I'll give you back after you come to a conclusion, if any. I'll take the question from the right‑hand microphone now, please.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I would be vehemently opposed to dropping end‑user to three months. There are a number of reasons. There are billing reasons. Every record for an end‑user would be done. These are organizations that come for significantly less space over time. That's just a very different model, and I would not feel comfortable with doing that. Overall, do I like the idea of simplification? Absolutely? Does this hit the mark? I don't think so. But I think this is a great example of a draft that needs some consistent work.
I believe, as a community, we have spent the last five years adding and adding and adding to a rock pile that is showing its age and is about to topple. What I would implore the author and the shepherds who are working on this policy is to forget about the next 12 months and to look at these policies after runout. Slow start was a great example. I'll call it no start. If you're an ISP and you are coming to ARIN and you can't get any space from your upstream to begin with, slow start becomes no start, and we really have to come up with something. This might not be the policy to do it but something else might be there.
But v4 is going to be around. This is not about rearranging deck chairs. This is about simplifying the transfer market once we have run out. Just keeping it as simple for everybody. So that ARIN staff don't lose more hair, don't get grayer, and customers ‑‑ and customers have confidence that they will be able to get what they sufficiently need when they need it. Thank you.
Vint Cerf: Thank you. Owen.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Moving end‑users to three months would be devastatingly bad. Doing an ISP application for subsequent is a relatively trivial process that involves records an ISP has to keep anyway. I know I've done a number of them.
John is nodding his head because he's seen a few of them. Doing a subsequent assignment for an end‑user tends to be a bit more involved because the end‑user doesn't necessarily have all those records that we assume they keep if they are doing things right. And they don't necessarily know where everything exactly is right at the moment. And it often takes time to research those things.
Doing that once a year is tenable for most businesses of medium size. Doing that every three months would be invasive and potentially difficult and costly. And I don't think that it provides any benefit to the community for us to have ARIN processing four times as many requests for end‑users as they would otherwise have to process under the current regime. I don't think end‑users consume enough of the space compared to ISPs to warrant such a draconian measure either.
Vint Cerf: Let me take Bill all the way in the back there.
Bill Darte: Bill Darte, ARIN AC. So I have a hunch, based upon 15 years of policy development experience that suggests that when there's a show of hands relative to this Draft Policy, it's not going to bring in support. And taking up time in this meeting now to argue the details of a policy proposal that needs to get a lot of rework is not terribly productive. And then I'll encourage people to take their enthusiasm and passion for the topics and details of this to the Public Policy Mailing List or to a working group that would sit down and craft better language at another time.
Vint Cerf: Bill, that reminds me of the Postel solution to any kind of disagreement. He would send people away and say let me know when you figure it out. John, he's whacking my butt again.
John Curran: This goes back to Jason. If you remove the slow start by removing what would be just the slow start phrase, then we're indeterminate whether we're back to three months or 12 months. If you remove it, it tends up on how the action policy ends up being worded. The most likely outcome is we would end up, because we're past the final /8 IANA allocation, we're already in a three‑month window for ISPs. So when you say remove slow start, do you mean striking that out as well? Because it occurs twice. There's the less than a year slow start and there's the because we received the last /8 slow start for everyone.
Jason Schiller: No. No, not the last /8. Can we put the red‑lined version up, is that possible?
John Curran: Here's what I'm saying. Until we see the final text out of the AC, it's not worthy to try to do a staff assessment of text in this ‑‑
Jason Schiller: I'm comfortable moving something forward if ‑‑
John Curran: We're not moving anything forward. This policy can't be moved forward.
Scott Leibrand: Let me address your question in a general sense. Yes, we could ask them to put the PDF up. I would rather not. Here's why. I don't think we're at the position where we want to argue the details of this. As Bill said, what we're trying to get at is concepts and what direction we should be moving this and what aspects we should be working on.
The question I would ask with regard to slow start is what should the policy be after ARIN's free pool is exhausted around qualifying for space from ARIN that you then get on the transfer market and how many iterations of that should be required. So under current policy there will be a requirement that you get a small block from ARIN except you don't get it from ARIN, you get it from the transfer market.
You show you used that, then you go get another block from the transfer market. Most people I know who are in the position of getting space for their future needs are going to say why don't I just get a year, two years worth of space on the transfer market.
I think the question to the community is would we be in a bad place if we allowed businesses to do what they normally do when they're acquiring resources that they know they are going to need for their business and plan for more than a few months of their need.
So slow start is one of those things that works great. When you have a free pool and you can easily go back and get them the next tranche of the request, after you've proven that they'll actually use it. The question I'd ask you is what should the policy be in a post‑depletion world for transfers? Does slow start have a good place in that, or is there another mechanism that we should be using.
Jason Schiller: Jason Schiller, Google. We still have addresses in that free pool. This policy will impact how we draw down addresses from that free pool, if it was to pass before the free pool is empty. Because the implementation of this is immediate.
Scott Leibrand: It can't pass now because it's a draft policy not a recommended draft policy. It will go back for at least one more meeting. That's six months from now.
Jason Schiller: Well, it could be February.
Scott Leibrand: Could conceivably be February. As the shepherd, I'm telling you this is not likely going to happen within six months. I suspect that we are going to need to write this in a way that it addresses the post‑depletion world, not the pre‑depletion world. I would encourage you to think about this from a post‑depletion perspective, and we'll make sure that language doesn't mess things up pre‑depletion.
Jason Schiller: I appreciate it. I think slow start is important. It's important for new organizations that don't have a year's worth of history and important for organizations that suddenly have logarithmic growth that haven't leveled off for a year. Without slow start, you can't give them the right amount of addresses. I don't know how to make slow start work in the transfer market.
It seems ridiculous to say: Go and transfer a small chunk and then come and transfer double that, transfer double that, or go and find somebody's who got the size block you think you need in two years and have them hold it for you and get the first chunk of it and use it and come back and keep doing that until you've logarithmically chewed up the whole address space before the two‑year clock times out. I don't know how you can make slow start work in a transfer market. But I don't think that means we should throw it out from the existing free pool because it's valuable. We need to move in the other direction. We need to figure out how to make slow start work in the transfer market.
Vint Cerf: I would conclude from this exchange, a good piece of advice to the AC and to the shepherds is to look into this post‑runout period and try to identify the period during which the proposal would apply. I think those are the people who said this felt like rearranging deck chairs, were probably thinking about in terms of pre‑runout, which, as we all know, is coming with runout, it's coming pretty soon. I didn't mean to intervene.
Jason Schiller: The other question I would pose back to you, Scott, is how do you prevent abuse when giving someone a two‑year supply of addresses that is solely based on a projection of what they think they might need in two years. Because I might need a /8 for all of the computers that I'm buying at yard sales to put in my basement.
Scott Leibrand: That's fine. If you were to do that today pre‑runout, I would be worried about you getting addresses for free for these supposed computers.
If you have to pay money for the addresses and you're getting them via a transfer, there's still little bit of concern that you aren't doing some sort of speculation operation on the market. But that's a much different story.
Jason Schiller: Even if I'm not doing speculation, even if I swear to you I will never resell these addresses, what's preventing me from, say, stockpiling a ten‑year supply of addresses for my needs and claiming I'm going to use them in two years, how do you deal with that? Or is it just okay to not have justified need in the transfer market, is that what you're saying?
Dan Alexander: This is Dan, ARIN AC. That's not the intent. And it's obvious that slow start or this nuance of the difference between projections and historic is important, as you're pointing out. Future revisions to this document will have to accomplish something like that, and this is all very valuable feedback. So the gist or the essence of this conversation is that there's a question about projections versus historical data and we have to make sure that's incorporated into this draft.
Vint Cerf: I think that's pretty positive feedback. Thank you very much. Let me take a question now from the right‑hand side.
Matt Pounsett: Matt Pounsett from Afilias. I'm still opposed to this. But seems to me from some of the questions being asked and some of Dan's comments about the three‑month time period, there might be some missing or forgotten history. I thought I'd try to refresh people's memories. When we switched the ISP request timeframe from 12 months to six months to three, it wasn't done to change the runout date. It doesn't actually have any significant effect on the runout date. Might shift it a little bit by days or weeks. The idea was to smooth run out and create fairness in the last year or so of address assignment.
The issue that we're working around is the idea a very large ISP could come in and ask for a year of space and chew up the entire free pool in one request. By switching it to six months and then three months, it meant that those requests would come in for shorter timeframes and would allow other people to be able to also request address space in those time periods. Pre‑runout, that's still extremely important. Post‑runout, as you say, it's a different playing field. Doesn't matter so much when you're not worried about smoothing the free pool.
My suggestion would be, I think, if you want a policy proposal like this to move forward for post‑depletion world, then just make that the implementation date or make the implementation date dependent on ARIN's free pool runout. Good feedback. Thank you.
Michael Joseph: As I'm observing the rest of this debate, I notice there's such incredible confusion over the policy, we asked for red line and there was concern about putting the red line up. But given how confusing this policy really is to understand, I think that really reiterates the need to break this into chunks that are more meaningful.
I'd like to request of the Chair, when taking the poll of the room, ask not just for support or opposition to this policy, but whether we want to consider ‑‑ whether we want to advise the AC to consider developing a policy more incrementally, perhaps in four pieces or something along those lines, to implement a simplification of the assignment and allocation practices without doing a wholesale rewrite in one shot of all of section four. And I think that could be meaningful. So I'd like to request that the Chair consider doing so, when the vote is asked.
Vint Cerf: I would consider that. Although, I have a slightly different formulation which I hope would accomplish the same objective. You and I are in agreement that this is a rather large and complicated object that we're talking about. So I thank you for that input.
Mike Joseph: One more point. You previously admonished us to consider what policy objective, what problem we're trying to solve here. I don't think that's actually been clarified either. In particular, I've heard several different things. I've heard we want to simplify policy. But that in itself shouldn't really be a strong motivator. I also heard we more particularly want to deal with the circumstance, particularly on PPML. I've heard people complain that some organizations could be in a gray areas, whether end sites or ISPs.
Mostly today they self‑identify, and that actually seems to work fairly well. So before we rush into trying to develop such a complex and wholesale rewrite of this type of policy, I really think we need to better understand what the specific ‑‑ what the specific goals are. I mean, I see you put up the rationale. But I'm just not sure that what came out of this really addresses these specific rationale, and I'm actually not sure that all the items in the rationale are as problematic as people want to believe they are.
Scott Leibrand: Point taken. Thank you.
Vint Cerf: Do I have a response?
Dan Alexander: Dan Alexander, ARIN AC. To answer your question, there were really two primary motivations behind this. And I will very quickly point out I am not dead set on any of these points. And the genesis of this proposal was actually just a number of comments that were made on the Mailing List regarding several different issues. And it was pointed out that we need something to work off rather than just the generic discussion. So this was put together to try and facilitate that discussion. But the two things that this tried to focus on was, one, the policy gaps that we're talking about between dealing with this depleted world that it says in the rationale.
But the other one was there were comments made at the mic even today about the pile of rocks and how over the years the manual has evolved into this mountain because we just keep adding on to things. And then what struck me was this week was a very good example, because at the NANOG meeting you have 600 attendees and here at the ARIN meeting you have less than 100. And the recurring themes that we've always heard throughout the years is a lot of NANOG people don't like coming to ARIN meetings because we make things overly complicated and we always get into the weeds so far and we talk about all these little details.
And I'm not trying to dismiss them, because those details are extremely important. But sometimes we have to step back and say maybe we've got to look at this forest instead of all the little trees individually and see if we can't approach this differently. And this was the first shot at it.
Vint Cerf: One more comment from the head table.
John Sweeting: John Sweeting, ARIN AC. I just want to remind everybody that this is a Draft Policy, not a recommended draft. It will not go into Last Call from here. What we'll be looking for is guidance on whether to continue working on it. And, Mike, we hear your concerns of maybe, if we continue working on it, splitting it out into a couple of different proposals. Thank you.
Vint Cerf: I'm going to close any further questions from adding to the queue. But I'll take the three people who are now in queue. Let me take the right‑hand side again, please.
Scott Silzer: Scott Silzer, Afilias Canada, as well as Toronto Exchange. I agree with a number of changes suggested, but a number I might disagree with. It needs to be broken up. I think addressing the current situation, I don't know that there's enough time to do it. Addressing post‑runout, I think, is important. But doing it in a massive document like this, I don't agree, I don't think it's possible.
Vint Cerf: Center microphone.
Chris Tacit: Chris Tacit, TekSavvy. Having heard the problems that might arise for end‑users for the one‑year subsequent applications, I'll withdraw that comment that I made a bit earlier. But it does point out the fact that this is very complex, and I agree with those who suggest it needs to be broken up. It was difficult to digest all of it even with the red line and all the details. But I appreciate the work that's been done here and the intent. Thank you.
Vint Cerf: Jason, you seem to get the last word again.
Jason Schiller: Jason Schiller, Google. I want to apologize on the SWIP. After poring through the red line again, I noticed on page six of nine in Section 18.104.22.168.1 that SWIP does remain there. I think it now is under Section 4.2.8, which is about re‑assigning address space to customers. So I suspect if you're an end-site that has customers you would now be required to SWIP under this proposal. The other pieces of text, which I substantiated, have been deleted or dropped. I recommend we not drop those pieces.
John Curran: As is you'd be opposed to the policy?
Jason Schiller: Yeah, I think slow start is important. I think some of these other things that have gone missing, they're important and we should keep them. I oppose as written.
Vint Cerf: Thank you, Jason. This is another good example of being down in the weeds, 22.214.171.124.7.2. First of all, no jabber comments, right?
Stacy Hughes: No. I would have hit you in the butt.
Vint Cerf: You'll have to throw a spitball at me. This is going to become legendary: The only way to get Vint's attention is to slap his butt.
Vint Cerf: So let's do this: I want to find out, first of all, whether people feel this topic area needs to have continued attention, because the impression I have is that in fact there's a belief there is work to be done but it may not be achievable in current form.
Owen DeLong: I have to ask a clarifying question. Which of these dozen or so topic areas does this cover, do you mean by that?
Vint Cerf: Me?
Owen DeLong: When you say "should there be further work done on this topic area."
Vint Cerf: You have an object right now, which we've been debating, complex object, recommending all kinds of changes. It touches mostly on rules for the allocation and assignment of IP address space. And it does so in a very confusing way, because it addresses the ‑‑ without further clarification, it could address the period of time prior to runout. It could address the period of time after runout.
It makes an attempt to not distinguish between end‑user and LIRs or ISPs. It even raises, in my mind, a question about what policy would look like if we had no IPv4 address space at all and we were only leading on with IPv6, how would we treat these things. So one problem we have in this formulation is what time period does it apply and to what portion of the IP address space does the v4/v6 apply, should they be the same or different?
What I'm trying to suggest is, first, is there willingness to continue to work with either or small or all of the space that's been touched upon, or do you want to just ignore it. I don't believe that we would get an outcome that everybody just wants to ignore.
John Curran: May I make a suggestion or may I confer with the chair privately?
Vint Cerf: He doesn't want the Chair to express an opinion.
John Curran: Because we have a very flexible, very easy policy process that allows anyone to submit a policy proposal that handles any one piece of this. If anyone wants to work on a particular component, they can make that obvious by submitting a proposal on that one area.
The only real question is whether the AC should continue to attempt to work on this proposal. And they may break it up based on what they've heard or not. But the fact is a motion to continue work would have the AC continue. And if people thought that continuing on this thing wasn't productive, if it was abandoned, then they could submit policy proposals for the parts that they thought were important. So I don't know if we need to know if the scope is important. I think what we need to know is, is the current approach right or wrong; should the AC continue to work on this.
Vint Cerf: Well, with that clarification, John, would you propose that, unlike Mike was suggesting, would you propose that we ask, do you want to continue trying to operate with this tarball, or do you want to start over again with a slightly different maybe significantly different set of targets and rationale.
John Curran: Yes.
Vint Cerf: One way to vote on this is do we continue trying to deal with the existing text or do we restart?
John Curran: That would be the question that I would propose.
Vint Cerf: Mr. Joseph, if you don't mind, I'd like to ask that question. So let me pose the question: Do you wish to continue working, strongly, with this particular draft or would you like to ask the AC to essentially restart either by inviting other proposals or proposing some variation of splitting this up? We keep working on the tarball or we don't. If you vote in favor, you're asking to continue working on the tarball. I apologize if I pejoratively characterized it, but I think it's not inaccurate.
Scott Leibrand: As long as we geez up the tarball, it's going to be fine.
Vint Cerf: Those in favor of working with the tarball, raise your hand.
John Curran: Nice and high. If you're kneeling, I can't see you. Raise your hand.
Vint Cerf: You can see how the way in which you phrase questions have a dramatic impact on response. Every pollster in the world knows this. Are we good with that?
There's a hand in the back. I thought maybe you were just stretching. How many would rather not working on this particular tarball. Keep your hands up. Why do I feel like a criminal with a gun. Keep your hands up?
John Curran: Policy Proposal 13‑7. If you're raising your hand, your elbow should be above your head. Raise your elbow or lower your head accordingly.
Vint Cerf: We really need to find a faster way to do this. We're a bunch of geeks, we ought to be able to figure this out.
John Curran: There's some wonderful systems and we can look into them. One was demoed at APNIC using laptops and/or cell phones. It works very well.
Vint Cerf: Has the polling committee completed its work? Thank you very much. I think it's generally obvious what the conclusion is. We'll wait for the numbers. But to the AC, it sounds like re‑examining scope, rationale and focus will be a big help in this space.
Let's wait until we get the answer, then you can talk. Should the AC continue to work on this policy? Left out the tarball part. In favor, three. Against 45. With 126 people in the room. Advisory Council response.
John Sweeting: John Sweeting, ARIN AC. So I would like to ask the people that were in favor of this to please submit your proposals so we have something to work on and get the things fixed in this that you feel require fixing. Thank you.
John Curran: Excellent. Okay. That concludes our afternoon policy track. We're now going to catch up with the presentations that we didn't get to before the break. First, Jesse Geddis has arrived. Jesse, are you here? Jesse, come on up, Jesse. Jesse was delayed. So we didn't get to hear his candidacy speech. So come on up, Jesse. This is for the ARIN Advisory Council.
Jesse Geddis: Thank you for providing me an opportunity to address you today. My name is Jesse Geddis. Owner of LA Broadband and a candidate for Advisory Council.
Some may know me as the guy that started the recent discussion regarding ISP fees.
I want to thank those who have participated in the very lively debate that ensued. I included your thoughts in my proposal for the fee overhaul. That brings me to why I accepted this nomination. Throughout that three‑week very high traffic member debate, only two AC members participated. One constructively.
I think we can do better. When I was starting my company, the biggest hurdle wasn't funds or all the state regulations involved in starting a company. My biggest hurdle was getting address space. I want to work with you to find the solutions to these problems as well. To me, being a member of the Advisory Council isn't a bullet point on my resumé. I'm here to serve you.
I'm here to translate your thoughts and concerns into policy. If I'm elected, I will make it my priority to listen to you, to promote progress through ARIN's transition, to work to simplify policy and remove hurdles for businesses. And to be a strong advocate of IPv6 policy fees and in the business world. I'm asking for your votes and in return you'll have a person who will take the time to be involved, a person who will work productively both within our community and outside it. You will have a person with a passion for this. My name is Jesse Geddis and thank you for your time.
John Curran: There were two reports that we did not get to. One was the NRO Activities Report and the other one was the NRO Number Council Report. I'll ask Paul Wilson to come on up and give the NRO Activities Report.
Paul Wilson: Thanks, John. I thought the other guy was first. And I need a clicker. Good evening, everyone. I'm back. In this case, with a different hat on. It's my honor this year to be serving as the Chair of the NRO Executive Council. And with that comes the obligation to be here and to talk about the NRO again. This is an update of latest activities. Do we feel it necessary to go through what are the NRO slides? Does anyone need this? What is the NRO? I could ask any of you and you'd know exactly, right? All right. It's all the RIRs working together. We have five officeholders. Rotates. I'm the chair. Axel is the Treasurer. Adiel from AFRINIC is the Secretary.
Some news you may not have heard is that although we have a secretariat hosted by AFRINIC on account of Adiel, CEO being the secretary, we actually have a staff position now of executive secretary filled by German Valdez who happens to work out of the APNIC office in Brisbane. So we're a truly distributed organization.
German started in April of this year and is working full time supporting the NRO.
The ASO, what is that? The NRO is everyone working together. And one of the things we do together is we do the ASO. The ASO is formed by an agreement with ICANN.
If I can go back ‑‑ you may notice that the NRO was formed by an MOU signed on the 24th of October 2003. So that makes us very close to ten years old. Just, by the way.
ASO has been around one year less, it was the next year we signed the MoU with ICANN.
The function of the ASO is about taking policies from the RIRs to ICANN. Some other things like assigning Board members to the ICANN Board, et cetera. The ASO has an address council which comes from the NRO Number Council and I think the next speaker will tell you all about it. We have 15 members on that. I think you'll hear about this next time. The NRO finances ‑‑ we do have quite a few expenses. We've got staff costs and travel costs which is actually funding primarily the Address Council and NRO staff to attend meetings.
And some communication and outreach costs and we contribute a constant $823,000 per year to ICANN as a voluntary contribution. All of these NRO expenses, which add up to something like one and a half million a year, are shared proportionately among the RIRs. We have a cost sharing formula, which kind of reflects size and capacity to pay of each of the RIRs. Used to be a weighted formula of address space allocation, IPv4 allocations and registration services. We've just changed it so that we'll be sharing costs on the basis of Registration Services revenue only. And that's because we started to get that formula mucked up by the last /8 and the fact that some of us were allocating much less IPv4.
So, anyway, the cost sharing formula is now proportional to RIR Registration Services revenues from next year. There was an ASO review, which was conducted the year before last, reported last year. The latest on that is that we've sent a report to the ICANN Structural Review Committee and the implementation is underway, if not complete. And that might be the last time you see that slide. Internet Governance Forum is one of those activities that we carry out together in some respects. It carries that. There are RIR staff on the IGF multistakeholder advisory group, three of them, including myself and Raul and Paul Rendek.
And the IGF as I mentioned before is happening in Bali a week after next. And what the NRO does there is that we do gather there, and we represent the NRO. We run sort of a joint RIR booth distributing information. We make an annual contribution, which we increased to $100,000 per year this year. And that goes to the IGF secretariat in Geneva, which we believe deserves that support.
And we also joined together providing some workshops. So we've got workshops related to legacy space and IPv4 markets. And I think some regional policy development stuff coming up at the Bali, IGF. We also correspond occasionally with different people. We corresponded in the name of the NRO to the ITU for more openness and bringing greater attention during the World Telecommunications Policy Forum. We expressed our support for the IGF and multistakeholder model in the IGF open consultations earlier this year.
We have corresponded officially with ICANN about, in particular, about the ICP-2 process, which is the process for the recognition of new RIRs. I've pointed out to them quite firmly in this case that the establishment of a new RIR needs to follow the ICP-2 process which requires a bottom‑up industry community support for new RIR. That was around possibility that was being discussed in various places of the new RIR in the Arab region. We felt it was necessary to point out clearly to ICANN about the particular conditions there.
We did that publicly. There's no secret there. It's simply a reiteration of what's required by ICP-2. And most recently some email to ICANN to follow up on the issue of the establishment of the RPKI test bed with IANA, which is something that we're moving forward with within the engineering teams of most but not all the RIRs and working together with IANA.
In other developments, we've had a couple of retreats this year, most recently last week in Montevideo. A little more on that in a second. We've got NRO coordination groups working on Registration Services and IPv6 in a better coordinated way these days.
We're hoping to get more convergence on RPKI as all of the RIRs sort of reach the deployment of RPKI. There's been a bunch of interoperability testing which has gone on at the last IETF, in particular. Very active interoperability testing between the different RIR engineering groups.
And some recent further discussions with ICANN about their IANA consultation recently and increasingly the presence of the ASO and therefore the RIRs and IP addressing, in particular, in ICANN meetings. Now at this recent Montevideo retreat, we had a bunch of things that were being discussed. This was a particular NRO planning retreat, particularly about our vision and mission for the future. It was followed by another meeting that you may have heard about which involved all of the RIRs and the other Internet organizations.
That wasn't as such an NRO meeting. So I'm just talking here about the NRO retreat meeting itself. We established a new vision for the NRO. As of 2013, the vision is to be the flagship and global leader for collaborative Internet number resource management as an essential element of an open, stable and secure Internet.
We haven't had a vision statement before. That's it. And with that goes a mission statement. And the mission of the NRO is to actively contribute to an open, stable and secure Internet through: Providing and promoting a coordinated Internet number registry system; Being an authoritative voice on the multistakeholder model and bottom‑up policy process in Internet governance; and Coordinating and supporting joint activities of the RIRs.
Now there was a lot more discussed over two days with the NRO than that but we've got quite a bit of work to do on sharpening up a bunch of objectives for the future. So that's part one of what you'll hear about the results of that meeting. And that's all I've got to report.
John Curran: Thank you. Any questions?
Sandra Murphy: Sandra Murphy, SPARTA. I did a quick search to try to come up with dates. There was an NRO letter to the ICANN concerning the possibility of discussions of a global trust anchor. And I noted the slide talking about RPKI project management. And I noted something about discussions with ICANN. I was wondering if either of those had anything to do with the status of the discussions concerning the global trust anchor.
Paul Wilson: Not directly. The last correspondence to ICANN ‑‑ I seem to remember you asking me about this the last time I was up here.
Sandra Murphy: The last time we were in a meeting together.
Paul Wilson: Things have been moving along slowly. The last correspondence to IANA was to confirm that the RIRs represented by the NRO saw the global trust anchor as the correct eventual outcome and we wanted to move towards a test bed for that process for the global trust anchor to be a site of that at IANA. Not much happened there over the subsequent one or two years. And that actually reflects, I suppose, the collective priority among the other RIRs to move ahead and do that.
We were asked a number of times by ICANN or IANA staff what we were going to do with them and when, and hence the most recent correspondence, which said, yes, we do want to move ahead. But the reality is that not all of the RIRs will be involved with the test bed. Specifically, one of the RIRs does not want to be involved with the test bed and they have a lack of consensus in the community on progressing with that test bed.
And that's been a situation, which has been going on for some time. And it's resulted, as I said, as I mentioned, in kind of a lower priority, actually doing this. But we have agreed with no commitment at all to an actual global trust anchor deployment at any particular time in the future because of that lack of convergence of the RIRs. We've agreed to be moving ahead with the test bed, which would be supported or which will have at least four or just four RIRs participating in it. Is that good enough?
Sandra Murphy: It's an indication of the status. That's what I was hoping for. Thank you.
John Curran: Any other questions for Paul? Thank you.
John Curran: Okay. Moving right ahead. We're actually going to skip the Activities Report and we're going to move into the IETF/IAB v6 report. Louie will present the activities report tomorrow.
Cathy Aronson: I was really hoping to get punted to tomorrow. So where's the thingy? Oh, it's new. Hi. Oh, this is not the right slide. Hold on.
John Curran: Cathy, you're here tomorrow?
Cathy Aronson: Yes.
John Curran: Take your time. We'll have you do it tomorrow ‑‑ send the new slides. We'll have Louie and we'll move on to the Experience Report. We'll have you tomorrow. You'll be the exciting IETF portion of tomorrow's program. Okay. Now we'll have the NRO AC Number Report, just like the agenda says.
Louie Lee: I'm Louie Lee, Chair of the ASO Address Council. This is Louie's hat. Everybody loves my hat. More than me even. A little refresher of who we are. Quickly we'll review what's global policy and the PDP. I think we'll skip that in interests of time and what we have done for you lately. And I will focus on just the NRO NC and the Address Council because you were paying attention to Paul, right?
I've got my notes here, too. Thank you, though. So you already know about all this from Paul. Basically the NRO Number Council performs a function of the ASO AC. There are 15 of us, three from each of the five regions; two elected, one appointed.
And you know all about the MoU now. What is the ASO AC? We are an independent body that's separate from the RIR management and Board. We oversee the Global Number Resource policy work. We appoint two directors to the ICANN Board. Serve on various ICANN bodies as needed, and we advise the ICANN Board and IANA on Number Resource matters. The three members today, you've heard the introductions earlier this morning. So moving on. Currently no global policy proposals. Global policy, you all know what it is? Who doesn't?
Vint Cerf: This is the definition.
Louie Lee: It's outdated, probably.
Vint Cerf: Definition doesn't include the definitions that John Curran mentioned earlier today. You may want to clarify that.
Louie Lee: Yes. As we understood previously, global policies are those that require an outside body to act. Meaning IANA is what we typically assume. But there is a case that John had informed us earlier today that global policy could be one where all five RIRs, communities, agree on having that policy be applied to themselves. And we'll take questions on that later.
The PDP for global policy relies on the regional PDPs. You can see it on the slide. Moving on. Okay. ASO AC activities recent procedure updates. We're in discussion now on changes to the operating procedures with the ICANN Board selection; document destruction procedures to protect the privacy of the Board candidates; and we are also working on formalizing some of our procedures on how to appoint members to various bodies, such as the ICANN nominating committee, the accountability, transparency and review teams and other review teams being called on by the agreement between the Department of Commerce and ICANN.
Most recent with ICANN participation, we were at the Durban meeting in South Africa in July. We participate in the IPv6 workshop with a PDP presentation where there were also other IPv6 presentations from the Africa region. We met with the ICANN Board, the at‑large advisory council, the ATRD2 and the NomCom. We appoint individuals to the ICANN bodies, such as Kuo‑Wei Wu to ICANN Board of Directors, Hans Petter Hollen for the ICANN NomCom, and Fiona Asonga for the ATRT2.
And as an aside, there's also an ATRT2 member in the audience. I believe David Conrad is still in the room. If you have any specific questions about that, hit him up.
And we also continue to participate in ICANN outreach. We're developing a webinar with the ICANN staff to be given prior to the ICANN 48 meeting in Buenos Aires. Now we did respond to a request from IANA for guidance on the interpretation of the IANA policy for allocation of ASN blocks to the RIRs. Specifically on the idea that does a block of 10/24 need to be contiguous?
And our advice in the end as that it does not need to be contiguous. If you want discussion about that, we'll take questions. And, more specifically, with the ICANN Board selection, seat nine right now is occupied by Ray Plzak. His term will end in 2015, near the end. In 2014, near the end of next year, we'll start accepting candidates for that seat. Kuo‑Wei, we appointed him for another three‑year term, and his new term ‑‑ and I will have to have a correction at the very last line ‑‑ his new term is to start at the end of this year going on three years. That's it.
Cathy Aronson: Cathy Aronson, ARIN AC. So the thing about the AS numbers, I don't think they need to be contiguous or anything, but could, in the future, things like that actually go to the PPML, because I picked that up off of the RIPE policy list, and we were unclear whether that communication was, maybe it was Wilfred posted it to their list. And so there was some confusion, and the AC, we were discussing like where that came from or why he said it's policy. So it would be nice if we got communications about those things in our region as well.
Louie Lee: Noted.
John Curran: Okay. Any other questions? No.
John Curran: Okay. We're in our final stretch here, and we're going to end up with the policy experience report followed by the Open Policy Hour. So Policy Experience, Implementation and Experience Report. Leslie, come on up.
Leslie Nobile: Hi, everyone. This is the Policy Implementation and Experience Report. This is the staff opportunity to give you feedback on recently implemented policies, to briefly review them with you and to give you feedback on some of the issues that we see with the current policy set.
So recently implemented: There were two that we implemented since the last ARIN meeting. The IPv6 subsequent allocations utilization requirement was added and it basically says that ISPs can qualify for an additional v6 allocation when they've assigned 90 percent of their space to serving sites, has a few other requirements and criteria.
We have not reviewed any requests under this policy as of yet. The second policy we implemented was Section 8.2, reorganizations. The term "reorganizations" was put back into the mergers and acquisitions transfer policy that was inadvertently removed in the previous iteration of the transfer policy. So that was basically an administrative change.
Purpose of the policy experience report, this gives the staff an opportunity to sort of review our existing policies and identify some of the issues that we see with them, and these issues could include ambiguous text or inconsistencies in the policy, conflicting policy text, gaps and the effectiveness of the policy: Is it working the way it's supposed to be working?
We will identify areas where new or modified policy might be needed, and we base this obviously on our operational experience in dealing with you all on a day‑to‑day basis.
And we take this customer feedback when we see a customer, more than one customer, even one customer having an issue with a policy and we'll bring this to the community. We'll provide feedback to the community and make recommendations where appropriate.
We've got two policies that we reviewed this time. The first is NRPM 4.5, Multiple Discrete Networks, and the second one is 10.3, IANA Policy for Allocation of ASN Blocks to RIRs. The first policy, Multiple Discrete Networks. So this is like a policy with a thousand moving parts. We're only focusing on one single part of it today. So this is the aspect that we're going to talk about. And the highlighted text is actually the important part.
So when applying for additional Internet address registrations from ARIN, the organization must demonstrate utilization greater than 50 percent of both the last block allocated and the aggregate sum of all blocks allocated from ARIN to that organization. So it says: When applying for additional Internet address registrations.
So this is one of those policies that are actually missing criteria. And staff has had to kind of add what we think is the right thing to do. So it right now only provides criteria for an organization to qualify for additional addresses for its existing sites. Its existing discrete networks. There's no criteria defined anywhere in the policy for the new sites of an existing MDN customer and there's just nothing indicated in the policy.
And just to explain that a little bit further: When customers come in and apply under MDN, they typically have address space from ARIN. They decide that the MDN meets their needs; they have discrete networks. They're going to apply under the policy. So they come in and get new space, additional space, excuse me, for these existing sites. And the criteria are really clear. I just read it to you. It works.
And we use it all the time. But as they grow their network and they add new discrete networks and new sites, brand new, no addresses at all, they come back and say, well, I need additional space for these three sites and I've got two new ones I'm putting up. So we can't apply those same criteria. It doesn't work. There's no history. There's no historical utilization information. There's nothing there.
So what we do, how do we qualify these new sites. We apply the general principles of the immediate need policy. And we will verify that the ISP has connectivity at each of its new sites by requesting a recent bill or invoice or signed connectivity agreements. We will issue a /22 minimum allocation when an organization shows us the signed connectivity agreement. That's just one of the principles of the immediate need. We know they're growing the network and we can see they have customers at their discrete sites. So we will issue the /22 minimum.
If they need more than a /22, then we go full on with all of the criteria from the immediate need policy and we go based on a 30‑day need, which is how immediate need works, 30‑day need. We'll ask for signed customer contracts, complete customer justification data, deployment schedule and equipment purchase invoices. And it works, but we have lots of customers saying: Where did that come from? Why are you asking me for this? I don't have to give you this. We have nothing to back it up except to point to the immediate need policy.
So this is ‑‑ we have some questions. Should specific criteria be added for the new sites of an existing MDN customer? And should staff or should staff continue their current practice of using the immediate need criteria. Should we go to the second one or ‑‑
Andrew Dul: Andrew Dul, multiple discrete network guy. When I originally wrote this policy probably way too long ago, I originally intended that the policy protect itself of that section, would allow for new multi‑discrete networks to be added without going outside of that policy text. There was a complete rewrite of the MDN policy sometime in the past ten years, and I suspect what happened was that section or something got removed such that this now exists in the policy text.
I think that ARIN's interpretation to allow for the current way they're doing it seems okay. That doesn't strike me as weird. I think that organizations who add new networks should be able to provide all that information rather quickly and that shouldn't be a problem. So my question is more of is this really a problem or is it just a, hmm, we missed something in our translation at some point?
Leslie Nobile: When customers start asking us what do you have to back that up, why are you asking I've reviewed the policy manual, it doesn't say that I have to show you these things. We figure that if it's lacking and it's not clear to a customer, then we should probably bring it to you all for some additional guidance. That's why we're doing it.
Andrew Dul: Perhaps some adjustments may be needed. Who knows.
John Curran: Any other questions?
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, frequent commenter. Should we add specific criteria? No. Should staff continue their current practice? Yes, I'd actually suggest you could loosen it into using the existing three‑month policies that these are organizations that are coming back time and time again. It's a very complicated scenario at the MDN.
And even relaxing it to using existing policy based on the three‑month rules, I would be perfectly happy with. If you feel that it's working with the more complicated and immediate need, which does complicate things, I'm okay with that to some degree. But again, once we go into runout, I think keeping it as simple as possible is the best option.
Matt Pounsett: Matt Pounsett, Afilias. I think what you're doing seems like the right thing. Actually, I suspect we're one of the customers who has gone through this in the last year. And it seems to work, anyway. So, yeah, what you're doing seems to be the right thing. If there's still confusion and it would help, it might make sense for us to do a one‑line policy proposal to make it explicit, to use immediate need for that case. But I think that would probably go okay.
Leslie Nobile: Thanks, Matt. Owen.
Owen DeLong: Owen DeLong, Hurricane Electric. ARIN AC. I don't have a problem with what you're doing. I think it might be more appropriate to treat the new multiple discrete site as an initial assignment in terms of criteria to apply to it. But I'll leave that up to staff discretion for now. I'm fine with either one. One question I had is: Are you seeing this as a problem strictly with the IPv4 MDN policy, or is this coming up in v6 as well?
Leslie Nobile: That's a good question. I think it applies across the board. But I think it would be in both, actually.
Owen DeLong: I'll look into it in more detail.
Jason Schiller: Jason Schiller, Google. I think there are two use cases here. If the new site is a new multiple discrete network of the same types of the others that already exist, they have some network that's been regionally divided three ways and now they need to regionally divide it four ways. I think the historic growth of the other three regions could be used for the fourth and you could give quarterly allocation. I think if the MDN is of a different type, for example, we have divided our network based on product, we have three different products so we have three different MDNs and we're going to start serving a new product, the fourth type. In that case I don't think the growth rate of the existing MDNs applies. In that case slow start makes appropriate sense. I think you should use your judgment and apply the right policy.
Leslie Nobile: Thank you. Scott.
Scott Leibrand: Quick response to Owen. MDN in IPv6 is under a completely separate section, 6.11, that specifically says that each individual site is going to be treated like its own site. So my reading is it's pretty explicit in the v6 MDN, not the v4.
Louie Lee: Louie, Equinix. As a user of the MDN policy and also we have different classes of products where we have sets of MDNs, I support Jason's idea.
Leslie Nobile: We'll move on. So the second policy is NRPM 10.3, IANA Policy for Allocation of ASN Blocks to RIRs. I've brought this one to the community several times but the problem has changed slightly. After December 31st, 2010, IANA and the RIRs make no distinction between 2‑byte and 4‑byte ASNs and will operate from an undifferentiated 32‑bit pool.
The issues right now are as I think Leo may have mentioned, IANA has now issued its last full block of 1024 2‑byte ASNs. Issued to APNIC in September. So there are only 495 2‑byte ASNs remaining in IANA's free pool. That's it. ARIN will likely not qualify for additional 2‑bytes and we'll have to rely on our existing supply.
We do reclaim ASNs. And I have some stats on this after this, but they're not a steady supply. It's not reliable. We're never sure when we're going to get them back. So just some quick stats. We issue about 1400 ASNs per year. We've only issued 73 4‑byte ASNs since the policy was put into place in 2007. We have issued 32 since May 2013, when we changed our practice. I will talk about the practice in the next slide. Zero have been returned, which is sort of a miracle, because it's never happened before.
Our current inventory, we've got 677 2‑byte ASNs. We've got 959 4‑byte ASNs.
As far as recovered 2‑byte ASNs, we've recovered in the past six years anywhere from 300 to 1500 2‑byte ASNs and that's typically due to revocation due to nonpayment of registration fees. But again not a consistent number. So our current practice: We issue 2‑byte ASNs by default. But we first notify requesters of the 2‑byte depletion situation and we ask them to consider 4‑byte ASNs. We just implemented this in May 2013 after the last ARIN meeting we thought we need to try something different.
Prior to that, we were issuing lowest to highest because we were ‑‑ virtually all the 4‑byte ASNs we did issue were being returned with the reasoning that their upstream said the router wouldn't support 4‑byte ASNs. Our undifferentiated pool was we'll issue lowest to highest, put them all together, and we'll eventually get to the 4‑bytes. We're at the point, really, now where we'll have to. So our questions: Should ARIN change its current practice to issuing 4‑byte ASNs by default and 2‑byte ASNs only when technical justification shows that a 4‑byte won't work?
It's looking like the 4‑byte ASNs are somewhat usable now. As I've said, we've gotten none returned to us since May. That's never happened before. This would facilitate a smooth transition rather than hitting the brick wall when we're actually out of 2‑byte ASNs completely. And it would align us with the other RIRs. Currently APNIC, RIPE and LACNIC issue 4‑byte ASNs by default.
They sometimes have problems, as Paul indicated. There are some that still do get returned but it's not a high rate. And RIPE and LACNIC, in particular, have been very successful with their issuing 2‑bytes and 4‑bytes by default. A suggestion that came to mind, in speaking with Kevin actually, having a discussion about this, we could experience ‑‑ or you all could expand the waiting list policy to include 2‑byte ASNs.
So basically it would go into effect when ARIN has depleted its supply of 2‑byte ASNs and organizations that are unable to use 4‑byte ASNs could be placed on a waiting list until a 2‑byte ASN becomes available. We thought that would be a good sort of backup measure. And here comes Geoff.
Geoff Huston: I thought you might want to know what's in the routing table because I think it's kind of curious. There are, from ARIN, 23 4‑byte ASN numbers advertised in the BGP routing table. 23. In the RIPE NCC region, there are 2,419. I don't actually what happens in what geography in longitude and how it affects electrons and software and routers, but you know there must be something that's west of the Greenwich meridian that all of a sudden your implementations of BGP just simply go weird. Even in LACNIC, though, it's latitude as well. LACNIC managed to advertise 854 of them and APNIC 711. 23? There's something just ‑‑ I don't think it's technical. I'm sorry. We all run the same gear.
Leslie Nobile: That's what we're hearing. Of the 32 that we just issued, we checked the routing tables as well and it looked like five of those 32 were actually being routed. So we thought that was good news. That's all I have. Are there any other questions or comments?
Leslie Nobile: I think they were over there first. Rob.
Rob Seastrom: It's still a problem, quite embarrassing five years on, to talk to friends and colleagues and say just this past week somebody trying to get a BGP session turned up with an upstream that's nominally ‑‑ I think that everybody in this room, if I were to say their name, would say, yeah, they're a tier‑one provider, can't seem to get their software updated to something that was written this decade. And there's all sorts of drama. We need to disconnect you from the brand X router and connect you to the brand Y router because we don't have the right stuff loaded on it, this, that, and the other.
I don't have a good solution for you, but the problem is just not getting fixed. And I don't know if the problem is that in 2008 they laid off all their engineers and nobody's still around. I just have no idea how to fix this other than maybe it's time to start naming and shaming.
Vint Cerf: I was heading down the public embarrassment path: Anything we can do embarrass people into getting their software up to date is probably a good thing.
Rob Seastrom: I don't want to take this to the next level, but maybe in another three meetings I will.
Leslie Nobile: I think Kevin was there.
Kevin Blumberg: So public embarrassment is wonderful, but, unfortunately, the losers in this particular situation are the most vulnerable: The new multi‑homers. My question I asked was a little loaded this morning because Leslie and I had this chat last week when I was chatting at the APNIC report. Leslie, do we need to make a policy for wait listing, or can we, staff, just do the right thing in this particular regard? Does the community have to go through the whole machinations, or if somebody says, hey, when one becomes available can you put me on a list, an Excel sheet or whatever the case may be, I'll take it, and we don't have to go through the whole cycle?
John Curran: I'll take that one. There are Number Resources. We follow policy to do them. And actually we just heard earlier how some of the RIRs are actually audited on the quality of their adherence to their policies and procedures. Okay. So, hey, look, it's all good. We'll just do what you want. Now, if you ever do want us to excel to operating in a consistent manner, following document policies and procedures, then doing the right thing doesn't always go through an audit. It's up to the community. The community can guide us. I just want to be clear that we've been trying to aspire to highly reproducible results and that would suggest policy.
Kevin Blumberg: Without a staff interpretation handbook for the community, which would be a very massive undertaking, I'm sure, in the absence of policy, what would we do in this situation?
John Curran: Right now, in the absence of policy? There is no, per se, waiting list for AS numbers. So you couldn't get one if one wasn't available unless you asked and one showed up just then.
Kevin Blumberg: Let me rephrase it then. From a customer perspective, in the absence of a no or a definitive guide, should the ARIN organization be doing that? I guess it's a bigger question.
John Curran: That's this room, right?
Kevin Blumberg: Yes.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Can you go back two slides I think it is? The one that looks like the left arrow. So in terms of whether ARIN should change their practice or not, frankly, I don't care. But if you did want to change that practice, is that something you're looking for feedback here and you'll just do, or is that something that would require policy, in which case I don't think we're going to get the policy done in time for it to matter.
Leslie Nobile: It's not a policy. It's a practice. That's all we're asking for. Just guidance, feedback.
Owen DeLong: So my feedback on that is I don't care. In terms of policy for the other one, whether policy is going to get done in time to matter, I don't know. But putting it on the waiting list, sure, why not.
Leslie Nobile: David Conrad.
David Conrad: Since I don't run any routers anymore, I feel perfectly comfortable saying, yes, 4‑byte should be default and there should be a waiting list. I think pragmatically it doesn't actually matter because, given the low stocks of ASNs, if you're not able to handle 4‑byte ASN, you're going to be facing a really bad time.
Matt Petach: Matt Petach, Yahoo. based on an earlier comment I'd like to propose the default be if you already have an ASN that you're routing, it's 4‑byte by default. If it's your first time and you're one of the vulnerable people that were mentioned earlier, that you would get priority in that queue for 2‑byte either in the wait list or if there's a 2‑byte available and you indicate you need a 2‑byte, I would say first‑timers get first dibs. If you're coming back, you are doing BGP, you should know better, get a 4‑byte.
Leslie Nobile: To comment on that: Most of the people who request ASNs are first‑timers, quite honestly. There's not a lot of repeat customers ASNs.
Matt Petach: I think it's just crazy people like us.
John Curran: We're closing the queues on this part of the presentation. So get in the queue if you're speaking.
Aaron Hughes: Aaron Hughes as Aaron Hughes. I've interacted with a lot of small providers and a lot of small players, start‑up gear with really small footprints and really cheap routers with really small T cams that don't support current code. It's not untypical to try things with stuff from the gray market.
I wouldn't suggest changing the current process. The staff is handling this. However, I would suggest potentially something like an officer attestation letter or a notice to the members to say, hey, this might be an issue: If you're waiting on your forklift upgrades and this is a potential revenue impact, you should know about this.
Cathy Aronson: Cathy Aronson, ARIN AC. This has been going on forever and this code's been written for a long time. And although I have sympathy for little guys, I say 4‑byte ASNs by default and then that's just life at some point. They're going to have to do IPv6, too. I mean they need to get with the world.
Leslie Nobile: David.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I would agree change to 4‑byte ASNs by default. That still gives them opportunity to come back, makes a little more work for them but so what. And then I really like the idea that was just mentioned about preference for first receivers and setting up the waiting list. So I'm going to think about that and probably get something rolling.
Leslie Nobile: Andrew.
Andrew Dul: Andrew Dul, speaking only for myself. I would suggest that we consider what other communication methodologies need to be done at this time to declare a 2‑byte ASN exhaustion in our region and communicate that as widely as possible.
Leslie Nobile: I can tell you that we're working on that presently. We've been speaking with IANA about doing something jointly. And we are writing and working right now on communications about that.
John Curran: Thank you, Leslie.
Leslie Nobile: Thank you.
John Curran: Okay. We're in that final part of the day. We're going to have Open Policy Hour and then we're going to close the meeting.
John Curran: So this is the opportunity with the Open Policy Hour to come forth and raise any other policy topics that you wish to bring them to the attention of the community. Sometimes you find other people who feel the same way and you then go off over the social and work on new policy proposals. So this is the time to approach the microphones and talk about policy matters you haven't heard so far.
Vint Cerf: Just a reminder that if this is Open Policy Hour, and my watch says it's almost 5:30, if you go to 6:30, you're in trouble.
John Curran: Yes, very much so. This will probably go ten or 15 minutes. We also have another one tomorrow at the very end of the meeting. So microphones are open.
Mr. Schiller, I know you have something you'd like to speak ‑‑ wait, first Kevin.
Kevin Blumberg: If there's somebody else, by all means. I'll be fast. We were talking about slow start post‑runout. One of the ideas that I had in regards to fixing slow start especially for ISPs who aren't going to have their upstream space initially was with contract, the usual vetting contracts and et cetera. Just giving them, allowing them to go to the transfer market for /21, /20, /19, the community can decide on what the size is based on their first initial 24‑month allocation that they would get.
But if they can't get space from their upstreams, they need a kickstart, an ignition to be able to do what they need to do. And I wanted to gauge whether people feel a policy like that is a good idea.
John Curran: Anyone else like to speak to that or interested in it? Okay. His name is Kevin. He's over there. Raise your hand, Kevin. Find him if you're interested.
Okay. Jason signed up. Is he here? Schiller. Come on up, Jason. RIR principles someplace else.
Jason Schiller: I'm going to go through this quickly. I wanted you all to be aware that there's a LACNIC policy for RIR principles. It is different than ours. And there is this idea that going forward we might combine these policies for a global policy proposal.
So I wanted this community to look at LACNIC's policy proposal and make any observations how they felt about it and whether if some of this or all of this language ended up in a global policy, what this community would do with it. So I'm just going to read through it quite quickly. There are a bunch of other changes that I've not put up on the slides. There are a bunch of references to 2050 that are mostly replaced with the word "hierarchical," something or other.
But the meat of it is here in Section 1.11, which is principles for proper administration and stewardship: The fundamental principle is to distribute unique Internet number resources according to technical and operational needs of the network currently using or that will use these numbering resources allowing the sustainable growth of the Internet. The numbering resources under the stewardship of LACNIC must be distributed among organizations legally constituted within its service region and mainly serving networks and services operating within this region.
External clients connected directly to the main infrastructure located in the region are allowed. Anycast services that use numbering resources outside said region are acceptable as long as they are provided by an organization legally constituted within the service region and at least one copy of the service is hosted on the local infrastructure.
1.11.1, rational distribution: Internet numbering resources must be distributed ensuring their uniqueness and considering their technical and operational needs of the networks and the infrastructure that use them. Considerations must be made to take into account potential limitations on the availability of each numbering resource at the time of their distribution.
1.11.2, public information registry: Providing a public registry of information relating to the numbering resources that have been distributed is a fundamental requirement for the Internet numbering resources distribution system, aimed mainly at ensuring the resources uniqueness while providing usage and contact information in the case of operational security or problems that arise. Also, to allow analyzing the use of these resources.
1.11.3, the last section, hierarchical distribution: The hierarchical distribution of the Internet numbering resources seeks to contribute to the Internet routing system's scalability allowing resources to be grouped and announced as concisely as possible.
In some cases, the goals mentioned above may be in conflict with each other or with the particular interests of the requesting organizations. In these cases, a careful analysis of each particular situation is required so that an appropriate compromise can be reached among the conflicting parties.
So should there be a global policy in the space of RIR principles? If so, if it ends up looking more like the LACNIC version than our version, what issues does the community see with that? I hope someone will come to the mic.
John Curran: Any comments?
Milton Mueller: Milton Mueller, Syracuse University. Could you go back two slides to the first slide, I think.
John Curran: Like Jason, did you take the remote? That would be cruel.
Milton Mueller: So this principle, so‑called principle articulates basically the territorial approach to address allocation, territorial exclusivity that we pretty much rejected in our discussion this morning. I would consider that to be unacceptable, particularly the second paragraph. And I would think that would be something we'd want to get out of that before we accepted it as one of our principles.
John Curran: Thank you. All right. Any further comments? If not, I'm going to close the open mic session. I'm closing the queues. Any remote participants? No. No, I am closing the queues. The queues are now closed. That ends our open mic and concludes our program for the day. Thank you, everyone.
John Curran: The election is open. So if you're a Designated Member Representative, you can vote now. teamarin.net/2013‑elections. Visit Jud at the election help desk if you have any questions. Thank you for our sponsors. A round of applause for PhoenixNAP and Gila River Telecom.
John Curran: Also our webcast sponsor, Google.
John Curran: Okay. Don't forget the meeting survey. There's a meeting survey arin.net/arin‑32surveys.html. If you want a paper copy of it, raise your hand right now. If you want to burn a tree, there's one. Okay. We'll get you a paper copy. Someone's got that covered, right? Okay. All respondents online or paper will be entered to win a Samsung Galaxy Note 10.1. Very nice. Okay.
Tonight's social: At the Octane Raceway. Buses will leave the hotel starting at 6:00, which is real soon now. Also 6:15. 6:30 and 6:45. Listen carefully. If you went to the NANOG social and got on a bus, it's at a different place than this bus. So to get to this, it's at the conference center entrance, at the Komatake Ballroom E.
Go out the door and turn right, walk to the far end, outside the ballroom, all the way to the end, away from the main lobby of the hotel to the entrance of the ballroom. Return bus service will start at 8:30 and ends at 10:30. Bring your name badge. Reminders. Breakfast 8:00 a.m., down here. Meeting at 9:00 a.m. All the meeting materials are online. Thank you, everyone. Have a good day.