ARIN 31 Public Policy Meeting Day 2 Draft Transcript- 23 April 2013 [Archived]

Opening and Announcements

John Curran: Good morning. If people will come in and be settled, we’ll get started. Wow, a lot of people had a good night and didn’t make it. Hopefully we’ll see them before the policy discussion. Welcome back to ARIN 31 in Barbados. I’m John Curran, President and CEO. We have a couple of opening announcements. First, I’d like to thank our sponsors. Network connectivity is provided by LIME, and I have here Ian Galt. Ian is one of the managing directors at LIME, responsible for their government services. He’s very experienced in this region, having established LIME’s managed services portfolio. And I think as our sponsor you should come up and say a few words about today. Come on up.

(Applause.)

Ian Galt: Good morning, everyone. Can everyone hear me? I see you’re absolutely right. Looks like it was a busy night. I’m sure everyone was working feverishly last night, hence the reason that you’re here. So, first of all, welcome to the Caribbean. Welcome to Barbados. LIME is delighted to be one of the co-sponsors of this event. What ARIN does is it relates to readying the region for IPv6 over IPv4 is something that we absolutely support, and we’re obviously here to ensure that our region is ready and compliant when the time comes.

I understand this is the first time I believe it’s the first time that ARIN is meeting in the Caribbean or Barbados; is that correct?

John Curran: Yes.

Ian Galt: I’m seeing yes and no. First time in Barbados. Good. First time in Barbados. Very good. And I’m sure everyone is here to only work. I’m sure no one is going to enjoy the golf courses and the aquamarine seas. So jokes aside, what are you guys going to be – who is scuba-ing and who is golfing? Someone tell me. The reason I ask is it reminds me about a little joke about Barbados, and the joke is this avid scuba diver, you know, he lives, eats, sleeps, breathes, that’s what he does, and he’s readying himself for a dive one day off a boat, and he has an epiphany moment, and before him appears an angel. And he said “You know, I gotta ask you,” he said, “you know, when I close my eyes and die,” he said, “I have to know if heaven has scuba diving.” And the angel says, “I’ve got good news and I’ve got bad news. What do you want first?” And he said “I’m a positive kind of fella, you know, from the Caribbean. Give me the good news.” He says “Boy, you wouldn’t believe the scuba diving heaven has. He said: We’ve got waters that make Barbados waters look muddy all kind of sea life and fish you can swim with. It’s heaven, they’re all well fed. They don’t eat you, don’t attack you. Don’t have boats buzzing overhead, we’ve got fabulous dive boats, instructors, best equipment, and when you get back to shore the best clubhouse, open tab, no bills to pay.”

The guy says: Geez, this is fantastic, man. He said so what’s the bad news? He said the bad news is you’re taking your first dive at 3:00 this afternoon.

(Laughter.)

Ian Galt: But jokes aside, welcome to Barbados. You know, this is, like I said, something that LIME absolutely supports. We welcome you. We’re certainly here as one of the long term and committed partners with ARIN. LIME is a company with a lot of history in the region. We’ve been here, depending on the island, about 150 years. You know, back to the very, very early days of POTS, plain old telephone services. Today we’re very proud of our landline infrastructure, sub C infrastructure, our mobile offerings, our IP TV, very new and exciting product we launched about 15 months ago, our mobile infrastructure.

So we consider ourselves an absolute full-service provider, everything today from the standard telephone right through to cloud services. We’re here to support ARIN. We’re here to partner with ARIN, enjoy the rest of the time here, and great to be part of this. Thanks very much.

(Applause.)

John Curran: Thank you, Ian. Wonderful. I’d like to remind everyone our registration services desk is open, our financial services desk for people who need help with their registrations or their financial matters with ARIN. Both are right outside the meeting room.

Rules and reminders: The Chair moderates discussions of all the drafts so that all can speak and all can be heard. Please state your name and affiliation at the microphones when you’re recognized. And please comply with the rules and courtesies outlined in the program. Today’s agenda. We have a very full agenda. We’re going to do the ARIN Consultation and Suggestion and Process Report. These are the consultations and suggestions that have come in. We’ll do at some point today the NRO Number Council report, and we’ll do an update on ICANN Durban, upcoming meeting. We’ll have a presentation on RPKI delegated and ARIN command line interface. We’ll talk about the revised fee schedule.

We’ll have an update on BCOP efforts, and an update from ISOC on Deploy360 initiative. I’ll give an – they’ll give an Internet governance report, talking about activities in Internet governance. We’ll have an NRO Activities Report. And of course we’ll have an Open Policy Hour and open mic. We’ll talk about policy matters as we did yesterday. We also have a couple of policy discussions on the agenda. We have 2013 2: 3GPP Network IP Resource Policy and 2013 3: Tiny IPv6 Allocations for ISPs.

So at the head table: Our Chairman, Timothy Denton; Cathy Aronson; Aaron Hughes; John Springer; and Heather Schiller. And that might be the first time I got it right.

(Applause.)

John Curran: Wow, very nice. We’re going to start right in. And the first item is the ARIN Consultation and Suggestion Report. I’m going to have ARIN’s Chief Operating Officer, Nate Davis, come up and give that.

(Applause.)

ARIN Consultation and Suggestion Process Report

Nate Davis: Good morning. How’s everybody? Just an administrative issue real quick. John mentioned it, but I want to make sure for the remote participants, they caught it. We did have an agenda change for today. So for those that are participating remotely, there was a schedule change, if there’s a particular discussion that you were looking to participate in, please make sure you check the agenda so that you’re aligned with the new schedule that we have out and posted today.

So all right. ARIN Consultation and Suggestion Process. So as you know, ARIN collects input and processes input two ways. One is on the policy side, and we have PPML and also the PDP which governs how ARIN facilitates the Policy Development Process, which is the significant portion of what ARIN does. ARIN also collects input from the community regarding all other matters, as far as what ARIN should be doing, not doing, any great ideas and so forth.

And so the Consultation and Suggestion Process is actually our process to capture all policy/non policy related matters regarding things that are of interest to the community that ARIN should take a look at. And so that’s what I’m going to talk about today.

All right. So we have two active suggestions. And these are open suggestions that we’ve received recently that are included in the open suggestion review period. And it’s part of the recently revised Consultation and Suggestion Process, where we’re bringing these, actually, these open suggestions to the meeting and increasing the visibility for everybody’s input.

What we are looking for specifically as we go through this is a couple of things. One is to take a look at these open suggestions, provide ARIN some feedback on the comment or the merits of each of the suggestions, are they worth doing, are they not worth doing, is there an alternative to how it’s being suggested that somebody might want to consider and so forth, and give ARIN some ranking as far as in a particular order, as far as priority, as far as how ARIN should be approaching these from a priority perspective and implementation.

We’re soliciting this feedback back at the meeting, part of the policy process, and we do look forward to folks going on ARIN Consult and providing us some feedback. Now is a really good time. And the reason I say that is that in August the staff worked with the Board in laying out the activities and the projects and the operating plan for the next two years.

So if the community has any particular interest in some of these open suggestions or actually anything that ARIN is working on in general, now’s a good time to give us your feedback.

All right. So the first suggestion is 2013, provide Whois RESTful Web service results in JSONP for ease of third party application development. That should be third party. So this suggestion is actually just basically to allow an API for developers to be able to use some of the Whois results in a more effective manner for whatever they’re doing within their own environments.

When the engineering took a look at it, what ARIN planned to do with this is to add the access control, allow origin and header, and this is programming speak. So if anybody has specific questions, they can see Andy in engineering, but we would add that header to enable the functionality as it is best standardized approach for providing this type of functionality or service.

The engineering staff also took a look at what it would cost to implement this or develop this. And it’s about $21,000 just to give you a sense of size and the effort involved here. And that’s engineering and communication costs, QA, and so forth. The second open suggestion that we have is to change Whois output for certain /8 records. And this is 2013.4 on our suggestion list. And basically right now when you make a Whois query at a /8 for an ERX record, we will actually show the IRR that’s authoritative for that /8. What’s proposed if there’s actually a DA or DS record that’s available for that is instead provide that output.

Engineering took a look at that, and it’s going to cost roughly about $26,000 for ARIN engineering to put that into place. There’s two options as part of this suggestion, and we’ve gone out to the community seeking input as far as whether we should keep things the same or we should change them. And this is something we’d really like to see, have additional community input in regarding the importance of which direction ARIN should take.

Also we have in addition to the consultations we keep an ongoing list. If you go out on ARIN’s website under resources functionality, we try to keep the community apprised on that Web page of what ARIN is working on, what’s on radar, what’s on the horizon – what’s just outside of radar and on the horizon that we will be looking at, and also those things that we’ve implemented.

It’s a good place to see sort of if you will for all things suggested and otherwise what ARIN has implemented and what it is looking at and plans to in the future. So we’ve – so it’s a good place to look from time to time, but more importantly we actually have a survey we’d like to collect additional input. We do this from time to time because business conditions change for you as well as ARIN and we’d like to get a sense of what’s important from the community.

So if I could ask in the next few days if everybody has some time to please go out and take a look at the survey and respond to it. It would be helpful to us in determining what is important to the community. The ARIN Board has asked that the staff make a particular effort to solicit input from the user community for our functionality. And this is one of the methods that we’re doing this.

Another method, just as a side note, is that if you’ve recently completed a request with registration services, they’re actually soliciting input as part of the registration services process. At the end of each of those requests as they are completed, they’re collecting survey information from folks that have worked for registration services on their interaction with ARIN.

So, again, these opportunities exist. The survey here, the one with registration services, and it is all very helpful to ARIN staff in collecting those things that are important to the community outside of policy. And I think that’s it. Any questions? None at all?

John Curran: Thank you, Nate.

(Applause.)

John Curran: Okay. Next up on the agenda is going to be Jason Schiller. He’s going to present the NRO Number Council Report.

NRO number Council Report

Jason Schiller: Good morning. So this is the NRO NC report. I’m going to talk a little bit about what the NRO NC is and our recent activities. So what is the NRO? So normally when we give this slide deck, we start talking about all of these acronyms and alphabet soup. ICANN, the Internet Corporation for Assigned Names and Numbers, which performs the IANA function; IANA, the Internet Assigned Numbers Authority, which is responsible for IP addresses, ASNs, protocols and ports, and coordination of the root DNS.

There are ICANN support organizations of which the ASO is one, the Address Supporting Organization. This is all very complicated. In fact, we recently had an independent review from ITEMS, and they said there was a lot of confusion about what is the NRO and what is the ASO and how do they relate to each other. Rather than starting with all these acronyms, I’m going to do something different this time. I’m going to talk about what is the NRO, the Number Resource Organization.

This was formed by the NRO MoU in 2003. And it basically established a body for the five RIRs to coordinate and act together. This way they can speak with a single voice, and they can perform joint operational and external activities. And their mission is to protect the unallocated Number Resources, to promote and protect the bottom/up policy that you all know well and love, and to act as a focal point for the community for input. And the NRO is divided into three sections. There’s the Executive Council, the Number Council, and a Secretariat function.

So the Executive Council is one member from each of the five RIRs appointed by the RIR Boards. Historically it has been the RIR CEOs, but that’s not a requirement. The Boards could appoint someone else if they so desired. And it represents the NRO in external activity. It represents the RIRs on issues that the RIR delegates to it and it speaks on behalf of the five RIRs with a single voice. It also has the ability to commit RIR services, for example, to pay for travel and to appoint RIR staff to work on NRO issues and concerns.

The other part of the NRO is the Number Council. And this is made up of three members. So, no, this is incorrect. Yeah, there’s three members from each of the five RIR regions. Two of them are elected by the community, and one is appointed by the RIR Board. And it has been designated to perform the function of the ASO AC.
So what’s the ASO? Never mind the ASO AC. The ASO is a support organization from ICANN responsible for addressing. And this was formed out of the ASO MoU which was signed between the NRO and ICANN back in 1999, and it’s been updated since LACNIC and AFRINIC came into existence.

There’s a URL. If you can’t sleep tonight and want to do some reading, download the MoU and take a look. It basically establishes that the NRO NC will perform the function of the ASO AC, which I still haven’t defined, but will be coming to that shortly. It also defines the roles and process for global policy development and defines how to provide recommendations to the ICANN Board with respect to recognition of new RIRs and also number policy. So finally we come to the ASO AC. What exactly is it? It’s the Address Supporting Organization Address Council. And this function, as I said previously, is performed by the NRO NC.

It’s an independent body separate from the RIRs, and it basically works with the ICANN board. It oversees Global Number Resource Policy Development. It appoints seats nine and ten to the ICANN Board, and it serves on various ICANN bodies, for example, the NomCom or the security and stability review. And when the ICANN Board asks for advice on Number Resource matters, it provides such advice to the ICANN Board.

So as I said before, we’re made up of 15 members. Three from each of the five RIRs. From this region we have myself, we have Louie Lee, who is our Chair, and Ron da Silva. Also, we recently added Ricardo from LACNIC this year, and you’ll notice there’s a blank spot from LACNIC. Alejandro recently stepped down. There’s going to be an election shortly to replace him.

So global policies. Normally here we talk about what are the global policies that are in process. There are none right now. So there’s really nothing for me to tell you about. If you do need to produce a global policy proposal, we can certainly help you with that. A global policy is a policy that involves the IANA and its relationship with the RIRs. It can also have specific regional number policies as part of the global policy.

But if it lacks some behavior from the IANA, then it’s not a global policy. And basically the way global policy development works is each of the five RIRs have their own Policy Development Process. Once the policy is submitted, it would be submitted to all five regions. It would go through each of the five region’s Policy Development Processes. When it comes to the conclusion of that, if all five regions have accepted the text in an open, transparent and bottom up way, then it would be passed to the NRO for review and ultimately the ICANN Board.

So what is the NRO NC’s role in all this? Well, once it’s passed through all five RIRs, they validate the process was actually followed, that there was adequate consideration of viewpoints. They ensure that the same text came out of all five RIRs; if it’s not exactly identical text, the NRO NC can do editorial writing to make it the same text. It’s the NRO’s NC’s job to make sure that rewrite does not actually substantively change the policy. And you could be surprised, a simple change of one word from may to must is certainly very substantive in terms of changes.

After the NRO NC processes it, they recommend to the ICANN Board to ratify it. The ICANN Board can ratify it. They can sit on it, in which case it will automatically become ratified after a deadline. They can ask clarifying questions, or they can send it back down saying that there’s some concern that hasn’t been addressed in which case the NRO NC, the NRO EC, and likely the RIR communities will have to take up that question and address it before sending the policy back up.

We recently had our ASO AC face-to-face meeting at Beijing ICANN two weeks back. We discussed a number of things there. We talked about the ITEMS review and looked at if there was any action items required for the NRO NC. We have to do some procedure rewriting. Some of that is NRO NC work. Some of that is NRO EC work, because one of the recommendations was the NRO should have a single operating procedure. But specific to the NRO NC, we need to review our global policy procedures. We also need to review our appointment to the ICANN Board procedures. There’s a lot of timelines in there and a lot of dependencies. It makes it very hard to follow those procedures that we need to fix them up and clean them up.

And there was also a note that there’s no procedure for appointing members of the NRO or externally to any ICANN body such as the NomCom. So we need to write a procedure for that. And we already have some draft language kicking around. We also had a brief discussion about RFC 2050 BIS, and we held a two-hour ASO AC workshop. In the workshop we covered a summary of what the Global Policy Development Process is.

We talked about the status of the IANA public consultations and had a discussion of the ITU council working group on consultation on IPv4 addresses. We also met with the ICANN Board. And lastly I wanted to tell you about the ICANN Board selection. This year seat ten is up to be replaced. That’s Kuo Wu’s seat. We had five candidates. We’ve gone through the entire process and have made a selection and we’ve sent the selection to ICANN for them to do due diligence; and once due diligence is complete, that candidate’s name will be announced. Any questions?

Tim Denton: Thank you. This is a lot of work to do. Hi, I’m Tim Denton and I’m the Chairman of ARIN Board of Trustees. My question is what kind of validation takes place that the rules were followed? How serious is it? Who does it?

Jason Schiller: So we have global policy facilitator team, which is one member of each of the five regions. So out of Louie, myself, and Ron, one of us would sit on the PPFT, and we would be particularly concerned about the ARIN discussion and the ARIN process. So we do go back and look at the wonderful material that Einar puts together. We look at the minutes from the meetings.

We make sure that, for example, the policy was proposed on list. That it has been on list for the appropriate amount of time, that there was discussion in a meeting. We make sure that all of the appropriate milestones have been passed. And in the past there have been cases where a policy has been tried to move forward that, for example, was not discussed on the mailing list for a sufficient amount of time.

In that case we did send it back and sent it back through the cycle a second time. So we do do some due diligence in terms of checking that the right policy was followed. We also do have quite a bit of discussions about some of the significant viewpoints to make sure that there aren’t concerns that the community hasn’t addressed. Because that is something that certainly could come back to us from the ICANN Board.

So certainly we do do look at the process. We do look at significant viewpoints. We also do look at the text. We scrutinize the text that comes out of each of the five regions, literally hold them side by side and diff them and look for every word change. And we have to intuit whether replacing LIR with ISP, does that significantly change the meaning of the policy? No it doesn’t. So we’ll have an internal discussion about that. We’ll come to a consensus. And we’ll decide in that case we can certainly move it forward.

In the case where a single word “must” is changed to “may,” even though it’s a simple change, one word, we deem it really did change the intent of the policy and that did not match the intent of what all the five regions had passed and in that case we recommended that this policy should not move forward. And it did not.

Tim Denton: Once you’ve done your check, and supposing that it’s okay, it goes up to ICANN?

Jason Schiller: Yes. We then recommend the ICANN Board to ratify the policy.

Tim Denton: Do they do any kind of checking themselves?

Jason Schiller: I’m not on the ICANN Board, so I don’t know the details –

Tim Denton: Or ICANN staff?

Jason Schiller: …of those discussions. They do have the ability to come back and ask us for clarifying questions. And I see Louie at the mic.

Louie Lee: Louie Lee, chair of the ASO Address Council. Similar to what the ARIN Board might do with a policy, the ICANN Board will look at it to see if the policy is implementable from their side and they also check to see if doing their fiduciary responsibility, then make sure that it’s not completely out of whack in terms of finances to implement that policy.

Tim Denton: Thank you.

Jason Schiller: Thank you. Any other questions?

(Applause.)

John Curran: Thank you, Jason. Next up we’re going to have an update regarding ICANN Durban, and Mark Elkins will come up and give that.

ICANN DurbAn - July 2013

Mark Elkins: Good morning, everybody. I’m going to start off with a 2 minute 9 second presentation film. I’m hoping that will roll automatically.

(Video playing.)

Mark Elkins: So that’s the official propaganda for people coming to ICANN. One should also know that if you’re a golfer, you should take your golf clubs as well. It’s a great place to go golfing. Some other considerations: I’m obliged to travel to other RIR regions once a year. And I tend to base my traveling on apart from attending the former meeting on what else I can do. So quite blatantly I came a few days early so I could go scuba diving. Nothing wrong with that.

One of the functions we hope to have in ICANN Durban will be held at the aquarium. And this time, unlike what happened in Capetown, management has already approached us and said if there are divers amongst you, then you’re most welcome to dive in the predator tank while everyone else is sitting outside watching the show sipping their martinis. So there could be some spectacular events happening.

(Laughter.)

The other thing to consider is Durban is one of the new gTLD offerings that should be happening. In fact, when you come to consider the world changing, you will probably on your way to South Africa pass through one or more gTLD cities. You will certainly get through to Johannesburg, which is another gTLD city, arriving at the final destination a gTLD city. And I guess that’s one of the things that’s happening is this whole new gTLD process. One of the ones I’m very excited about, of course, is Africa.

But we do have some competition on Africa. And if you have a clue of what’s happening, it’s actually kind of interesting. Conflict is always unfortunately quite interesting. Talking of conflict, I was in Ethiopia at an ICANN African event, and I met our opposition, very pretty lady. And I understood that she was in fact a scuba diver. So I did approach her and I suggested that she should bring her swimming costume and she should bring her scuba kit, and I invited her to dive with me in Durban. I may have forgotten to mention the sharks.

(Laughter.)

Anyway, karma may work. I have no idea. Thank you very much.

(Applause.)

John Curran: Many wonderful reasons to go to Durban. Okay, the next presentation will be on the RPKI delegated and services and the ARIN command line interface. So I’ll have Andy Newton come up and give that.

RPKI Delegated - ARIN Command Line Interface

Andy Newton: Good morning. I’m Andy Newton. I’m the Chief Engineer at ARIN. And today I’m going to be talking to you about two different things: Our delegated RPKI service that we released in February and a set of scripts we’ve released to open source which use our RESTful interface, allows people to interact with ARIN from the command line.

Delegated RPKI. In the routing public key infrastructure, RPKI, there are essentially two different types of CAs, and a CA is the certificate authority, is the body that actually issues the ROAs, which is the route origin authorization files, which are the whole purpose of the RPKI. Everything else with RPKI is just machinery to get the ROAs published. There are two types of certificate authorities. And you’re not going to find this in the IETF literature on the standards.

This is more of a term that comes from the marketplace, as it were. There’s hosted and there’s delegated. Now, hosted is what all the RIRs currently do today. We put our RPKI service out in September, and we have with our first hosted implementation. And what hosted means is that as opposed to the network operator using their own machinery and their own hardware security modules and having to go through all the trouble of coming up with security practices around running a certificate authority, the RIRs do that on behalf of the network operator.

Delegated, on the other hand, means that the network operator runs their certificate authority using their own practices and their own hardware and security. With delegated, there are now essentially two different types of delegated CAs that we have. We have the Web delegated, which is specific to ARIN, and up/down CA, which is what all the other RIRs are doing or attempting or are going to do, including ARIN. We’re going to do that as well.

But delegated is one of the ways we have come up with in order to get RPKI delegated CAs bootstrapped into this region before we can actually get the up/down service. So it’s kind of a method that we’re trying to use in order to get things going before we have full up/down service. When you sign up for RPKI as an organization, you make this choice between hosted and delegated at the time you sign up. So I have two screen shots here over each other.

But at that point where you say I want to be a certificate authority in the routing public key infrastructure, that’s when you make this choice, whether you want to be hosted or whether you want to be delegated. Currently, like I said, we only do Web delegated, but we’ll be doing up/down hopefully by Q3. So the big difference, again, between hosted and delegated. If you’re doing hosted, you’ll see this screen. This is the create ROA screen.

This is if you went to ARIN Online and you were trying to manage your ROAs, ARIN Online, you would have the screen where you put in the prefix and origin AS and you give us your signed key in order to – or signed ROA signing request in order for us to generate the ROA for you. So this is not what you would see if you were in the web delegated or the up/down delegated model. Instead, if you’re doing web delegated, there’s two pieces of information you have to give us. And this is information that gets put into your Certificate Authority Resource Certificate. That gets published in our repository.

The first one is the rsync URL. And the rsync URL is the pointer that we use to point to your repository. So when relying parties’ software comes along and it fetches our certificates out of our repository and it wants to know where your repository is, that’s how it finds it. That’s what the rsync URL is for. The second piece of information is a public key used for your certificate. Now, when your CA software is set up, you have to generate a key pair, a private key and a public key. You give us the public key, and that’s what we use to sign when we create your resource certificate in our RPKI repository. So those are the two pieces of information you would give us in order to do that.

And then there’s no – using this information, there is no need for an interaction with an up/down protocol in order to get going with RPKI. And then beyond that, once you are signed up, whether you’re doing hosted or delegated, we have these managed RPKI screens. And, by the way, we’ve been working on some usability and user interface designs at ARIN, and so RPKI section of our website is actually one of the places you’ll see us trying to figure out how to make the site more user friendly. But this is a screen shot. And the only difference between hosted and delegated – and this is for delegated – is that if you had hosted CA you would see a column for ROAs. Otherwise it’s really no different from the managing perspective of using ARIN Online.

Now, I did mention up/down. We are working on the up/down software right now as we speak. There are software developers back at the office coding it up. And what we mean by up/down is compliance with a standard out of the IETF SIDR working group, RFC 6492. Now, that RFC actually doesn’t say up/down anywhere in it. I think it says provisioning, something or other, public key infrastructure. But we call it up/down. That’s the term that everyone seems to use.

What it means is that the up is the parent CA and the down is the child CA. So up/down is a protocol for doing certificate management between a parent and a child certificate authorities. In this case, for RPKI, up would be an RIR, or ARIN in this case, and down would be the network operator. Unlike web delegated, the – unlike web delegated, up/down requires a different type of bootstrapping mechanism. It uses this file called IdentityXML. This is not a standard. This is one of the problems with up/down at the moment. The IETF is going to take on this work, or they’ve said they’re going to take on this work, but the problem is there’s no standard for bootstrapping up/down trust authorities in the – between an RIR and a network operator.

But there’s a de facto standard. It’s called the identity.xml file, which ISC software generates. So if you’re running a certificate authority, and at the moment your choices are limited as to what kind of software you can use, either write your own or use the ISC code, you have to generate this identity.xml file. You hand it to us. You’ll log in to ARIN Online, upload this file, and that will establish the trust relationship, not in the RPKI, but in our web system between ARIN and the network operator.

This probably will change. So since the IETF will start working on this or has indicated they’re going to start working on this, and the author of the original version has already changed it twice, as indicated he plans on changing it again. So it’s going to be a little rough and tumble there at getting this trust mechanism going between up/down certificate authorities. And that is it on that.

The other thing I want to talk about is a set of scripts that we’ve just released that are used for talking to ARIN’s systems, RESTful web systems using command line. And these are some scripts that we open sourced. We put them on projects.arin.net. You can download them. They’re open sourced under ISC’s derivative BSD license. You can take them, use them, modify them, you can redistribute them, you can leave them in the parking lot on a floppy disk, it doesn’t matter.

But you can go to projects.arin.net and you can download them. They’re written in Ruby, so they should run on a Mac, they should run on Windows, they should run on a Linux box. They’re pretty cross-platform. And they’re really designed for people who like to do things from the command line interface. Systems administrators, sometimes programmers, people like that, who are not inclined to go hop onto a website.

They use our RESTful Web services, both WhoisRWS and RegistrationRWS, to talk to ARIN, and that’s what they’re doing behind the scenes. So there’s no real magic there. There’s no special API they’re taking advantage of. The same API that you could write your own software to. Now, these scripts started life as simple scripts for us to do gap analysis internally to figure out where we were missing functionality in our RESTful Web services and what we did is we turned around, kind of cleaned them up, documented them and then released them because we thought they were just generally useful.

But their hope – their intended original purpose was to try to figure out where we had gaps, but now they’re available. Speaking of the RESTful web services, and this is interesting information here: So last year we announced that the RESTful queries for Whois had surpassed the traditional port 43 Whois queries, and that happened in March of last year. And we released Whois RWS I believe in 2011. Now we can say that for the registration RESTful web service it is surpassing the template usage. It doesn’t do it every single month. But for the totals for the year actually show that we were getting more traffic for the registration RESTful web service than we are for templates. In some months it’s quite significant, much more than the template traffic.

So that’s pretty interesting information. So the RESTful web services are actually seeing a lot of uptake now. So the first script in this series of script is called ARIN Info, and what it does it’s kind of like a Whois replacement, but it’s very specific to ARIN. Most general Whois command line clients, they’re not really geared towards ARIN’s data model so they don’t have a very good understanding of how things work at ARIN specifically. Well, this command does. If you take a standard Whois command line client, they’re usually geared towards general IP queries and general domain queries, mostly domain queries. IP queries seem to be a second-class citizens in that space.

Here we have an example of the ARIN Info command, and what it’s doing is it’s querying for our CTO’s name, Mark Kosters. It recognizes Mark Kosters not as an IP address or as a domain name but as a person’s name and goes and grabs it out of the database and displays it. Has different levels of display usage. So you can turn on verbosity if you want to see that. You can also turn it down to be very terse if that’s what you want. There’s a lot of options.

The other thing that it does is it caches the information. So if you’re querying us a lot and you tend to query a lot of the same information over and over again, it will cache it on the client side so you won’t have to do that round trip over and over again for that information. As I said, the program actually knows quite a bit about the data model that ARIN, that’s specific to ARIN, and so here you see a tree view of the data looking up the ARIN ops organization. And ARIN Ops is the organization that we have at ARIN for putting all our infrastructure IP networks and ASNs under points of contact.

So here you see it displaying the points of contact and autonomous system numbers and the networks. And it’s doing it. It knows how to relate all the information in a tree structure, whereas the general Whois client can’t do that. Again, this is very specific to how ARIN’s data model works. You’ll also notice that the names are sorted. The AS numbers are sorted and the networks are sorted. That’s kind of new as well. One other thing you can do, is once you’ve queried some information and it’s cached it. You’ll see this tree structure here. You can actually dig down into the tree structure with a short notation as opposed to having to retype.

So if you wanted one of the first NetHandle out of this tree, you would say 1.3 on the command line and it would actually know that’s what you meant, was the first network in the response there. And it would already have it cached and it could pull it right up. We have two other programs in the set of scripts. One is for managing Points of Contact. So if you ever get that email telling you to come verify your Point of Contact at ARIN, you don’t have to actually log in to the ARIN Online to do that anymore; you can use the POC command.

And what that will do is that will actually go to our registration service, our registration RESTful web service, pull down your POC information, populate it into a template, pull it up into an editor, and then you can just change whatever you need to change. Or if you’re not changing anything, you can just save it and then it shoots it back to us and your POC information is updated. Of course, you can also create – delete POCs from the command line as well. We also have these things called reports that we generate automatically. If you ever logged into ARIN Online, there’s a report section you can ask for WHOWAS reports, association reports, and reassignment reports.

And what that does is that creates a ticket and we generate these reports in the background. We do it asynchronously so we don’t overload our systems. And then you have to come back a little later, maybe a minute later, and there’s a ticket waiting for you with an attachment with that report. Well, from the command line now you can just actually ask for the report directly there. You can do that from the command line without having to log in to the system. Now, once you ask for a report, it would be kind of nice to be able to get the report without having to log in as well, and so there’s a ticket command, which actually does that.

So what the ticket command does, it can download all your ticketing information from ARIN, store it locally on your computer, and you can get the attachments from – you can detach an attachment from the ticket and then view it. So if you ask for a report, in this case you’ll see the first ticket in there is an association’s report, you could actually detach the association’s Excel spreadsheet and then view it, and you’ll be good to go. It will also show you all the ticket information. It shows the different replies and so forth that are going on.

One of the things you can do with a ticket command is you can also reply to tickets. This is an example of where one of our registration analysts, Ed Diego, and I were playing with it, and I was filling out a question, and he was replying to me. But you can have a back and forth conversation with ARIN using this command if you want to. So that also stops you from having to log in to the system if that’s not the mode of operation that you’re in.

Finally, and this is I think the most useful command of them all, is you can manage your reverse DNS from the command line. Now, even when we did this with templates, even though we don’t do that anymore, you have to do a lot of cutting and pasting to manage your reverse DNS. So NS records sometimes aren’t a big hassle. But if you’re doing DNSSEC, having to cut and paste DNS records is painful, especially if you have a lot of zones you have to update. There’s an RDNS command. What the RDNS command will do is go and try to parse the zone files, including the DS sets.

If you ever use zone signer and it creates the DS zone snippet for you, it will actually go look for that file as well. It will read multiple files, multiple zone files, and it determines what the delegation is that you need for that, and it will actually go pull the NS and DS information out there, show it to you to make sure you think it’s okay, and then it will go ahead and take that information and upload it to ARIN.

So that would save a lot of time. For people managing reverse DNS it’s quite a pain to have to go do all this cutting and pasting out of your zone files and then telling ARIN or any RIR for that fact where your reverse information is. So this would save a lot of time for people. So I think it’s very useful. And that is it for the scripts. We do answer questions about these programs and about RPKI as well on the ARIN Tech Discuss list. So if you have any questions about them you can come and ask – you can download the programs, play with them, and shoot some questions over to “arin-tech-discuss” and we’ll answer them for you. Or if you have questions now, you could ask them.

John Curran: Any questions now for Andy?

Scott Leibrand: Scott Leibrand, Limelight Networks. Thank you very much. This is awesome, way more useful than a lot of the stuff we see out of RIRs and otherwise, so good job. My only question is: What’s the login authentication model? I think you might have said that, but how do I make modifications?

Andy Newton: I went through that, didn’t I? It uses API keys. We’ve been using API keys for the RESTful services. It’s the standard API key you would use. In fact, the 5.0 templates also require API keys. If you have an API key on your web-user account, there’s a config file for these scripts that use the config file. Go in there, put your API key in and use it. One thing I forgot to mention is that you can also point these commands at our OT&E environment. If you have access to the OT&E environment, so if you want play with commands without touching your production data, you can use that as well before you actually have to start using them for real. Yes, Sandy.

Sandy Murphy: Sandy Murphy, SPARTA. I, of course, have a question about the delegated model. You said something about the IETF has spoken about taking this on. So forgive me, I’m working for a chair of the SIDR working group, I don’t recall anything being presented to the SIDR working group yet. So am I missing a reference to what you’re talking about?

Andy Newton: So yes. In Atlanta Rob Austein stood up and there was a discussion about this very issue.

Sandy Murphy: Okay. So this is the draft that he mentioned that I asked him about.

Andy Newton: Yes. It hasn’t been formally adopted by the working group. I’m not trying to say the IETF is actually working on it, but it’s been presented. And anyone who reads the tea leaves, I think there’s unanimous consensus about the IETF doing this.

Sandy Murphy: Okay. I was just trying to make clear the reference. I kind of figured that had to be this mysterious other draft. So I did want to say something about the up/down protocol. You presented it as ARIN talking to a customer, a network operator, and that is exactly one of the cases where the protocol would be used. It’s also intended for operators who are talking to their customers or people to whom they’ve allocated. So the idea of having a common trust model for how you authorize that communication involves more than just RIRs talking to members. And I encourage everyone to play a part in that discussion, because there will be different requirements for different people. Okay?

Andy Newton: Yes. Thank you.

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

(Applause.)

John Curran: Okay. Next up on the schedule I’m actually going to give the NRO Update. And, yes, slides appear. Look at that. Wonderful.

NRO Activities Report

John Curran: So I’m John Curran. I am not the Chair or Vice-chair of the NRO. That role rotates, as I talk about, but I happen to be here and the slides are here, so I’m going to present them. So what’s the Number Resource Organization? It’s the vehicle for inter RIR cooperation and representation. It’s a lightweight unincorporated association formed by the NRO MoU in 2003.

Our goal is to protect the unallocated Number Resource pool, promote and protect the bottom up Policy Development Process, act as a focal point for input into the RIR system, and fulfill the role of the Address Supporting Organization within ICANN. We have an executive committee. One appointed representative from each RIR plus RIR board and staff observers. Generally the Executive Director/CEO is the appointed representative on the Executive Committee. Three officeholder positions rotating annually. Decisions are made by unanimous executive committee agreement.

We have a Secretariat rotating, and now we have an executive secretary position. We have German Valdez, who has been appointed as our Executive Secretary. You can imagine with five RIR execs all traveling, offices rotating, a little bit of continuity is good from time to time. So now by having a permanent role as Executive Secretary, German will help with that function. We also have coordination groups that contain the leads of each of the various functions. So engineering, communications, public affairs, and registration service managers.

So when you get things like an NRO joint stats report, that’s because the RSMs, registration service managers, have all worked together through the NRO so we can give you one report that has consolidated data and you don’t have to consolidate it yourself. Our executive committee in 2013: Our chair, Paul Wilson of APNIC; our Secretary, Adiel of AFRINIC; Raul and myself are on the Executive Committee; and Axel is our Treasurer. The Secretariat is hosted at AFRINIC this year.

ASO. I’m not going to go into too much detail because Jason covered it, but the ASO is a supporting organization of ICANN and the ASO has a number of tasks it does. It’s responsible for global Number Resource policy work. It appoints two Directors to the ICANN Board. It appoints representatives to various bodies, advises ICANN on Number Resource matters. We have an Address Council which does a lot of those tasks. The RIR coordination is generally done by the Executive Committee and the tasks coordinating with ICANN is done by the Address Council and it consists of 15 individuals, three per region. They have - are, as we have covered before, in the ARIN region, Louie Lee, Jason, and Ron da Silva.

And we have to keep NRO running because we have expenses. We have expenses in terms of documentation and presentations we do, when the NRO goes and represents the RIR system.

But we also have a significant contribution to ICANN each year, which has been $823,000 every year since ICANN’s formation. The expenses are allocated by revenue in total IPv4 resources. So NRO’s total expenses are allocated. Percentage wise, ARIN is – pays about 18 percent of them.

ASO review. There was an ASO review conducted per ICANN bylaws. They review all the supporting organizations. In 2011 there was a report. We sent a response, and now we’re busy on the implementation of that response, things like clarifying the history of the RIRs, making sure the website is consistent, making sure that the terminology that we’re using is understandable to the ICANN community in addition to the RIR community.

Global policy. We handle global policies. The most recent one is global policy for post exhaustion IPv4 allocation mechanisms, and it was ratified by the ICANN Board in May of last year. APNIC, ARIN, and RIPE have returned resources to the pool. At some point, that will actually start being reallocated out. Total space in the pool is now about 1.2 equivalents of a /8.

Internet Governance Forum. We participated extensively in the IGF. We participate in the Multi-stakeholder Advisory Group that helps set the agenda and theme of the meetings, and then we actually attend the meetings and run workshops. Last year’s meeting was in Baku, and the NRO contributed $75,000 to IGF itself, its operations. And then we held workshops, including moving to IPv6, certification of number resources, and participation in several panels, including the closing remarks for the final report.

We participated in the open consultation that was held about the IGF in February, trying to figure out where the IGF goes going forward. And the UN has a CSTD group, council trying to figure out IGF improvements, which we participate in. We also participate on the technical advisory committee of the OECD, the Internet Technical Advisory Committee, and forms that are set up by various organizations that are looking for input on Internet governance.

Happily, the fact that we share this load among all the RIRs means all five of us don’t have to cover all these events. The World Telecommunications Policy Forum is actually going to take place next month. We nominated people to their expert group, and we’re encouraging the Secretariat to continue opening its conferences to all stakeholders, not just member states.

WCIT. Extensively participated in WCIT. And as noted and as we’ll talk about a little later, we believe that the inclusion of Internet matters is not appropriate for the international telephony regulations.

IPv6 outreach. We’ve asked the ITU Secretary General to open discussions with us regarding IPv6 capacity initiatives. They have a number of documents that encourage the ITU to do capacity building. In other words, increasing awareness and education about v6. We’d like to work with them. We’ve sent some correspondence and are hoping to see something back. We also noted that ICANN received a renewal of its IANA functions contract. We welcome the decision and noted that continued discussion about the relationship with the US government and ICANN is probably a good thing. You can find our correspondence in our documents folder.

Other developments. We held a retreat meeting in February in Singapore. This was both the NRO EC held a retreat, and then we met with what’s called the “I*” Group, which is ICANN, ISOC, the five RIRs, the representatives of the IETF, which is the IAB and the IESG, and W3C attends, and we talk about the Internet standards process and how that’s going.

We decided at our workshop to increase IGF contribution in 2013 to $100,000. IGF serves as the only open, transparent forum that you can participate in to talk about Internet governance matters. So we’re trying to not only encourage that in our speaking, but we’re trying to encourage it with our funding as well.

We established some coordination groups on – formerly the registration services coordination group has been an informal group. We formally said we’ll have an NRO coordination group in registration services and they will rotate like the others, and an IPv6 coordination group to help us coordinate messaging on IPv6 among the RIRs.

We also did some discussion on RPKI project management regarding what we’re all doing and whether or not we’re all trying to aim for the same dates for the same services, such as you heard, things like up/down. That concludes the NRO update. I’ll take any questions.

Owen DeLong: Owen DeLong, Hurricane Electric. You mentioned an $830,000 voluntary contribution to ICANN. Given that ICANN is going into the “let’s sell off TLDs to make money fast” business, is there any thought of reducing that?

John Curran: So when ICANN was first formed, the RIRs were fairly well organized, and we said we’ll be part of this group, the International Coordination of Assigned Names and Numbers, we’re ready, we’ll be here, and we’ll fund it, we’ll fund some initial funds. And the first year we did that we, I believe, were probably more than 90 percent of the funding that ICANN had on that first year. The domain name community came to the table, and over time ICANN has significantly grown. ICANN is ICANN including all the domain coordination functions. Sort of on the side of ICANN.

ICANN’s original model was supposed to be a very small, lightweight organization, but because DNS is embedded within it, it’s a pretty big organization today. And it has ample funding, as you know. I think as long as we participate in ICANN, we should continue to commit them, commit funds to it. If it turns out that ICANN is not relevant to the RIRs and vice versa, I would imagine not funding it. But right now, as though we only take 2 percent or so of ICANN’s mindshare, we also should pay 2 percent or so of their budget. So it’s corresponding to the size of the organization and the attention we get.

There are dedicated staff at ICANN who help the RIRs. There are folks who help Louie Lee and Jason and the ASO get its work done. There are costs for ICANN to help us with coordination. And so we do get benefit from supporting them. Does that answer your question? Okay. Other questions? I see someone at the left microphone.

Sandy Murphy: Sandy Murphy, SPARTA. With some cringing I approach the mic, because this is a question that I just gotta get an update on. You spoke of ICANN. You spoke of the IANA function to ICANN. The NRO has communicated with ICANN in times past about beginning dialogue about performing the functions of the root of the RPKI hierarchy, and other – one further statement after that about how you might go about that. Can you say anything about the progress?

John Curran: Sure. To be clear, the IAB sent a message saying if we’re going to have resource certification, it would be nice if we had a single trust anchor. The NRO sent a message back to the IAB, materially the same thing, saying: We heard you. We believe a global trust anchor is also useful. So the alignment of intent and the messages can be seen, have been gone back and forth.

Now, implementation. Much more difficult. The actual implementation of something like that is predicated upon the five RIRs each first understanding how the structure of a global trust anchor would work and how resources below that would be hung so that every time a block moved between regions we don’t have to resign the root.

And so I think you’re aware there is work going on, it’s slow within the RIRs, to propose a model for how blocks are arranged within that hierarchy that provide reasonable swing points. Once that draft is done and working with IANA on that, the ICANN team – the IANA team at ICANN, then we’d hope to propose it to the IETF and say this is how we think it makes sense to do. But I think we have to write that up before we can actually implement.

Sandy Murphy: So is there a timeline?

John Curran: So unfortunately we’re simultaneously implementing RPKI at the same time as we’re worried about a global trust anchor for RPKI. Right now the focus has been for everyone to get their services out, including up/down services. I think once we get past the point of having our initial services out, there will be a lot more focus on building a TA above everything. I don’t have a timeline.

Sandy Murphy: Thank you.

John Curran: Thank you. Okay. Any other questions on the NRO report? No. Thank you.

(Applause.)

John Curran: Thank you. Moving right along, the next report will be given by John Curran who will give a fee update regarding ARIN’s fees. Slides. Coming soon. Thank you, John, for that great introduction.

Fee Schedule

John Curran: So fee schedule update. I’m John Curran, President and CEO of ARIN. ARIN has a new fee schedule. It aligns the ISP IPv4 and IPv6 fee schedules for ISPs into a single set of registration services where each ISP is in a certain category, pays for that category, and has up to a total holdings of IPv4 and IPv6 address space. So rather than having a v4 fee and a v6 fee, you have a category fee and it includes both. This means every ISP who has IPv4 resources can get IPv6 resources, up to the same category level, and it doesn’t change their billing.

It provides $100 a year end user maintenance fees per address block and AS number. So if you’re an end user, your maintenance fees are instead $100 per block. If you have three IPv4 blocks and one IPv6 block and two ASNs, you’ve got six blocks, you’re going to pay $600 a year. Legacy fee holders pay the same as end users if you’re under an LRSA. Some of the LRSA’s cap that and your fees will actually only increase per the cap of $25 per year up until your fees match the end user fees. Legacy fee schedule is the end user fee schedule now.

But obviously your contract provides your ramp up, so you’ve got to ramp up. The fee schedule structure was presented at ARIN 31 – ARIN XXX in Dallas and discussed, and we had a formal consultation afterwards. And we got comments. There was some comments and feedback. And the Board tried to incorporate what could be done.

It was adopted by the ARIN Board in January 2013 to take effect on July 1st. And the reason for delay was so we could have an online calculator, for example, so you could go in and log in and see what your fees would be. That has been implemented. We actually corrected a typo in the original schedule because originally we had the extra small and a meaningless number and not the one that mathematically it should have been. That’s been fixed.

The other thing I note is that one change that people didn’t notice that I’d highlight is you get one invoice for each ORG ID. If you have three ORG IDs, you get three invoices, because we see you as different organizations. Sometimes organizations have multiple ORG IDs because they have multiple ORG IDs. They have a wireless and a wire line business unit, for example. So each organization receives one invoice. It covers all the resources held.

The fee change is revenue neutral for ARIN. We’re not raising fees; we’re not lowering fees in terms of what we’re trying to do for total revenue. What we’re doing is establishing a fee schedule that’s long term and stable. It should provide ARIN what it needs in order to recover its costs regardless of what happens with v4, v6. It covers the full range of possible holdings by any organization. So people can make policy with a predictable schedule as a background. Now, this is wonderful. The next slide is supposed to be the question slide. Okay. Any questions? It’s not. So let me tell you what the next slide is.

We only got modest feedback in the original discussion. Since that time, since we announced the schedule, we have had no shortage of feedback on the new schedule. I would have to say we have an abundance of discussion since that time. And a lot of the discussion is about fairly structural matters, things like we need – still need additional IPv6 fee waivers. We need to throw out the idea of basing it on total resource holdings and base the fees on organizational revenue, which is what some trade associations do, for example.

Maybe fees based on total resources held, because if you’ve got records in, then why would we treat people different. If ARIN’s costs are generally proportional to the records, why would we treat instead based on address size and total address holdings. Or how about fees for allotted addresses. Let’s just have a fee per address. If you have a lot of them, you pay a lot. Obviously when we get to v6 we’re probably talking about networks, not addresses. Because there’s no fee that you can multiply a v6 address by that results in a reasonable number.

So IPv4 addresses or IPv6 total networks, and we’ve got a lot of discussion on these. We’ve got a lot of people who feel very passionate. The fee schedule is set by the ARIN Board. It generally has me work with the FinCom for a period of months, going up until any recommendation. We model what it means to ARIN, the cost, the revenue, what the change risks. There’s a bit of work that has to go into a new fee schedule so we don’t end up precipitously doing something to our billings. And it’s important work.

We can’t just jump from all the discussion to a revised fee schedule, particularly because this discussion has a lot of different forks in the road. It goes a lot of different directions, and we need to make sure we’re all aligned on a direction. And it might not be the one we’re using now. Right now we’re using one now which is based on total holdings for ISPs and total records for end users. So the ARIN Board of Trustees has directed that the finance committee convene a fee structure review committee which will include selected volunteers from the community and will consider various long term fee structures, reporting back to the ARIN before the next meeting.

We have to look at the pros and cons of some of those things on this slide, and we want to get some passionate people involved in doing that so that we can talk about what those directions mean. So selected volunteers. Volunteers needed. It’s a complicated process to volunteer: You send me email. I’m going to take all the people who volunteer. I promise, if you volunteer, I’ll include your name and I will send it to the FinCom. I do not think they’re going to have a dozen volunteers. They’ll have some number, three to five, I don’t know what it’s going to be. It’s really a Board decision.

But they’ll bring in some number of volunteers and you’ll work through not just the one you’re passionate about, but you will work through the pros and cons of everything that we’re talking about, all the various structural aspects, with the goal that this fee structure review committee will come back to ARIN before the next meeting or at the next meeting and present its findings. Now the question slide. Microphones are open.

Andrew Dul: Andrew Dul. I support the new fee structure as it exists now. Given the length of controversy that currently apparently exists, are you considering delaying the implementation given that you’re now having a formal review of the process, or are we going forward with the fee schedule as published?

John Curran: We’re going forward with the fee schedule as published. This is a committee to review the structure of the fee schedule and see if it’s on the right direction.

Andrew Dul: Excellent. Thank you.

John Curran: Any other questions?

Scott Leibrand: Scott Leibrand, ARIN AC. I noticed a bullet point that said you corrected a typo about XX small. Is that specifically with regard to the /40?

John Curran: On the schedule it is now corrected. It’s now /40. For IPv6 XX small, if you look on the website, you’ll see it’s updated.

Scott Leibrand: So that sets the stage for our policy discussion later.

John Curran: Sheer coincidence. Yes. Nate.

Nate Davis: Related to the small typo, coincidentally the fee calculator represents now the corrected typo. So it will calculate the fees according to the /40 boundary for the extra small.

John Curran: Right.

Owen DeLong: You indicated that the new fee structure is revenue neutral, and yet I think – Owen DeLong, Hurricane Electric and currently representing the ORG IDs DeLong and DeLong Z, so I have a second question about that. But the first question is you say it’s revenue neutral, and yet I suspect that within the end user fee category it is revenue neutral at best and that for most organizations it is substantially revenue increasing.

John Curran: Right. I’m actually talking overall it is revenue neutral. It is 20 percent across all the end user organizations’ increase. You can go look at the October presentation to see that. And it does mean that some organizations with a lot of resource records pay more, both the DeLong and DeLong Z. Would either of them like to ask a second question?

Owen DeLong: Yes. The second question is the only reason I have two ORG IDs is because ARIN couldn’t make me one ORG because I have LRSA and RSA. Are you going to fix that?

John Curran: If you want to put them all under the RSA, we will fix that.

Owen DeLong: No, I don’t want them to be separate ORGs just because they have different agreements. You’ve got people with different RSAs under one ORG.

John Curran: Right. But the terms of those two agreements are different. So once you’re willing to move to a single set of terms, we can combine them. It’s the same that applies to RSAs.

Owen DeLong: No, you have people with different versions of the RSA on different records operating as single ORGs.

John Curran: But they’ll now get separate invoices if they’re separate ORG IDs.

Owen DeLong: No. You have people with one ORG ID with different versions of the RSA.

John Curran: Correct.

Owen DeLong: That are operating as a single ORG.

John Curran: Yes. You can have –

Owen DeLong: I have an LRSA and RSA. They’re different versions of the RSA, and I want them under a single ORG.

John Curran: Yes. You can have one ORG ID with different versions of an RSA. That’s fine. You cannot have an LRSA under that ORG ID because the terms of the fees are different. It’s a different fee. The fee schedule’s the same, but the LRSA provides certain protection of the fees. That’s the only difference between the two schedules at this point. Between the LRSA and the RSA, the only difference is the fee paragraph. If you find another difference between those two schedules, let me know.

Chris Grundemann: Chris Grundemann. I’m wondering for the fee structure, if it’s all based on size, and so the question is: Is that size just space that’s registered from ARIN to an ORG, or is it also space that they may have from an upstream?

John Curran: It’s space assigned by ARIN. It’s not from an upstream. No, that would be colorful in a number of ways. Okay. Any other questions? Okay. Thank you, John. Thank you, everyone.

ARIN-2013-2: 3GPP Network IP Resource Policy

John Curran: We’re going to resume. We’ll now start the policy section of our discussions, and we’ll start with the consideration of ARIN 2013-2: 3GPP Network IP Resource Policy. The history of this. It originated as ARIN Proposal 184 in March of this year. The shepherds, Scott Leibrand and Rob Seastrom. It was accepted as a Draft Policy on the 21st of March. The text and assessment is online and in your Discussion Guide.

The purpose of the policy is to change the way that ARIN counts utilization for mobile network operators. The proposal offers two possible options. Instead of the current policy applied to mobile operators, which applies an 80 percent utilization, the first option would be to counter block utilized if it’s 50 percent in use by customers. The second would count the total number of subscribers as the utilization measurement.

Status at other RIRs. No similar proposals or discussions. Staff assessment. This is new a Draft Policy, and so it’s just out there. We’ll do an assessment when the AC thinks it’s fully developed and they submit it for us. We’ll do a staff review and legal assessment. So at this time I’d like to open it up. I’ll have Scott Leibrand come up and do the AC presentation on the proposal.

Scott Leibrand: Good morning again. This draft policy as we already heard is proposed to deal with some potential issues with running IPv4 in cellular networks, aka 3GPP. So this summary is what we just talked about. I wanted to have this in here for talking about later possibly. There’s some technical background that’s in your Discussion Guide. I don’t expect you to read it up here on the screen. But there is a pretty solid problem statement here in terms of why it is that some of these networks are having trouble with assigning addresses in such a way that they can get to ARIN’s 80 percent utilization and qualify for additional space.

This slide outlines and your Discussion Guide outlines what that technical topology looks like and why it is that addresses are assigned in the way that they are in this particular network scenario. I’m not going to go over the details, but if you haven’t already read that in your Discussion Guide and have any questions about the technical reason for why this is necessary, take a look at that. But the actual problem statement, I think, is worth going over in a little more detail here. Some of these networks are using non RIR assigned space, and they’re using that behind NATs or for internal use to number within their network, but there’s not always enough RFC 1918 space for some of the larger networks.

So in some cases there have been – they have had to use other space that’s not assigned by the RIR and not RFC 1918. As you might imagine, that space is subject to actually being assigned to networks and used on the Internet, and that’s going to be less and less possible as the remaining IPv4 resources get put into use on the global Internet.

So that’s a concern that they don’t want to be in a situation where they’re using space that someone else is using on the public Internet inside their network. So in order to solve that problem, they want to use RIR assigned space, AKA ARIN space, to number that network, but to do so they have to run through ARIN policy and show that they’re using enough of the space and they’ve been having some trouble meeting those needs. So the potential solutions that have been outlined for solving that problem include the ones that John summarized.

One would be to look at the current utilization metric that we always look at, which is simultaneously attached users. So if you have a phone that doesn’t happen to be connected to the Internet right now because you don’t have any push notifications – I mean, smartphones tend to be always connected to the Internet. Feature phones tend to only connect on demand. So the way they measure utilization in a cellular network is based on the number of users that are simultaneously attached at any given time.

Currently the requirement is that they have to have 80 percent simultaneous attachment in order to get additional space. The problem, as you can read in the NAT, is that because of the way the network is architected and the requirement for failover between different nodes in this particular architecture, they can’t get to 80 percent without being unable to serve a bunch of customers in the event of a failure. So if we continue to measure based on simultaneous attached users, the suggestion in this proposal is that we drop the utilization threshold to 50 percent.

Another option, rather than counting simultaneously attached users, would be to count total subscribers. And so that would count all the cell phones that are on the network in that area, whether or not they happen to be using the Internet at any given time. And if you use that metric, they could get – they could use the 80 percent that we do today or even something higher and still be able to accomplish the goal that’s trying to be accomplished here.

So those are two options that were presented in this. You may have noticed that we don’t actually have policy text changes to the NRPM in this proposal yet. The reason for that is under the new Policy Development Process, the first step is getting a good problem statement together and getting consensus on whether that’s a problem that we should actually fix and then working on the actual policy proposal text. We have refrained from proposing text until we have this discussion with the community. So one of the primary goals here is to get input from the community on, A, whether this is a problem, and, B, whether the solutions proposed would be good ones or whether there’s other ideas for how to solve this.

So I’ll go a little bit into the pros and cons of solving this. The discussion that we’ve had on the Public Policy Mailing List with regard to whether this is an actual issue, there’s been some quite substantive discussion there. If you haven’t read it, I would encourage you to do so. In my estimation, this does seem to address a real problem for at least some cellular operators, so there does seem to be a solid problem statement here, a real issue that could be solved. Solving this problem would allow those operators to get rid of the address space conflict that I mentioned before and potentially reduce their use of network address translation.

It would also have the effect of making things a little bit more similar to another policy that we have existing that applies a 50 to 80 percent utilization threshold to ISPs serving residential market areas. That was originally called the cable policy because it applied to technologies that involved a shared medium where addresses had to be assigned to the equipment and then the number of addresses had to be assigned based on the number of users there were in that market area regardless of how many were actually using the service.

So the author feels that this is a very similar issue, and the fact that this proposal would seek to make the policy for cellular networks similar to the policy for fixed line networks serving the same types of users might be a benefit as well. There have been – there’s been some serious discussion on the list about why this may not be a problem that needs solved or why the solutions may not be ideal as proposed. The big one here is that anything that we do to make it easier for large operators to get large amounts of additional space will likely mean that the ARIN free pool runs out sooner.

Some people would consider that to be a drawback. I’ve heard a few people who would express the thought that, well, let’s just go ahead and get the addresses out to people who can use them now and move on. So depending on your estimation of what’s best for the long-term interests of the community, that may be a drawback or may not.

But there’s other drawbacks that have been identified on the list. One is it’s not entirely clear how broadly this problem exists in the cellular networks. We know that the author is aware of it in at least one case. There’s been some sentiment expressed on the list that in certain other cases this isn’t a problem.

So one of the things we need input from the community on is: Is this a problem in other networks? Is this something that should be solved for the general case? There are some potentially outstanding technical questions as to why this needs to be solved in policy and couldn’t be solved with technology over the change in internal addressing plan or operations. I don’t want to get into too much detail as to what those solutions would be. But it is a valid concern. If we are trying to solve something in policy, it should be a problem that is general case and needs to be solved in policy. If there’s an easier solution that doesn’t involve policy changes, it’s probably at least worth bringing that up.

And then there’s some sentiment that’s been expressed that really we’ve made enough tweaks to the v4 address policy. This is usually referred to using the deck chairs metaphor, and there’s some people who think maybe we shouldn’t be continuing to change IPv4 policy when we’re this close to exhaustion.

So that’s a lot of stuff to think about, but I wanted to highlight a couple of points that I as the shepherd would like to get input on and I think the rest of the AC would like input on to decide whether we should develop policy text around this and what it should say if we do. The first question is pretty simple: Do you understand the problem statement? If you have read through what’s in the Discussion Guide and you’ve watched this presentation, I hope it’s clear, but if it’s not, I can do my best to explain what I understand the problem to be and we can discuss that.

And then is this an important problem that we should try to solve? I don’t have the answer to that, and I’m looking for input from the community on whether this is something that we feel as a community is a problem we should solve. If so, how should we solve it? And that’s where we get into the details of 50 percent simultaneously attached, 80 or 90 percent of total subscribers, or something else. So that’s all I have. I’d like to open it up and turn the microphone over – so is it discussion or an informational session or –

John Curran: You can –

Scott Leibrand: John says go ahead. Go ahead and get the remote question in.

Cathy Aronson: Marla Azinger, Frontier: I understand the need, but why is this only addressing wireless and not all pool environments like DSL or retail service providers? There are many services where the 80 percent rule is not realistically achievable, and I only support it if it creates a solution for all having this problem.

Scott Leibrand: Thank you. That very much goes to my question about how broadly this applies. So maybe rephrasing this question: How broadly does this apply to network operators generally? If we can construct a solution that addresses the needs of more than just a handful of companies, I think that’s probably a preferred direction. So I would encourage anyone else, Marla or anyone else, who is interested in helping us craft text that actually applies to everyone this problem is relevant to, to please speak up either now or on the mailing list. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric. Going back to the slide, yes, no, and because of the previous answer to No. 2, irrelevant. I don’t support this pony as written.

Scott Leibrand: Thank you. Rear mic.

Dave Kessens: Dave Kessens, Nokia Siemens Networks. I still don’t understand why this cannot be done under existing policy. I mean, basically we’re talking about the pools. But it’s like a static assignment for a user. And that’s perfectly fine. There’s nothing against setting assignments for users, and that’s what this is.

Scott Leibrand: Let me see if I can summarize it in a way that’s useful. These operators allocate a pool of addresses to what is essentially a region of the country. I don’t remember the exact term. But that region has a bunch of addresses that are used as a pool to assign all of the end users, all of the cellular network devices that are in that region. If there’s a failure of the devices serving one region, then all of the users are switched over to the adjacent region.

So the pool assigned to each region in this architecture is sized such that it is approximately double the number of simultaneously attached users that they get at a particular time. So having done that, the utilization of these pools is essentially 50 percent. And that makes it quite difficult for them to go back to ARIN, which requires an 80 percent utilization threshold to finish renumbering out of the squat space that they’re using onto general space. So is that clear? And does it address your question at all?

Dave Kessens: So I understand how the technology works for various obvious reasons, because I work in this industry. But it’s like why can this not be treated just like one IP address per subscriber? What makes this situation so special? I think this should be handled under current policy and it’s about interpretation about the current policy. And I think the interpretation should allow for –

Scott Leibrand: So are you outlining an interpretation that basically looks at total subscribers instead of simultaneously attached users?

Dave Kessens: Yes.

Scott Leibrand: So as the policy is currently interpreted by staff, in this and a number of situations, just having someone as a subscriber doesn’t mean they’re actually using an address. So they treat the use of an address as only being simultaneously attached users unless we specify otherwise in the policy. So John can probably talk to details of that.

John Curran: To be very clear, the policy that – the practice on how we interpret the policy is very long standing and well understood. We are happy to change that, but if you want to change that, I’d recommend a very short policy statement that says: Please count total customers and not simultaneous subscribers – total subscribers, not total simultaneous addresses in use. And we can do accordingly. But given that the practice is already well known, we’re going to need direction from the community before we flip flop on that.

Dave Kessens: Of course there’s an obvious follow up question, and that is how other regions are doing this. And I see other people in the room that might be able to give an answer on that.

Scott Leibrand: I’d be interested to hear that as well. Should we go to the remote participant?

Cathy Aronson: Marla Azinger, Frontier: To David’s point, the network footprint is what causes the problem, not the footprint being the problem. But when you increase the quantity of the pools, you drastically increase the difficulty to reach 80 percent active utilization. ARIN requires active not assigned.

Scott Leibrand: Thank you. Front mic. Andrew.

Andrew Dul: Andrew Dul. Can ARIN staff eliminate what policy section that they believe they’re drawing their current practice from?

John Curran: Give me a moment.

Andrew Dul: For example, is it from 4.2.4.1?

John Curran: As I said, give me a moment. Probably should go to the next speaker.

Scott Leibrand: R.S. or Kevin; who was first?

Kevin Blumberg: Kevin Blumberg, The Wire. So I’m neither for nor against, this is really a discussion, but my first question is this is now a discussion about failover as far as the author is concerned; is that correct?

Scott Leibrand: I think that is a component that goes into it. But the underlying discussion is the architecture that has been chosen for various technical reasons, including failover, makes it very difficult to comply with ARIN policy and still get the addresses that are needed, and therefore there’s a proposal to change the ARIN policy. I think, as Marla highlighted, there are other architectures and other technical situations that get people into similar situations. So I would like to avoid deep diving too much into the particulars of any particular failover or anything like that.

Kevin Blumberg: That’s fine. So based on that, my only thing to say is I would actually scratch out the total subscribers and change it with connectible subscribers. And the reason why I’m saying that is if I have a thousand customers that I provide paper airplane service to, they are a subscriber, whether they can connect to the Internet or not. So while that might be the total number of subscribers that can connect is a valid metric, the total number of subscribers I would not consider to be a valid metric.

Scott Leibrand: Right. I think if we construct text to address that particular solution, we would probably model it a little bit after the residential market area text, which does essentially the same thing, which just says how many, in this case homes, do you have connected and could you provide IP service to if they subscribed.

Kevin Blumberg: Okay. Thank you.

Scott Leibrand: R.S.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN Advisory Council. I am the secondary shepherd on this proposal. I am committed to it getting a fair hearing and input from everybody in the community. I am personally opposed to this proposal, and here’s why: There are a succession of bad architectural decisions that have been made here. And I’ve been engaged heavily with the author and tried to get – offer some alternate approaches to fixing things.

The failover architecture is not appropriate to conservation of address space, and the decision to use squat space is something that we are now being asked to back out via policy, when we’ve told people for years that a business plan that depends upon continued large amounts of IPv4 being available is deeply flawed and it will come home to haunt you.

Its cousin, its very close cousin, is the assumption that one can go ahead using squat space as the amount of squatable space goes to zero. And we’ve been saying – I’m coming up on 10 years of running IPv6 at home. I think Owen probably has me beat. But we’ve been saying for a long time to the manufacturers, to the telephone system operators, that your solution in this is IPv6. In my day job I have fought successfully for single stacked IPv6 devices because address conservation is not a problem there.

There’s a wonderful, cute article that Heather pointed out to the AC, and I commend it to each of you. If you Google for “not everyone gets a Band Aid” and read that. It’s about an exercise involving some school-aged children. I believe that’s the situation that we’re encountering here, and I’m deeply sorry that I’m not in a position to be able to fix this problem for Cameron’s organization, for any other cellular phone company, or for any other place where we have this sort of problem, because we’re going to have a lot more of these problems as IPv4 runs out. Not everyone can get a Band Aid.

Scott Leibrand: Thank you.

Andrea Cima: Hello, Andrea Cima, RIPE NCC. There was a question on how we would do it in our region. With regards to assignment, approving additional assignments to a certain service, in this case we would look at the peak of simultaneous users in that area, in that assignment, and base the additional assignment on the peak of users.

When it comes to allocations, because now we just automatically give a /32, the LIR would still have to use 80 percent of their total allocation. So it was also up to the LIR to make sure it was well planned and give the right number of IP addresses to one assignment or to one area rather than, let’s say, too many IP addresses to one area, to one service, and not enough to the other.

Scott Leibrand: So am I understanding correctly that you are interpreting your policy the same way that ARIN interprets their policy?

Andrea Cima: Yes.

Scott Leibrand: Thank you. John has a follow up on the other question.

John Curran: Yes, it is per 4.2.4.1 regarding 80 percent utilization, and it notes that this includes space assigned to customers. But we actually have to have the practices that that space actually does have to be used. It can’t be assigned to a customer arbitrarily or pre-provisioned. So that’s the existing practice. Again, we’re happy to change it if the AC wants to provide different language.

Scott Leibrand: Thank you. Jason? Sorry. It’s hard to see the front table. These guys have probably been waiting for a long time. Heather, go ahead.

Heather Schiller: So this sounds a lot like a problem that we should have solved 20 years ago with dialup. And I’m not really understanding how it’s different. Like in dialup you had customers who weren’t always connected, you had peak connection times and design – you had separate POPs where you had potentially 100 customers be able to dial up or 100 IPs assigned or whatever. So I don’t understand like why they’re having a problem with interpretation of policy when ARIN’s staff probably has already dealt with this 20 years ago.

Scott Leibrand: So acknowledged. The only thing I would point out is that this isn’t the first time we’ve dealt with a similar issue. The cable policy, while it was a different technical reason for not being able to get to 80 percent, had a somewhat analogous issue that we ended up solving via a policy that was appropriately crafted for that situation.

Heather Schiller: So can we just fix it by saying cable and wireless and – or maybe not exactly in that way, wireless and cable, so we don’t have the company, but like – like, I mean, it just –
Scott Leibrand: I think there are a number of ways to solve the problem in policy text. I think the more important question is, is this a problem we should solve, and, if we do, which outline. So if you have any input on that, I’d love to hear it.

Heather Schiller: So my input on that is it’s probably not a problem we need to be solving. I both agree with Owen and R.S. that like this is a problem that we’ve been saying, building your business around v4 space is not necessarily the best business plan, and so kind of getting over that part into – and I don’t believe that this is necessarily a huge problem to solve, and I also don’t believe that it’s not something that could be worked out directly with registration services staff.

Like I think that they’ve seen cases like this. They should be able to handle it. Like they should be able to come to an arrangement to be able to get the address space they need. I kind of agree that it seems like maybe not a pony like “I wanted it because I want it” pony, but like I want it because I’m not understanding how to give them what’s needed in order to – how to document what I have or how to engineer my network.

Scott Leibrand: So my understanding is that this is an actual policy issue and not just a lack of understanding issue. And from Marla’s comments, I’m sure that this isn’t the only case where organizations are doing things that they would otherwise not want to have to do in order to move space around and otherwise get things up to 80 percent before they get more. The question then to me becomes what level of that sort of activity become onerous and justifies a policy change to allow it to be easier for people in that situation to get addresses.

Heather Schiller: So maybe I could say this a little bit more clearly; that like if that’s a problem, it’s been a problem for the last 20 years. Let’s deal with other problems that have to do with running out of space and getting folks to move toward v6.

Scott Leibrand: Acknowledged. Thank you. Do you have a remote? I don’t know what the order was, so – let’s do the remote and then we’ll do John and go back to floor mics.

Cathy Aronson: Marla Azinger, Frontier: I understand Seastrom’s point; however, addressing affects the economical health of all networks and global economy. Retail and exchange are tied to this. While some cases might not be realistic and a pink unicorn pony, the ultimate pony, there are many cases that need to be considered in this policy that would be more inclusive and representative of the ARIN community. Let’s see. There’s more. Whether it’s liked or not, business exists because IP addresses make it possible. That can’t be ignored, and this is an old – a new issue as well as new services are created.

Rob Seastrom: Rob Seastrom. If you think it’s that bad, wait a year.

John Springer: Math check. If we were to take this down to last call and beyond and we went the 50 percent of simultaneously attached users route, would that be moving toward the limit of two IP addresses per user based on the failover architecture?

Scott Leibrand: That seems like one possible effect of this, yes.

John Springer: I wouldn’t be in favor of that.

Scott Leibrand: Jason.

Jason Schiller: Jason Schiller, Google. I had a similar question to John and following up on a comment that not everyone can get a Band Aid. I have trouble understanding what are we talking about here in terms of scale. Would a /8 solve this problem; would two /8s solve this problem? How much swamp space are they currently using; how much space could they currently justify at 90 percent utilization effectively allowing them at least to number into that space for steady state usage and maybe falling back to double used swamp space? And my third question is would a /10 suffice?

Because it sounds to me like some of the cable operators were complaining about a similar sort of problem where they were using RFC 1918 space and they were getting to a point where there was not enough of it in order for them to do CGN, and they got 100.64 /10. Could that space work in this context as well? So basically my question is: What are we talking about in terms of scale? Could 100.64 suffice? And would a /8 or two, effectively all the remaining ARIN space, would that make a difference?

Scott Leibrand: So the author specifically said that that /10 is not enough, and John has additional details.

John Curran: So we have lots of mobile operators who get new address space. They utilize their old allocation, they come back, they get more. We’ve had – from the email on this, we have – an operator has indicated that there are circumstances where it can be very difficult for them to do so because of the technical architecture they have.

We don’t know whether or not 30 mobile operators or two would make use of some policy if you changed the policy. Very hard to estimate that. It was noted that the current policy can be technically difficult to achieve and a parity issue with the fact that some service providers, like broadband cable operators, have a different threshold. So that’s why it was raised and brought to this. There’s no way to estimate who might make use of a policy statement to be written. But obviously mobile is a huge growth field, and so any policy statement we write will apply to a lot of people seeking addresses.

Jason Schiller: So with regard to the space being shared, such as 100.64, would such a shared solution suffice to solve this problem?

John Curran: I don’t know. I haven’t had any discussions to that effect. I’m just giving you the context that led to them being referred to the policy process.

Scott Leibrand: I don’t know for sure, but I believe RFC 1918 is being used for this purpose and is not big enough. If there were a larger block of RFC 1918 type space or something equivalent to that /10 that were large enough for their purposes, I suspect that that might provide some alternative ways of accomplishing this, but you’d have to ask the author on the mailing list to get a good answer. Milton, I think you were next.

Milton Mueller: Milton Mueller, Syracuse University and Advisory Council. I can’t easily dismiss this proposal because of the fact that we had Marla speaking in favor of it, showing that it’s not just a problem specific to this particular mobile operator. And you’ve just admitted that you dealt with a similar problem with the cable infrastructure.

What I don’t like to see is solving these problems for a specific technology on a one by one basis rather than having a generic policy. The other issue that I think I’d like to raise – well, just to conclude that thought, I think that this proposal is not really a proposal. We need to have a generic solution to this problem that would hold.

And the other point I want to make is that it would – it’s probably tempting for many to say, well, we’re talking about the next four or five months of the free pool that this affects, but in fact you’ve tied the transfer market to needs assessment, and if these are the criteria that are going to be used for needs assessment for acquisition of addresses in the secondary market, then you really do need to deal with this problem in a proper way, in a generic way, that applies to – if it can, applies to all these different technical infrastructures.

Scott Leibrand: John wants to respond to that.

John Curran: Milton, could you stay at the microphone for a moment? Could you repeat your last point about the tie of the transfer policy to this.

Milton Mueller: Repeat the last – okay. You’ve tied the transfer policy to the needs assessment. So to pick up on Rob Seastrom’s point, the price system would automatically penalize people who build their business models on the continued availability of v4. As the price rose, they would have to start thinking about that. But in the meantime it would allow them to pay that price if they thought it was worth it.

But if you’ve tied the needs assessment process and you actually – you don’t even allow them to buy addresses, then, number one, the market for v4 does not reflect the actual value. You’re simply stifling exchanges that could and should be taking place. And, secondly, you’re not really giving them a chance to understand the full cost of the business model or any other players in the industry.

John Curran: Thank you for saying that. I want to tell people, listen to Milton for a moment, okay, to be clear. The transfer policies create dependencies on all of the assignment and allocation policies such that we can’t look at policies and say is this important over the next two years before we run out, because all of these policies, the way things are currently constructed, will be in active use in qualifying parties for transfers. So that’s just the nature of the structure we set up and needs to be kept in mind, this might be a good policy, this might be a bad policy. I guess what I’m saying is: Whatever we decide, we’re going to be living with it far more than the free pool.

Scott Leibrand: I believe R.S. wanted to respond to that. Is that all right, Owen?

Rob Seastrom: We’ve already bifurcated the policies a little bit in terms of advanced need documentation. What is it, three months versus 24?

Scott Leibrand: Yeah.

Rob Seastrom: Would you have a problem with having a policy like this, since you talked about the back pressure that would be created on demand in penalizing people or companies that base their – their address policy and technology on continued v4 use? Would you have a problem with making this something that only worked in the transfer market and did not work for depleting the free pool?

Scott Leibrand: I think that’s a question for the entire community, not just for –

Rob Seastrom: It is actually. It was directed at Milton, but it’s a question for everyone.

Owen DeLong: So first I’m going to take issue with something Milton said, which is, quote, these transfers that should be occurring. Well, by policy we’ve said actually that these transfers shouldn’t be occurring. That’s why we’ve tied transfers to needs basis, is because we don’t think transfers should be occurring without need, and so that’s an assumption that goes contrary to the community’s adopted policies.

Now, going back to what I was actually up here to say, there are a number of operators, both 3G and otherwise, that have managed to get the space they need to run their networks and such under the existing policies. The fact that we have some operators represented that don’t seem to be able to figure out how to do that is an indication that those operators need education more than we need a policy change, in my opinion. As a data point, the particular operator in question that has proposed this particular policy has about two /8’s worth of users.

Scott Leibrand: Thank you. Rear microphone.

Dave Kessens: Dave Kessens, Nokia Siemens Networks. I take issue with a few things that I heard hear on the mic. One of those things I heard was that 3GPP architecture, et cetera, is very broken. Well, there’s definitely arguments to be made for that. But there’s one thing that the 3GPP architecture is actually not wasteful and inefficient at, is actually IP assignment and allocation. That part actually works rather well and rather efficiently.

So trying to paint the mobile operators as rather wasteful in that context I think is not right, because they’re actually rather efficient, and much more efficient than some other technologies that use IP addresses. And, second, the other thing, it’s like – thank you – so the other thing I heard was that, well, we don’t need – we don’t want to solve this because it’s late. Yes, of course it’s late. But as an industry we’re going to tell relatively newcomers into this industry like, well, we don’t solve this problem for you because you’re late to the game.

That’s iffy. If somebody has a legitimate need to use IP addresses, yes, even if it’s late in the game, they should be able to get them. And if they get finished earlier, then so be it. But they should be able to get them. And that’s an important principle that we should continue in this community and that it should stay until the end. Because the end is in sight. But just saying like, oh, it’s late, but I don’t think that we can say stuff like that; that it’s just not acceptable.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I think we need to be careful about proposing to bifurcate policy between the transfer market and the free pool.

We have bound them together for a reason. I’m not saying we can’t bifurcate. But if we continually do that and do that to extreme, we call into question the whole concept of attaching it to the needs assessment and move us more toward the idea, well, maybe we don’t need needs or maybe the cash value of the transfer is proving the need, as some people have said. I don’t believe that, but we need to be careful about that.

So I would not support bifurcating this. I do support the – or I support finding something here. There’s no text to support just yet, so I can’t support it as written.

But I support doing something on this. I haven’t decided whether it’s the 50 or the 80 or total subscribers. I gotta think that through a little bit more. But something along those lines. I do agree we need to find a way to do it general.

I would just point out that this author provided a previous proposal stating it much more simply along those lines of, hey, the residential subscriber policy should apply to mobile. So we told them, well, why? And so he’s telling us why now, and now we’re saying so let’s be consistent here. So I’ll leave it at that.

Scott Leibrand: Thank you. John wanted to respond.

John Curran: I want to be clear. I’m not advocating that the needs assessment be broken out separately from allocations and assignments versus needs assessment and transfer. I’m only noting that our present structure means policies for allocations of assignments are used for needs assessments for validating transfers. Therefore, when you’re thinking about policies, you need to think about them thinking about not just what that policy means for the duration of the free pool, but for the duration of the free pool plus all transfers dependent on it going forward over time.

I guess what I’m saying is policy has a lot of longevity beyond what people might just think about until the remainder of the free pool. I’m not advocating for break either way, I just want the community to be aware of the impact of the policy it develops.

David Farmer: Just quickly to respond to that. David Farmer again. I wasn’t directing my comment at you, John, it was at others. And I would just add to that: Policy lasts a long time, so we better be careful about how we tweak it and stuff like that in splitting it and otherwise.

Scott Leibrand: Thank you. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Last year we had a policy, the TPIA policy, that took a very long time to bring the community up to speed in terms of what the author was looking for get and which community was being affected, et cetera. I think I’m fairly technically savvy, and I’m trying to add up 1 and 1 and I keep getting 2.68 by whatever these numbers are. Nothing is making sense to me here. This is something that’s been going on for 20 years. I don’t understand how this is a specific issue at or near run out suddenly that has propped up.

With that being said, if the community can come to an understanding of why this is a real technical problem that cannot be solved in the way that it was a bad design choice versus anything else, then my suggestion is to look at guidance from the TPIA policy, which is to prevent the profiting of giving out abnormally high numbers of unutilized numbers. Maybe that’s putting it or requiring it only be in the transfer market. Maybe that is not allowing it to be part of the transfer market after it’s assigned. I don’t know.

But I always worry when we start giving out unused IPs for the chance it might be used in failover situations or in certain situations but it’s really not being used. It’s too easy to game the system in those types of situations.

Scott Leibrand: Thank you. Front and center microphone, then we’re going to go ahead and close microphones after this. So if you want to get in queue, please do so before I call the next speaker.

Robert Duncan: Robert Duncan, Merit Network. So I don’t see there’s any conceivable v4 policy that can address this issue at all. For one thing, it’s not a policy issue. It’s an architecture issue. They’re trying to assign or reserve multiple addresses for one active device. That strikes me as just wrong. You don’t do that in a datacenter environment where you’ve got several thousand virtual machines. We pass the addresses around. We don’t reserve multiple addresses in case this machine moves somewhere within that cluster. They can do the same thing on the front end of their architecture and still have one address per device, which is the way it should be allocated. So I’m not in favor of wasting any more brain power on this at all.

Scott Leibrand: Thank you.

John Curran: All right. Closing the microphones now and remote participation will be closed momentarily as well. Go ahead, Jason.

Jason Schiller: Jason Schiller, Google. So listening to the temperature at least in this room, it sounds to me like what people are saying is this is not a widespread 3GPP problem; that there are a number of providers with different architectures that don’t seem to have issue getting the address space that they need; that there is a small handful of providers that have an architecture that people are claiming is not valid because of its inefficient use of address space. And I think that this is very different than the Canada cable TPIA problem where it was widespread affecting all of the non-incumbent cable providers.

I think if this policy is to move forward, what needs to happen – well, first of all, we need some clear policy text. But, secondly, we really need those providers in the community that are having this problem and those providers that are not having this problem to come up and talk to us about whether this really is just an architectural problem and, as David Kessens suggests, that 3GPP technology can and does efficiently use address space or whether this is widespread amongst all of the providers in this space. And I think putting together a panel of those providers would be very helpful in moving this forward.

Secondly, I think if we are going to resolve this problem, it should be solved in a way that is generic and applies to all of the providers in this type of a space, where dynamic addresses are given as assigned to a pool that belongs to a piece of equipment, so that would include dialup, that would include DSL, cable, et cetera. So that that’s my personal feedback to the author and to the shepherds and to those who are going to craft policy: Put together a panel of operators that either explain that it is a widespread issue or it’s not a widespread issue, it’s just a bad architecture, put some clear policy text down on paper, and make sure it’s generic enough to apply to all dynamic uses of address where the addresses belong to pools of upstream equipment.

Chris Tacit: Chris Tacit for TekSavvy Solutions. I wanted just to echo the comments that were made. Actually my comments are going to be a lot shorter because of these last set of comments. I think the way I’d like to put this is we need more evidence of a problem before we try and come up with a solution, and I’m all in favor of investigating that and seeing how widespread the problem is and if it is a problem.

But some initial indicators are that perhaps it’s not right now. And we can be persuaded otherwise, but the fact that other RIRs have not seen fit to have this type of policy, the fact that a lot of time has passed before anybody’s even raised this issue, and the fact that the issue is being raised by a very limited number of service providers suggests we need a lot more evidence before we put the community’s effort into this activity. And if that evidence materializes, then so be it. We would have no objection to that. But I think this is different from the cable situation where the whole competitive industry in Canada wouldn’t have been able to function without the relief that was granted by that policy adjustment. So for me it’s all about evidence based solutions. Thank you.

Scott Leibrand: Remote participant.

Cathy Aronson: Fred Moses, Tri County Wireless Incorporated: As Merit just said, one IP per device, no holding IPs just in case of failover.

Scott Leibrand: Thank you. I think that concludes our discussion, so thank you.

(Applause.)

Scott Leibrand: We’ll take this as advice to the AC. I think we’ve got some pretty good understanding of what information we need to collect and what direction we need to take policy, and then I’ll leave it to John to see if there’s anything else.

Rob Seastrom: It’s still a lunch table topic today.

John Curran: People that want to continue the discussion, this is one of the lunch table topics today. I also want you to know with respect to lunch table topics we had challenge because we had people talking about government issues with lunch table topics, and we’re going to double the number of tables talking about that topic. And we ask that people let the government representatives from the Caribbean have first digs at those tables, obviously, because they are the ones most significant. So that will be when we get to lunch.

ARIN-2013-3: Tiny IPv6 Allocations for ISPs

John Curran: But we’re not going to lunch. No lunch until we’re done with policy. We have one more policy to consider. It is Draft Policy 2013-3: Tiny IPv6 Allocations for ISPs. And I will now invite Dave Farmer up. Let me do the intro very quickly. Started as ARIN Policy Proposal 185 in March of this year. Dave Farmer and Chris Grundemann are the AC shepherds. The AC accepted it as a Draft Policy then. It’s online and in your Discussion Guide.

It will reduce the minimum allocation size from /36 to /40 if approved. The ISP that has a /36 or /40 can have additional allocation without being subject to additional allocation policy as long as they don’t cross the /32 border. Presently policy allows them to opt to a /36; this would extend that to a /40. No similar policy proposals or discussions. It was posted for discussion. The staff and assessment will be performed upon review of the AC. That concludes the introduction, and I’ll invite Dave Farmer up to give the policy presentation.

David Farmer: Mics, there we go. We have a pretty good problem statement here. Basically the fee structure has this graduated scale and you pay based on the amount of resources you have. At the very bottom end there’s this new XX small ISP category or XX small category, and there’s no associated allocation that can be made for it. And this proposal is suggesting a /40 for it.

And so while tiny in absolute terms, if you don’t have – if we don’t have this – if someone has a /22 of IPv4 space in the current fee system, they would – to get v6 would have to basically pay $500 more. And in absolute terms that’s not a lot, but that’s doubling. And that kind of eliminates – creates a disincentive for v6 deployment for these very small ISPs. And we’ll move on. So as noted by John, the fee schedule was corrected. It used to say /48 or smaller. It’s /40 or smaller was I guess the intent. It’s now what’s up on the website. So that’s what’s up on the website.

So the intent is to add an optional /40 minimum allocation size allowing these XX small ISPs to deploy IPv6 without changing their fee category. This right now you can select a /32 or a /36. This also adds the smaller allocation sizes, can expand up to /32 without renumbering or additional justification. And essentially this requires reserving at least a minimum of a /32 to allow this.

Because there’s a number of ISPs that have deployed v6 at no cost to them due to the fee waivers in IPv6, there’s a number of ISPs that will end up going beyond this XX – that would otherwise qualify for XX small but they have a /32, and so they need to be able to reduce their category. There is no clear guidance on allowing returns, and the second part of this proposal is to provide some clear guidance on that. And it’s done in very generic terms, because there may be unforeseen reasons in the future that ISPs or end users for other reasons than we’re talking about right now would want to return space, so let’s make it generic so we don’t have to revisit this every time we create – if there’s a reason for someone to return stuff.

The specifics of those requirements are you must not increase the number of blocks being held. You return whole blocks when that’s possible or practicable. Partial blocks that are retained must conform to the applicable policies as to size, alignment, et cetera. Blocks retained within a – should be retained within a single reserved space or aggregate where possible or practical. And the blocks returned must not be in use. In other words, you can’t return blocks under your customers or you can’t say, oh, I’m not using that so I’m going to return it but keep using it.

So disadvantages. A number of people in the community feel this is really a problem with the fee structure, so fix it with the fee structure rather than by changing allocation policy. This creates a financial incentive for ISPs to make undersized allocations. I will note that this is – that that kind of incentive exists across the whole spectrum, but it actually is kind of more acute with a /40 allocation size. And in this case it’s not the ISPs that are really harmed, it’s the customers. And they may not even understand they’re being hurt.

But there are advantages. This allows all ISPs to get an IPv6 allocation without changing their fee category. It eliminates in this particular case the financial disincentive for XX small ISPs to deploy IPv6. And there’s a number of proposals in different ways to change the fee structure, as John had mentioned earlier. Most of those seemed to have some other long-term problems, as far as I’m concerned, and this is a long-term solution. And it’s doable now. So while /36s and /40s are suboptimal from a policy perspective, this is mitigated by allowing any of those ISPs to expand back up to /32 without renumbering or additional justification.

It’s completely voluntary from a policy perspective. We’re not saying, oh, well, you’re too small; you can’t have a /32. We’re saying you can decide if you want something smaller. And it basically fundamentally just makes it an internal business justification for the ISP as to what size allocation they’re going to get. This is the policy text. We add an “or /40” to the 6.5.2.1 clause B. And we add a clause G that allows you to expand back up and provides the requirement for you doing that without renumbering or additional justification and basically says they’re not subsequent allocations but if you go beyond the /32 you have to qualify as subsequent allocations.

And then we have the policy statement for the reduction in return. This becomes a new section under IPv6. So during the discussion on the mailing list, there’s been a few questions that I sort of punted and basically said, well, I’ll ask these questions at the PPM, but we needed to get some text and get it frozen for this meeting. So should there be a requirement to retain only the first or last block of the part that’s being returned, or should it be flexible, as the text currently is? In other words, the person returning it gets to decide which part they’re going to keep as long as it meets the other criteria. Should a /28 be reserved for all ISP allocations, /32 or below? And should there be some sunset clause eliminating the /36 and /40 obligations if and when the fee schedule changes?

This was brought up on the list, and I said, hey, I need more guidance on this. So those are some of the questions I have for you on how to look at this, and time for discussion now.

Tim Denton: Owen DeLong.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. As the –

Tim Denton: In favor or against?

Owen DeLong: I’m very thoroughly against it. As the person who originally put /36s into policy as a way to try and cope with the fee situation as it existed at the time, the Board then took that to 11, so to speak. And the unfortunate problem of this is that we create a financial incentive in the current fee structure for ISPs to provide substandard assignments to their end users in order to try and fit themselves into smaller fee categories.

And while I’m less worried about this practice at the higher end, I am worried about smaller ISPs deciding that, well, I can get more customers with /60s in and still remain in the /40 percent or I can get more customers with /62s or /63s or even, good God, /64s per customer into the same space and save a few bucks each year.

And I think that because the victims of that decision are not the ISPs themselves but their subscribers; that we really need to be careful what we do with the policy in this regard and that we should not provide any mechanism by which people are able to further screw the customer in the name of saving a few dollars on the other side.

Tim Denton: Thank you. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I am against. My biggest concern is we’re playing a game of Whack-A-Mole between the fee schedule, which the community has input but no involvement in setting, and policy where we’re trying to change how much people pay; i.e., affect the fee schedule through policy. And that game of Whack-A-Mole goes both ways. We’ve already heard this morning that the fee schedule is now going to be looked at again based on significant discussion.

And it’s very possible that if we pass this policy, the fee schedule could change again because now the balance tips and et cetera. So I’m very actually concerned that we can’t play the policy game against the fee schedule. We only have to look at it from a technology point of view. And I think I agree 100 percent with Owen; that /40 is dangerous for the community. Thank you.

Tim Denton: Jason first, then Paul Andersen.

Jason Schiller: Jason Schiller, Google. I also oppose this policy as written. While I’m sympathetic that small ISPs shouldn’t see a bump in their fee structure just because they adopted v6, this would certainly not help encourage IPv6 adoption. I don’t think the way to solve this is by mucking with the routing and creating yet another class of allocation size. If you decide to get another class of allocation size, please, please, please, put it in a separate block so people who want to filter it adequately can. There’s still some ISPs that are filtering on /32 or /36 boundary or /48 for PI. We put PI in a very clear and specific block for this purpose. If you’re going to create yet another class of addressing, please put it in a specific block.

IPv6 renumbering should be easier, theoretically. I know that’s not always the case because people hard code IP addresses into things like firewalls and host names. In terms of the expansion into the /32, I don’t feel like all that added complexity is needed. I think yesterday we discussed a policy where basically if you meet under the current initial allocation policy you can get more space. And it seems like an ISP that’s making some delegations that you qualify it for a /32. So I don’t see that as being a burden, and I don’t think that that added text is needed.

Really I just want to echo the concerns that, yes, I think it’s a tragedy for the price to go up because you’re doing v6. I don’t think we should be solving it in this way. I think we should be giving feedback to what the fee schedule should be and trying to figure out a way to have an extra small class that doesn’t impact the system or grandfather in the current extra smalls for the current price or something to that effect.

Tim Denton: Thank you. I see Andersen, remote, and Curran. You’re standing to look beautiful, or are you going to talk? No?

Paul Andersen: If it makes you feel better, I’ll sit down.

(Laughter)

Tim Denton: Remote and then Curran.

Cathy Aronson: Michael Sinatra, ESnet: I am still opposed to this policy. The IETF has established standards and practices around the allocation of IPv6 addresses and we are not only driving number policy from bugs in the fee structure but we are creating implications for those standards and practices. I am very concerned about that. I also disagree with David that this is a long-term solution. It’s not, as it will need to be revisited the next time the fee structure changes. There are a few technical reasons. I think this is all a bad idea, and I have pointed those out on the mailing list.

But my opposition is more philosophical. We’re letting the ARIN fee structure drive a reinterpretation of IETF standards. What’s up with that? Smiley face.

Tim Denton: Mr. Curran.

John Curran: Amazingly good timing, actually. Couple of things, the fee schedule is independent of the policy. And folks should think about this policy proposal and decide whether it makes technical sense or not. I don’t think there’s currently a policy proposal within the ARIN region regarding end user assignments for IPv6, whether those need to be /64, /56, /48. And so, absent that, it’s a valid question as to whether or not extra small ISP can make use of a /40 in an effective manner.

So you should consider whether that’s a technically valid thing or not and come to a conclusion. That’s why you’re the community. Regarding the IETF, there’s actually only one document that talks about a minimum, and that document specifically notes it’s not for small ISPs either. So it’s important to realize this is up to you. I think it would be if there was a policy that’s set, a minimum ISP allocation for customers, then this would be a trivial thing to address this policy one way or another.

Indirectly, you need to address it by thinking about the size of an extra small ISP and whether or not /40 is simply too small to make sense. Last point. On the fee schedule, we will always have a fee schedule that covers the entire range of possible address holdings, because we can’t run to the community and adopt one after the fact when because of mergers or acquisitions or splits we end up with communities in that particular situation. So the fee schedule isn’t applicable if you don’t make policy. If you think it’s good policy, and you make it, it is. But the fee schedule doesn’t drive the bus, you do.

Tim Denton: Owen? Sorry. Scott.

Scott Leibrand: No comment. Scott Leibrand, ARIN AC, Limelight. I think it’s worth bringing up the alternative. I know it’s fees and it’s going to be decided by the Board and their new committee and we can talk about it in the members meeting. But my personal opinion is that this is probably not the best way to solve this problem. It might be the best way to solve the problem under the PDP, but I would personally be more in favor of holding off on the solution like this to see if the Board could accomplish something like Michael Sinatra’s proposal of if you have a /32 or less in v6, your fees are set by your v4 holdings, which I see as somewhat kicking the can down the road because eventually v4 holdings will go to zero for a lot of these users.

So I don’t think it’s a long term solution, but given the fact that people are not seeing a value proposition for adding v4 right now and any additional costs makes them have hard conversations with their business people about it, I think that deferral might be entirely appropriate. So I would oppose the policy as written as far as adopting it. We’re not in the point of recommended Draft Policy. So I guess what I’m saying is let’s wait and see if this can be solved for the next couple of years by a fee structure tweak.

John Curran: So discussion of IPv6 fee waivers is definitely something that the fee structure review committee needs to do. In terms of a problem statement, right now current policy allows an ISP to opt for a /36, an extra small, if he does that his fees are actually lower than under the fee schedule. So there’s nobody avoiding an increase who needs this policy to avoid increase. Existing policy provides that. So it’s not clear that there’s an actual problem statement of avoiding an increase, that needs to be addressed.

The fee review panel will look at fee waivers. We already had one for IPv6 for four years. It phased out. So obviously people want to review them. It’s part of a review panel. I don’t know – when you say whether something needs to be done in the interim in order to solve the problem, I don’t know what problem you’re trying to solve unless it’s make really, really low fees that have never been available before available to extra small ISPs. That does require action on this policy.

Scott Leibrand: You’re right, the fees are going down for anyone in this small category, and I think that is a good thing and I congratulate ARIN on making that decision. I’m not worried about someone who has v6 and their fee’s changing, because the changes would be all in the positive direction for them.

What I’m worried about is someone who gets into this extra-extra small category and then decides whether or not to add v6 that has fee implications. So I think it is worthwhile to consider this, like you said, as part of the committee. I think the other thing that we should be careful of is let’s not keep calling this a waiver. Let’s set up a fee structure that determines fees based on v6 or v4 utilization and does it in a way that the formula does the right thing and we don’t have to keep revisiting waivers.

Tim Denton: I saw Jason first, and then Paul Andersen. Paul? Fine. Paul.

Paul Andersen: Paul Andersen, ARIN Board treasurer. It’s already been said, but I think the decision to go forward or not should be on the technical merits of the policy. And I think it’s important for the community to recommend that should a policy make it to the Board for adoption, the Board would expect staff to give us its impact, and there’s always the chance that the fee schedule that you see now may have to change based on whatever the policy text is. I wouldn’t want to predict that.
But, yes, you shouldn’t be – I would like us to avoid making this a fee waiver discussion or fee discussion.

There’s a time and a place, and we discussed that earlier. But I want to reiterate that please don’t pass this as an attempt to get a certain fee, because we may decide – the staff may decide upon reviewing the policy that’s proposed that the fees have to change. Thank you.

Tim Denton: Thank you. Are we getting time to have a vote? I think so. No? Go ahead.

Cathy Aronson: A last in remote participant. Lea Roberts, Stamford: I am opposed to this policy, and I agree with Michael that any policy which discourages generous IPv6 customer assignments is wrongly headed.

Tim Denton: I think we now could get the vote takers. Are you – pads and pencils? All right. All those who are favor of the Draft Policy as written, would they please signify their approval by raising their hands. This is going to be a tough one. All those – okay. That vote is now closed. All those who believe the policy as written should – does not have their approval, please raise their hands. Vote counters, please tell me when people can lower their hands. Yes, you can. In relation to Draft Policy ARIN 2013 3: Tiny IPv6 Allocations for ISPs, those in favor were zero, those against were 28. I don’t think there’s any further need for any – to send this back for reconsideration.

John Curran: Thank you. Thank you, David, for your presentation. Thank you, David.

(Applause.)

John Curran: Okay. You’ve all been good.

Jason Schiller: Can we get the room count on that?

Tim Denton: Yes, you can. The room count was 102.

John Curran: Okay. You’ve all been good. You’ve done your policy discussions, and so we’ll feed you. So the next thing is lunch. I remind everyone that there are lunch table topics out there. I am told that there will be multiple tables for the resource challenges faced by governments ISPs and end users in the Caribbean. I ask again that you make sure priority is given to government folks who are here who wish to sit at those tables. And, please, if you want to Twitter about ARIN or use our hashtag, we’re also on Facebook, feel free to post. And take your valuables with you. It is not locked. There is no security. We are going to resume on schedule, which means we’ll see you back here at 1:30. Yes, Mr. Darte?

Bill Darte: Those multiple tables for the Caribbean community to discuss resource issues is not in the lunchroom but it’s immediately outside in the open area.

John Curran: Good to know. We have multiple tables. They’re not per se in the lunchroom.

Bill Darte: And it’s all the Caribbean stakeholders.

John Curran: Thank you. I’ll see you back here at 1:30. We have an hour and 15 for lunch.

Update on BCOP (Best Current Operational Practices) Efforts

Aaron Hughes: Thank you, John. All right. Welcome back, everybody. This is an update on best current operational practices. So for those who haven’t seen anything on best current operational practices, some time ago, three years ago, a few of us went around to all of the RIRs and LIRs and did some lightning talks on what we were proposing, and since then we’ve actually implemented some things. So this is an update to talk about where we are since then.

For those who don’t know what a BCOP is, it’s a Best Current Operational Practice document. The idea being that this is an open repository of living BCOPs. It’s similar in nature to the ARIN process. The idea is that they are a bottom-up development process. It is operator consensus driven with an 80/20 model, 20 percent being documented caveats with 80 percent sort of being the applicable piece of the document.

It is transparent in nature. They are revision controlled, and the documents are vetted at a community that participates by a development process for BCOPs. Also community-written. There are both local BCOPs and global BCOPs. So the problem statement is fairly simple. I’m sure you’ve all gone out there to do some research on any particular topic that is operational in nature to find out what is the best particular method for solving a problem, implementing a solution. Whatever it is, you go out there, you Google something and you come back with a whole bunch of solutions: some right, some wrong, some vetted, some opinion.

Particularly in the operator environments what you find is a whole bunch of PowerPoint presentations that are archived from meetings. Of course those are archived without the text that went along with them that was spoken or the video that goes along with those that might actually clarify points. And most importantly you can’t actually figure out if it’s current or if something has surpassed it since the last time that presentation was given. There’s clearly this gap in the community for a need for a repository of vetted current operational practices, and preferably the idea to have something central versus having something – and have something local.

So a very quick history. In 2010, as I mentioned at the beginning of this, did go around, give a whole bunch of lightning talks to validate that the communities agree that this was a need. There was an overwhelming agreement that there was a need for a solution like this. What it was wasn’t entirely clear, but there was a gap that definitely had a need to fill it. In 2010 we did launch a list and got community involved on a discussion list to try to figure out how to put this whole thing together.

In 2011 we had a whole bunch of list discussion, launched a website, started a draft process for a development process, which has been continually evolving, and wrote some BCOPs. So we tried to actually have some meat at the same time we were writing the process for how these things evolve. In 2012 we renamed it from BCP to BCOP because there was some IETF confusion about the focus on the operator specific documents rather than the actual IETF BCP process.

In 2012 we had a completed development process, which is the BCOP DP – yes, more acronyms, and it’s more fun to say, too – and in 2012 we ratified our first couple of documents. After that we went back to the community. We went to ISOC, ARIN, NANOG, RIPE, a whole bunch of volunteers and a few other operator groups to ask for some assistance with really getting this thing to work. Because a small number of volunteers couldn’t do it all. Everybody responded overwhelmingly yes, that they would help.

And in 2013 we came to understand through community outreach and some of our own realization that it made more sense to convert this sort of single group into a multi-regional and global BCOP organization structure. So an example would be someone might say I want to write a best current operational practice document on how to interact with law enforcement.

That’s something that would be a regional BCOP and not have any relevance in another region, but you could just as easily say how would I implement ingress and egress filtering on the top eight major router vendors, and that document would probably be very similar across the entire globe and make sense to be in a global repository. In 2012 it looked something like this. This was the way that it was and is the wrong way. We had a single organization with some resources and we’d all go out to individual operator forums and host tracks and individuals going to RIR forums to help get some input into this as well.

We’re converting to a restructure, as mentioned, regional operator driven. Some BCOPs stay local; others become global. So the restructure looks something more like this, the idea being that we start in a single operator group, build a track, build this process to be scalable and effectively come away with a template. And the template can be for any operator group that is interested in participating in this process.

Of course, they can change that themselves because they can have their own development process that allows them to be flexible and change. We just wanted to start someone and give them a package that made it easy for them to replicate. So today we’re doing that with NANOG. They’ve agreed to be the sort of guinea pig for this so that we can template-ize the whole process and continue going out to other groups.

So we’re in the process of that restructure. We have moved the existing BCOP development process. That’s the PD should be a DP. The best current operational practice documents, the list, the website, to a single operator group as a template. Yeah, I mentioned this. And we’ve also identified a host for a global BCOP provider supporter and validated it from parties and we’re executing.

So regional. We talked to NANOG. The Board agreed to move the list, the website. We’ve made some changes to the development process to use as a template for other operating groups and operator forums. Global ISOC responded using their Deploy360 program. They seem like a really good match for hosting the global process, the support, the documents, anything that we really need for the outreach. And it has really good strategic alignment in that and you’re going to see from the next presentation highly focused on the dissemination of information related to key Internet technologies such as things like v6 or DNSSEC or routing resiliency, routing security.

So we think that these programs make sense as a good hoster for a global BCOP repository and process. That’s, however, still underway. ISOC is currently testing the water. They’ve hired some strategic players and focused part of their hats on validating the interest globally to make sure that this makes sense in all regions and to help fix a whole bunch of things, including things like a feedback loop into the IETF from an operator perspective, which is a nice value add.

And then we have locally within the NANOG region really shifted our focus away from the development process itself and now we’re finally into the meat. So we’re writing documents and looking for authors and looking for subject matter experts, which is great. So we got through this hurdle. Took a long time but now we actually have some structure in place and it seems to be moving along just fine.

So what’s done today? We have a development process and we have three current BCOPs in it. This should expand dramatically by this next coming NANOG meeting. We currently have a best operational practice document on v6 subnetting, public peering exchange interface configs, and IPv6 peering and transit. And, as noted, there’s input needed for version two on that last one. It’s still a work in progress. So what’s next? We have a website to move still. It’s on the third party VM which we’ll do before NANOG.

We need to find a better document management system. Because today it’s really challenging to have revision control with rich documents. It’s pretty easy with text only. But we actually have things like graphics and it’s actually really challenging. So I’d love to hear, by the way, if anybody’s got some great solution for that on how to manage rich documents, version control. We’re probably going to move it to something that’s wiki like with a PDF plugin to manage those for now. If anybody has any ideas of making that better, we’d love to hear them.

And we’re going to try and kick off a whole bunch of drafts and really kick this thing forward with a lot of meat, put it out in the public to people involved. There’s been tons of volunteers, and there are several hundred people on the list that are really waiting for this to all start. So we’re good for launch. How do you get involved? There’s a list now hosted on the NANOG mailman server. Go to the URL and sign up for the BCOP.

For the global input, while this is still not completely developed, if you have some input or you want to volunteer yourself as well, you can certainly send that email to deploy360@isoc.org. And if you’ve got any general questions that you don’t want to put on lists, you can certainly just send an email to Chris or myself and we’ll be happy to give you an answer. Questions?

John Curran: Thank you, Aaron.

Deploy 360

Megan Kruse: I’m Megan Kruse and I’m happy to be at an ARIN meeting for the first time in a few years and not as a staff member. So no responsibilities. I’m here to tell you what I’ve been doing for the past two years or so with the Internet Society. We have a new initiative – new as of a year and a half ago we officially launched – called Deploy360.

Our main mission is to increase real world deployment of the standards that are coming out of the IETF. We have three main topics at the moment. They’re IPv6, DNSSEC, and routing resiliency and security. So the problem that we see is that the IETF creates these standards and then they say, okay, we’re done. Standards done. And there’s nobody to fill that gap in and go to the operators and say: And here’s how you do it. So that’s the gap that we’re trying to fill. We’ve also – if you go Google “how do I do IPv6,” you’re going to get millions of hits, so – and some of them will be 15 years old and completely irrelevant.

So we’re trying to kind of be the best ever repository of information and get the real hands on information into the operators’ hands so they know what they’re doing and how to proceed. So there are four main components of the program. The web portal is everything. It’s got all of the tutorials and white papers and case studies and videos.

There’s tons of information on there and we’re constantly adding to it. And we have five main audiences that we’re trying to reach. They’re developers, network engineers, consumer electronics manufacturers. And two more. We’re very active on social media. All of our resources that go out are put out over Twitter and Facebook and Google+ and RSS feeds, trying to engage as many audiences as we possibly can. We add them to LinkedIn groups that are related to DNSSEC or IPv6, things like that. We do a lot of videos.

We have outside speaking engagements such as this one where we go to network operator groups. We go to IPv6 summits. We were just at the Rocky Mountain IPv6 Summit last week. Dan York, my colleague, is at SIPNOC. That’s a voice conference. He’s there this week. And World IPv6 Congress. All sorts of events all over the place.

And we actually have our own ION conferences. We do three or four a year. We try to hit different continents. This is very much a global effort. And we’re just trying to spread the word out. And it goes two ways. We’re trying to get the people that have done it in the room with the people who need to do it.

And then we’re also trying to get feedback from the people who need to do it saying – just to find out what do you need from us. We’ll either create it or we’ll go find somebody who has already done this how to document, what do you need, how can we help you. We’re really trying to get you the information you need, but you need to tell us what it is you need if it’s not already on the web portal. I have an animation, who knew. So just let that fill in apparently. There we go. So this first one, this is how you can get involved. This first one might be preaching to the choir a little bit, but go to the website, poke around, look at the resources, see what’s there, see what you can use to actually get IPv6, DNSSEC, things like that, deployed.

And give us feedback: what worked, what didn’t, what can we add, what was clear, what was not clear. Look through the resources and let us know how we can help.

Spread the word. I’m sure all of you have completely updated all of your networks to be IPv6 and DNSSEC ready. Right? But maybe some of your customers or clients have not. So spread the information to them, give them the information that they might need. And, again, if they come back to you and say this wasn’t clear, let us know. We’re constantly adding things and tweaking the information on the site.

So we have the ability to add content and create new content and change it up so that it is helpful if you don’t find it exactly what you need right now.

And then this is the part where I’m really hoping you can help us out is we have a product – we have a roadmap for each topic, and this is the holes we see, the things we need to fill in, the case documents, the case studies, the tutorials. Take a look at the roadmaps. And maybe you or your company has already written some of this stuff and we can add it to our site. Maybe you can work with us on a case study of how you deploy DNSSEC in your own, for yourself. So work with us to create new content, and we will credit your work. We’re happy to spread the love a little bit. So that’s kind of the bulk of it.

I only have six slides, so probably didn’t need 15 minutes. We’re all over social media. Here are the links. You can also go to internetsociety.org/deploy360 and poke around. I’ll be here for the next few days, so contact me or contact us at deploy360@isoc.org. And we’ll be around. Also, following up on Aaron’s presentation, if you’re going to stick around for CaribNOG, I’m going to channel my co-worker and give his presentation on the local BCOP efforts. If you have any questions and you’re not going to stick around for CaribNOG, just find me and I’m happy to answer questions. If you have any questions, go for it.

John Curran: Any questions for Megan?

(No response.)

John Curran: Thank you, Megan.

(Applause.)

Internet Governance Panel

Cathy Handley: I’m Cathy Handley. For anybody in the audience that doesn’t know me, I’m ARIN’s Executive Director of Government Affairs. Instead of giving the regular government affairs report about where I’ve been and what meetings, after some wonderful discussions here the last couple of days, we’re doing this much different. It’s going to be no presentation. It’s going to be Mary K. Lee, who is our HR Director at ARIN, and Bernadette Lewis, who is the Secretary General of the CTU. We’re going to talk about what Internet governance is and what it really means to this region.

I’m going to read something that came out of the World Summit on the Information Society for the WSIS meeting in 2005, and I quote: The development and application by government, the private sector, and civil society in their respective roles of shared principles, norms, rules, decision making procedures, and programs that shape the evolution and the use of the Internet. That is a worldwide accepted definition of what Internet governance is. Now, that was written in 2005 and things have changed a lot.

It used to be Internet governance was the sole responsibility of stakeholders in business, academia, and civil society. It’s not the case anymore. Times are changing. As the Internet has increased and more entities are becoming concerned about its future, there’s a lot of money that rides on it. There’s lots and lots of government programs ride on it. This should be a wake up call for everybody. We can no longer set as a technical community and think we’re the only ones that have input.

At the same time, this has to be a wake up call for the governments. They can no longer sit and think they’re the only ones that run and make the rules. Mary K. had an interesting time over the last 18 months or so as someone that hadn’t really been exposed to Internet governance, so she’s going to have a chance to kind of give some things that she saw, things that worked, things that didn’t work. Bernadette, like myself, we’ve been at it for a very long time sometimes it seems like. But it can’t be that long because we’re like 20.

(Laughter.)

Cathy Handley: Don’t laugh. That’s not funny. And Bernadette has some things that she’s seen that work and don’t work. What we’re going to do is we’re going to talk a little bit – that’s why this is sort of a different arrangement than getting up to the podium. We’re going to talk a little bit about things that people have seen, things that you as the participant, the multi-stakeholders in this case, can and should do to see, to kind of spread this whole concept of we are in this together, because I don’t want to preach doom and gloom. That’s not what I’m up here for. As a matter of fact, it should be a very positive thing that we can work on. So, Mary K., you were in your office one day when I came by, unfortunately for you. And look at where it got you. Can you tell a little bit about what you’ve learned and how things have been?

Mary K. Lee: I’ll try to do that. It was probably about not quite two years ago, and Cathy mentioned I really need somebody to help do some of the trips and have another presence from ARIN be at the meetings and someone else at ARIN to learn a bit more about Internet governance, and happened to be pretty good timing for me. It was a little quieter moment on the HR side, so I started accompanying Cathy to some of the meetings. The first meeting I went to Cathy was not with me, so I got sort of the quick introduction at the ITU in Geneva to a lot of people. Luckily I had some colleagues from ISOC there who were kind and took me under their wing and introduced me to some folks and other companies.

So I did see. And we’re not here just to talk about WCIT, but I did see not all the pre-WCIT meetings but I saw five of them leading up to the WCIT conference in Dubai. It was quite an experience, something I was very glad I got to do. I did see that, and I know it’s difficult for everyone to do sometimes, that being there is extremely important. Maybe not every single meeting or maybe you’re a group of some sort, whether it’s formal or not, but someone needs to represent your interests regardless of what they are.

If you’re not there, decisions may be made, whether they’re in the conferences themselves or, as we all know, the back hallway conversations where the true business really takes place sometimes. But your opinions, the country you represent, the organization you represent, you really have to find a way to be front and center and participate in these groups. I think that’s what I saw more than anything else. There’s definitely a learning curve. I had a huge learning curve.

Still certainly on it at this point. But being there and talking to the people, being part of what’s going on, and noting the difference from the first meeting that I attended to the third meeting where I attended that subtle and gradual change where all of a sudden you’re welcomed into a group of conversation that maybe you wouldn’t have been at the first meeting. And you can’t do that unless you’re there or, say, there’s a group of you who rotate from your organization that sends you to these places. I would just say it’s essential. I know it’s difficult and I know it’s expensive. But if you’re not there, you’re not part of it.

Cathy Handley: Thank you, Mary K. Bernadette, I’ll turn it over to you.

Bernadette Lewis: It was in 2005, January 2005, that I was asked to take up the issue of Internet governance on behalf of the Caribbean, and I said Internet what? Having just concluded the whole WSIS process, I think the response would have been the same for many people within the Caribbean. And what I realized is that there was so much that I didn’t know, and I was pretty certain I would not have been alone in that position. I started contacting people in different types of organizations and we had the first Internet Caribbean Internet Governance Forum in August of 2005.

And at that forum, when we looked – Cathy read the definition, how broad and wide it is, and what we attempted to do at that very first meeting of the Caribbean Internet Governance Forum was to identify the things that were of primary importance to Caribbean stakeholders and tried to craft a program which addressed the things that we could reasonably address, the things that we felt we had the ability and the competency to address.

And we met – that Internet Governance Forum met every year, has been meeting every year. We completed our eight Internet Governance Forum in August last year. But what we also did was developed a Caribbean policy framework for Internet governance, which identified a number of strategic areas for activity. And that policy framework, which was developed through these multi stakeholder consultations, guides a lot of the work of the Caribbean Telecommunications Union.

So we would have identified, for example, critical Internet infrastructure as one of the areas and because of the CTU’s work in proliferating Internet exchange points, we now have eight Internet exchange points in the Caribbean. We have been advocating for the adoption of IPv6. And what over the years what we recognized was that, yes, we had participation from many stakeholders. Multiple stakeholders but the governments we were not getting the traction from our government primary members of the CTU.

So we instituted ministerial fora, sessions designed specifically to explain the technology, the evolution, the impact on policy, on legislation, on regulations, the possibilities for national development. And at several of these ministerial fora, we spoke about Internet governance and the need for the governments to take an interest in it and to participate in the regional and global discussion. Because more and more we are hearing our government ministers speak to the fact that they recognize information is going to be a driving force for development in the Caribbean.

And more and more they are migrating their services and their information to networked systems, to Internet based systems. So of necessity there must be an interest and must be participation in this whole scheme of Internet governance. So we have been making progress as a result of our outreach to government ministers, many of them have started, for example, committees for IPv6. Many of them have started working groups for Internet exchange points, and another area identified in our policy framework, and this is one of the areas really focusing on, is the area of – the whole issue of content and indigenous content industries for the region.

So what we have found really works well is the need to do the education and outreach from the level of the governments down to the businesses to the technical people, to the man in the street. And we have a number of different fora designed for that. And we have been seeing positive results and greater understanding and greater participation, but a lot more needs to be done. And I don’t think it’s sufficient just to give the information now. We have to work towards engineering the outcomes that we would like to see.

Cathy Handley: Thank you, Bernadette. For those who were here four years ago, this room was maybe half full. And I can’t tell you how nice it was to actually run out of room at a table because there were so many people setting there that wanted to discuss topics. At ARIN we’ve recognized what Mary K. just said, what Bernadette just said: Participation is crucial and it doesn’t have to be the same person every time to every meeting. You build a network.

You have a person from Antigua attend this meeting, a person from Barbados attends another one. But you share it. That’s what so many of the people that are sitting here in this room already know. They’re online with each other all the time.
They’re on various Public Policy Mailing Lists, whether it’s within ARIN or at RIPE, AFRINIC, LACNIC, APNIC. It’s all about talking back and forth. If you go look on the ARIN website under participation, you’ll see a link to Internet governance. Click on that and it tells you what ARIN’s doing. You can click on any of the other links and sign up to be on the Public Policy Mailing List. On any of the discussions.

If you can’t make it to a meeting – not everybody can travel every place. If you can’t make it to a meeting, participate remotely. Stacy’s been setting up here reading comments that remote participants are doing. So you can fully participate. You can make your voices heard. We are trying very, very hard to make sure ARIN stays – as well as I know the other RIRs are – truly a multi-stakeholder environment. We want everybody here. We want to have governments. We want to have private sector. We want to have civil society. You know there’s an old saying that Mrs. Clinton made at one time about it takes a village.

It truly takes everybody participating. And you’re not alone. You’re going to have a lot of frustrations trying to get – maybe get to where you want to be. But a lot of us have already had those frustrations, so you should take advantage of that. I know we don’t have a whole lot of time, but, Mary K., do you have anything else you’d like to say?

Mary K. Lee: I don’t think so, really, except to emphasize what Cathy said, your voice needs to be heard, and we do want to hear all the voices and it’s really important. If you don’t participate, there may be decisions made that you’re not happy with. So really you need to be there in whatever fashion you can be.

Bernadette Lewis: And there are creative ways. Creative – let’s use – from a Caribbean perspective, let’s use our creativity to come up with systems that would enable us to be consistently participating within the region. Not just from a regional point of view. Not in the region, but in the international discussion, right? Because we are indeed, as Cathy said, in a global village, and we cannot afford to be operating in silos and depending on the strength of our own resources. If we pool our resources, bring our ideas together, we’re in a better position to have an impact at the international fora. Thank you.

Cathy Handley: I think that’s probably the shortest I’ve ever spoken. You’re probably happy about that. We’ve got some time, and one thing I would encourage is anyone that can come up on the mic and speak positively about experiences they’ve had in participating in some of the fora and that and would welcome any other comments or anything anyone has to say.

John Curran: I’d like to pause for a moment for a round of applause for our panelists.

(Applause.)

John Curran: Their efforts have been remarkable in this area. I constantly receive praise. Certainly Mary K. and Cathy’s efforts. And Bernadette, I see myself when I go to these events, I know she also puts in remarkable times, and I’m sure her CTU constituency appreciates all the efforts as well. So we’ll now open the microphones for any questions or comments people want to make.

Cathy Handley: Owen, I’m sorry. I’m not sorry you’re Owen; I’m sorry I didn’t see you.

Owen DeLong: Yeah, no problem. Owen DeLong, Hurricane Electric, ARIN Advisory Council. I want to thank the three panelists. I’ve been working with them for several years on some aspects of this, and it’s been a real privilege.

I’ve been privileged to be with ARIN at the CANTO conference. For those of you who don’t know, that’s the Caribbean Association of National Telecommunications Organizations – do I have that right, Bernadette? And it’s an annual conference where a lot of the Caribbean operators and various other network providers get together and there’s a lot of government representatives as well. It’s a pretty high level conference.

It’s also a very, very good time and we have a lot of fun, but we get a lot of work done. And it’s a very good opportunity to interact with people, and I’ve been very privileged to participate in that.

Cathy Handley: Thank you, Owen. Thank you, everybody.

Open Policy Hour and Open Microphone Session

John Curran: Microphones are open for anybody who would like to bring up an open policy matter. Mr. Springer at the front.

John Springer: I’m John Springer with Inland Telephone and also the ARIN Advisory Council. Yesterday Leslie gave us a presentation about some things to do, and three of them are going to be a lot of work, but one may not. So I’m going to propose a policy tomorrow at our AC meeting to do some housekeeping on 8.2 to reinsert a term that was apparently inadvertently dropped on our last edit. I am seeking preliminary comments from the group that’s here so we can take those into consideration tomorrow.

Problem statement. There is no longer a reference to corporate reorganizations in NRPM 8.2. And ARIN is seeing corporate reorganizations as a basis for transfers under 8.2. Corporate reorganization wording were part of the previous policy of 8.2 as follows, quote: ARIN will consider requests for the transfer of Number Resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity’s use of the Number Resource.

Current policy reads: ARIN will consider requests for the transfer of Number Resources in the case of mergers and acquisitions under the following conditions, dot, dot, dot. Corporate reorganization is being used as a valid reason for 8.2 transfers today under the following conditions: Parent organization can transfer resources to a child organization or vice versa as long as the child is 100 percent wholly owned subsidiary with various documentary requirements that apply. So that’s the problem statement.

Essentially what I’m going to suggest is that we substitute the following proposed policy text “ARIN will consider requests for the transfer of Number Resources in the case of mergers, acquisitions, and corporate reorganizations under the following conditions,” dot, dot, dot. So the difference between existing policy and my proposed policy text – which is admittedly a little cart before the horse here, but why not – is merely the addition of the phrase “and corporate reorganizations” to the existing policy text.

John Curran: Would anyone like to come speak to that?

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I support the proposal mostly. I just wanted to clarify one thing with John. Did it say corporate reorganization previously or reorganization? Because my suggestion would be to remove the word “corporate” as it is limiting and was not in the previous text was my understanding. So just reorganization, not corporate reorganization. So my suggestion would be as it stands just without the word “corporate,” to keep it in line, which I believe was your content.

John Curran: Leslie, was it in the prior text as corporate or just reorganizations? Just reorganizations, okay.

Kevin Blumberg: Otherwise it’s a beautifully written policy.

John Curran: Yes. At the table.

Bill Darte: I’m Bill Darte with the Advisory Council. One of the questions that we will struggle with is whether this change is substantive or not. And that will determine the ease at which this change would take place if supported by the community. So I’d be interested if everybody thought this was just a wordsmithing, editorial change or whether this was really a major and significant change in policy.

John Curran: Go ahead, Jason. So I’m going to say for the record, if people believe it is not a substantial change, then staff will very quickly move to get the AC to consider an editorial update to get the words back in there because we considered it an oversight and are operating in this manner. So I either suggest that the AC consider the policy and make a determination one way or another if it’s desirable, or adopt an editorial change and incorporate it because we have viewed this as an oversight. If that’s not how the community views it, we need to know that, and the AC is the only party that can determine that.

Scott Leibrand: Scott Leibrand, ARIN AC. Specifically our practice to date has been if anyone objects to considering it an editorial change, that’s grounds for making it a policy matter. That’s true both on the AC, but I would also say it’s true for any substantial objection from the community. So if anyone thinks this is going to change policy in any significant way, they don’t like the idea or anything like that, please speak up so that we can make sure it goes through a full policy cycle; otherwise, I’d be entirely in favor of making this editorially.

John Curran: If you do not make this as an editorial change, it absolutely has to go to a policy cycle to be affirmatively determined one way or the other so staff knows we’re in sync with what you want us to do.

Chris Grundemann: Chris Grundemann, ARIN AC. I’m sorry; I left out the word “reorganization” when writing this. The intent of the policy change that actually caused this was simply to align 8.2 transfers more with 8.3 transfers. There was no intention to remove reorganizations from the text. That was just a textual oversight.

John Curran: Which is why we’re operating according to the existing practice when it comes to reorganization. But I love text that says how we should operate.

Jason Schiller: Jason Schiller, Google. On the question whether or not this is a substantive change or not, I would like to ask the question to ARIN’s staff about their current practices and how that would change if this proposed policy passed, if at all.

John Curran: If the AC considers this matter and approves it, our practices will not change. If they disapprove it, we’ll stop doing it. Okay? Hence the reason for AC consideration of the matter.

Jason Schiller: Thank you for the clarification.

John Curran: Microphones remain open. This is the Open Policy Hour. Does anyone have anything they’d like to come speak about? Come on up.

Chris Grundemann: Basically this is not my work. I’m presenting work that was done by Tony Hain. This is a follow up to what we heard from Leslie yesterday in the Staff Experience Report regarding some new organizations that are in slow start right now which are coming back for space and ramping up their allocations.

So there are exactly 31 organizations from the public records that are in slow start and are coming back and doubling. Most of them are doubling every time they come back and they’re coming back every month or two months, it looks like, in general. And some of them are more than doubling; some are going out by two bits, they’re quadrupling each time they come back.

Like I said, there’s 31 of them. In addition to that, there’s 24 other organizations which, within the last nine months, have come back multiple times. It appears that they’re hitting the three-month allocation window and actually coming back every couple of months and getting more space on a pretty significant basis. So all the other projections that we’ve seen to date have been based on large sets of data, so going back through the entire history and trying to trend from there.

Tony basically, last week, took this new information into account and did a weighted projection that weights more recent allocations stronger than older allocations, basically dividing one buy today minus the first of each month. So the weighting decays historically and uses that as a modifier to the actual rate of change for each month and then built this forecast based on that. So the forecast itself is the little green line, which drops to the bottom right about the middle of August on this map. So that would be ARIN’s free pool emptying. So you can also use the historical data and run a sixth order polynomial projection which actually creates a pretty identical curve that hits the bottom a couple days beforehand.

This is a slightly slower curve than what we see at APNIC. And so according to the information I’ve gotten from Tony, right, what we’re looking at is this is fairly aggressive, but it’s actually still, like I said, a little bit lighter than where APNIC went down. And considering that both APNIC and RIPE have basically run out of free pools, or you can only go back for the single dip /22 in both of those regions, many of those organizations are multi national corporations that also have offices here in the US or within the ARIN region. And so this actually, based on that, could potentially be conservative. But a data point that maybe needs to be taken into consideration for further policy considerations.

John Curran: Right. At present, the last time we looked at depletion at ARIN, the rough approximations were 12 months to 16 months – 12 to 16 months out and that was two months ago. But we are seeing an enormous increase in demand recently from parties coming back; and as noted, when someone comes back, if they’re moving very quickly, they’ll get one bit larger for their next assignment. So there’s a potential that instead of having 12 to 16 months, we have four months before the free pool depletes if those two estimates are accurate.

Chris Grundemann: One more point, looking at this obviously as organizations get larger, it’s harder to keep doubling. But if even half of those 31 organizations continue on this trend, then this becomes pretty accurate. If all of them continue doubling, this sucks in quite a bit more. So roughly that could be – anyway something to consider.

John Curran: Would anyone like to comment? The microphones remain open.

Chris Grundemann: I’ll point out the link on the bottom, again, this is Tony Hain’s work. There’s a PDF, a link there which has actually all the data he’s using to base this on, which is basically the last nine months of allocations from ARIN, and it shows all the organizations and what size blocks they’ve taken in a really neat format.

John Curran: This is related to the item in the Policy Experience Report that Leslie gave. We noted that there is some usage of organizations, where the organizations are in the region, where their equipment is in the region but their customers may not be.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. The first question I have is, is there anything that you’re suggesting from a policy perspective, or is this more informational in terms of, by the way, folks, it’s pretty damn close?

Chris Grundemann: From my perspective, this was just news to me. And I figured it would be wise to share it with the wider community. Again, this is a projection. So take it for what it is. Your miles may vary, but I thought it was interesting to look at the fact that if this drops off in July or August, that means before we have another Public Policy Meeting, ARIN could be out of free space. So the NANOG Public Policy Consultation would be the last chance to talk about policy before free pool exhaustion potentially.

Kevin Blumberg: So the second part of that was more directed at ARIN’s staff, based on Leslie’s talk yesterday where basically there was a question about the validity of many of these requests. And the question is should staff be revisiting or re-scrutinizing or scrutinizing to a different level, or are we too late at this point? I know that their hands are tied to some degree in this regard, but are what we’re seeing an artificial run out in that it’s not from the region that this run out is occurring because of?

John Curran: The answer to the latter question is yes. And on the former, there’s no additional scrutiny possible. I can send you – if I send you a list of customer ads and I give you addresses and names and they’re all potentially not even in English, they’re related to countries outside the region but that’s where your customers are, they may be using resources hosted within the region and connected within the region. There’s not a lot we can do to validate. We can do some spot checking, but the level of scrutiny, even at maximum, again according to policy, as Leslie’s pointed out, we don’t have a basis for saying no.

Kevin Blumberg: Okay. Thank you. I’ll let somebody else talk.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I don’t think that it makes sense to apply additional scrutiny. I think we sort of have seen this coming for a long time. I’m surprised it took this long to get here. IPv4 is running out, folks; that shouldn’t be news to anybody. Move on.

John Curran: And I have no comment one way or another. I just want to point out: At run out, ARIN will have people coming to it, for example, small ISPs coming and saying: I’d like some resources and there’s already a chance that they will be very surprised that there are none. The surprise may be increased if there are none because of a precipitous drop in the final four months, and it’s just we need to be prepared as a community that we made a conscious decision on how we approach this.

I didn’t say how we approach this problem, I said how we approach the situation. It’s a fine situation as long as the community thinks it is. It’s a problem if you decide it is, but we would need to act one way. We need to not act or consciously act quickly and we need to decide that very promptly.

Bill Darte: Bill Darte from Advisory Council. But ARIN website sort of talks about the remaining free pool, right? And so I don’t think you will publish an expected run out date, right? But in the past the ARIN Board of Trustees has made public announcements about this run out and the importance of that. And so if no policy matters would arise in this community for us to deal with, it would seem reasonable that if, to alleviate some of those surprises, maybe more of that kind of action ought to take place soon.

John Curran: For example, this week I believe we’ve dropped from 2.49 to 2.43 /8s over the course of this meeting, in aggregate. I can do the math real quick, but the countdown timer’s now starting to actually look like a countdown. So it’s not a problem. It’s just not obvious to people who go and look at the ARIN web page that that’s underway.

Bill Darte: I understand. I’m suggesting that maybe you ought to find some other media to inform people that this run out seems to be accelerating, if you’re concerned about surprises.

John Curran: I’m not concerned unless the community is concerned. I want to be very clear. I’m asking if you’re concerned about surprises. If you’re not, it’s not a problem. I get to say we looked at it; it’s fine.

Kevin Blumberg: So my concern with this is that other regions have a cushion. They have a cushion for the people that don’t look at the ARIN website. They have a cushion for the people that live in – I know that a lot of people are not sympathetic to these people. But they have that one kick of the can of the /22 in the other regions. We have nothing. We’re done. With this rapid acceleration, with no cushion, it just means it will be over. Is that something that the community is interested in having: A small block reserved out for final /22s or /21s depending on what’s available? There’s a block for each company –

Stacy Hughes: Come to the mic, please.

Andrew Dul: Andrew Dul. ARIN does have a reserve block, a /10 which allows from /27 to /24, and there are requirements about that. They are different than the other regions, but we do have that buffer if that’s what you want to call it.

Chris Grundemann: Right. It’s for transition technology specifically.

John Curran: That’s the transition block; it’s not a general purpose block.

Andrew Dul: Right. But if you’re not transitioning at that point then you’re not really operating.

John Curran: Okay. Next – yes, you want to stay up – is this on the depletion, people want to continue to talk on that topic? Yes, R.S.

Rob Seastrom: Rob Seastrom. I just wanted to reply to Kevin and say that there is always the transfer market for those organizations. And I’m sorry that things have just gotten a whole lot more expensive. But things are getting bad and getting worse, and I think that I want to quote Andrew and say: If you’re not transitioning, you’re not operating.

Kevin Blumberg: I do not disagree with you in the slightest. I’m ambivalent to this. I’m actually trying to gauge the room and see if that cushion, especially with how we’re seeing that last bit depleted, if that cushion is something that the community’s interested in. I actually am ambivalent either way.

Rob Seastrom: I’d love to hear from others in the room, as well.

Jason Schiller: Jason Schiller, Google. We’ve discussed this many times. And the discussion basically plays out like this: We should take a chunk of address out of the general use pool and hold it back for a special use that some people need at some point in the future. And then the response is why is it more fair to not use a needs based policy that we’ve always used since the beginning of time and withhold addresses and make them not available to people who need them now in order to make them available to some potential need in the future. And at the conclusion of that discussion, this community decided we should run until we hit the wall.

(Laughter.)

John Curran: Okay. Any other comments on this? Remote participants? No? Very good. Chris, thanks for raising it.

Chris Grundemann: Deploy IPv6. Thanks.

(Applause.)

John Curran: Jason Schiller.

Jason Schiller: Jason Schiller, Google. We’ve danced around a very specific question that there is use of ARIN space by customers that are outside of the ARIN region that are getting transit from gear that’s physically located in the ARIN region. And I think it’s been suggested that we should ask, assuming the customers are real and they’re not committing fraud, is this usage something that this community finds acceptable? And if it’s not, should we suggest to the Board to take some emergency action based on some suggested policy of why this use is or should be out of policy?

John Curran: So people who want to speak on that, approach the mics, the mics are open. Yes, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. My concern with any such policy would be how to identify those users without accidentally roping in other uses that are sort of on the periphery but intended to be still permitted or even how to identify those users separate from domestic users in general.

You know, is there a meaningful distinction between a client getting IP transit over a tunnel from Asia and using services in the US and therefore getting US address space for that versus a client running a node in a datacenter in the US or somewhere else in the ARIN region for that matter, and how would we tell the difference between those two even if it were considered a meaningful difference. So I think that this would involve heroic measures to do a great deal of rearranging of deck chairs for a very, very small amount of freeboard.

John Curran: Front center.

John Springer: John Springer, Inland Telephone, ARIN AC. The one part of this discussion that was most problematic to me was the inability to establish contact with any of the registries in such a way that you could communicate with them. If we’re going to take this last two and a half /8 equivalents and plug them into a black hole that doesn’t speak English, that doesn’t sound to me like a very good idea. And I disagree that that would be heroic measures for no purpose.

John Curran: Let me respond for clarity. We do ask when someone shows up and says I need more addresses because I’ve used them for customers, they self declare these are the customers and we are the customers in all countries all over the world, there’s a slightly higher probability of those customers being fraudulent than when we get that from someone else, because they may be in a foreign language. It’s sometimes more difficult to verify. We do spot check this stuff.

There’s a slightly higher risk. But in many cases these organizations are saying no, they’re legitimate customers, they all exist, they’re making those representations. They’re being very plain that the ultimate customers are outside the United States. We take a risk with any assignment, regardless whether someone’s in the region or not in the region, that their customer list that they’re using to justify is fabricated. We have steps to try to determine that. There’s a higher risk, but that doesn’t mean that they’re not legitimate. It’s just there’s probably slightly more getting through, if that helps explain it.

Does that answer your question, Owen, about distinguishing? We can distinguish the ones who say my customers are all outside the US. They’re self-declared to that extent.

Owen DeLong: But that’s not what I’m trying to distinguish. My point is you can have a customer outside the US, and we certainly would want to allow a customer outside the US to have an IP address in region for a host, a virtual host that is being operated in region. How do you distinguish that from a customer who is instead using that address to receive service outside of the region?

John Curran: Got it. Much clearer. Thank you. My customer is overseas. My virtual host is in a datacenter in Irvine, California, and it’s a legitimate host and a legitimate customer.

John Springer: My shell company is in Irvine, California. My customers are all overseas, and I don’t answer my phone anymore and the technical contacts don’t speak English. I thought I heard that scenario expressed as a greatly growing problem.

John Curran: Correct.

John Springer: And that just doesn’t seem like heroism to try and step on that particular thing’s neck.

John Curran: That’s for the community to determine, yes. Okay. Center front.

Mark Elkins: Mark Elkins, AFRINIC Board. I suspect a lot of these customers are on the end of a satellite in a number of countries within Africa where they have like a /24 of IPv4 space. And I guess that I would love them as customers in my region and so that you can get your space back, back to this region. And if this happens and they go through the horrible, terrible painful process of renumbering, et cetera, et cetera, you might buy another two to four weeks of IPv4 address space here. I don’t think it’s worth it.

John Curran: Center rear.

Rob Seastrom: Rob Seastrom, ARIN AC, Time Warner Cable, and speaking on my own behalf here. I’m also skeptical about any kind of heroic measures, anything that ARIN could do incrementally as far as looking at ways to incrementally improve the auditing without exerting huge amounts of effort, time, money, et cetera, would certainly not be out of place. But I don’t think that we would gain much from that either.

To Mr. Springer’s point, I don’t have to go more than a dozen miles from my house to find a place where the core customer base is all people who were born in another country. They don’t answer their phone in English, and yet there’s nothing fraudulent going on at all. They sell Asian food.

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

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I’ll keep it short because I know we’re getting close to break time. What happens – very shortly we’re going to start getting into the next phase in regards to scrutiny. Correct? And is ARIN going to be able to scrutinize at the more stringent level? Is this something that’s going to cost the corporation significant resources and funds to be able to deal with? And is that – maybe this isn’t a policy issue, this is more a corporate issue at this point.

John Curran: Let me try to be clear. If people thought it was a policy issue, okay, then that probably is something people need to move quickly on and address, because presuming total veracity of every application they still don’t believe it’s appropriate for the policy to be used in that way.

If that’s the case, we’re going down one path. If that’s not the case and the community thinks that the usage was fine, as long as it’s true, the applications are true, yeah, when we hit the boundary, we’re going to probably expend more resources in those final two /8s making sure those applications are true. I wasn’t going to invest in that until I knew whether or not that was a valid use in that the community had thought about this. But even if nothing else happens, we might take some more costly measures to try to verify these.

For example, you can use databases. You can use people who have language skills in other languages. We’ll probably, once we get to 2.0 in the free pool, start doing that for these applications. That won’t change the fact that a lot of them are probably quite valid and are still going to drain the pool very rapidly. But it’s worth doing just to make sure they’re accurate. Does that help?

Kevin Blumberg: That helps. But my final comment to this, similar to Owen, forgetting the word “heroics,” I don’t believe we can make a radical change to our policy to exclude a base where fundamentally what they’re doing is not wrong. Their IPs are being touched in region, and I think it will actually create an issue where there is unintended consequences across our entire policy that we never thought would happen with something like this.

John Curran: Okay. Center front. Remote, center front – remote.

Stacy Hughes: It’s Marla. Hi, Marla. Marla Azinger, Frontier: No, not worth spending time on sifting and sorting more than done already. Customers can live in any location and use processing services in the ARIN territories.

John Curran: Okay. Center front.

Scott Leibrand: Scott Leibrand, ARIN AC. Plus one to everyone who said don’t worry about this unless it’s fraud. But I have another topic if we’re done with this one.

John Curran: Anyone else want to speak on the topic of in region use for out of region customers? No. Next topic, Scott.

Scott Leibrand: One of the other things that Leslie brought up in her Policy Experience Report was the definition of LIR versus end user. I have a thought on how that definition might be tightened up. I don’t know if I mentioned it. I also work for Limelight Networks. As I currently read the policy, Limelight Networks is neither an ISP nor an end user because we do not primarily assign IP addresses to downstreams, and we do not exclusively use them for our own purposes. We mostly do it for ourselves and we have a couple of downstreams.

So I would propose that we tighten up those definitions by removing that word “primarily,” which leaves us something like an LIR is an IR that assigns address space to the users of network services that it provides, and then the second sentence to that I would reword to be something like, for example, ISPs that reassign addresses to end users and/or reallocate to other addresses or LIRs. I’ve talked to a couple of people at socials and stuff that have other ideas about what the definition of LIR versus end user should be that key on other things than whether you do reassignments. I think that’s the central issue. But if people think that there are other things that we should be basing our definition on, I think now would be a good time to discuss those.

John Curran: Please come to the microphone if you want to speak about end users versus LIRs. If you’re still thinking about it, remember there’s a break shortly. And Scott’s the gentleman in the white striped shirt. You can find him – down here.

Bill Darte: I would only say since there wasn’t a rush to the microphone I publish those – that language on the PPML and ask people to respond there.

John Curran: Okay. We’re actually –

Dan Alexander: Dan Alexander, Comcast, ARIN AC. I’d actually – in this conversation about ISPs, LIRs, end users, I’d be curious for people’s opinions on at this point in the game, and also given some of the comments Leslie made, whether we need the distinction between all these categories of users and whether we just start looking at merging all of these very lengthy, convoluted sections of the policy manual just into a very straightforward: If you need space, here’s how much and here’s why, and call it a day.

John Curran: I was going to put myself in queue first. But let’s go down at the end.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Thank you for reminding me. We just talked about v4 and a bunch of stuff and, yeah, we can – it’s going to be gone here, and, yeah, we still have to worry about transfers and a couple of other things, we really shouldn’t be focusing too much on v4. We should be focusing on v6. And I would argue that in our v6 policy terms, there’s actually a significant distinction in what we give out between what we think are end users and what we think are ISPs. If you’re saying everybody should just get a /32, okay, fine, but you better be careful what you’re saying.

John Curran: Remote participant.

Stacy Hughes: Marla Azinger, Frontier: I think we should remove any difference at all and not have end user versus ISP. I don’t see the advantage other than the fee issue.

John Curran: And I was just going to respond: ARIN staff is a huge fan of simpler over more complicated policy. To the extent that you want to simplify policy, it makes our job easier. It makes our conversations with customers easier, and it prevents misunderstandings. Having said that, you don’t want to spend five years simplifying policy that you don’t need after three. So if you’re going to do it, do it promptly so we can get the benefit of it for a period of time. Okay. I’m closing the microphones because we’re going into break. Yes, last person at the mic.

Mark Elkins: Anonymous. I’ve got a couple of buttons which I’d like to give away.

John Curran: Okay. And we’re going to go into break. We have a break outside. Refreshments. And I will say that the only thing on the agenda for the remainder of the day is the continuation of the Open Microphone. So we’re going to have a break for 30 minutes. We’re going to come back at 3:30. And then if you folks have nothing more to say, we’ll actually move to adjournment, but maybe you’ll be spurred to great ideas by your conversations over refreshments. I’ll see you back here at 3:30. Thank you.

(Break.)

OPEN POLICY HOUR AND OPEN MICROPHONE (continued)

John Curran: We’re resuming the Open Policy Hour and Open Microphone. And hopefully your conversations outside have been wonderful and entertaining.
And at this point I would welcome – the microphones are open. Please approach them for any enlightenment that has happened. Not a lot of enlightenment since before the break. Yes, Stacy.

Stacy Hughes: I have a “here here” from Kevin Otte about encouraging IPv6 adoption.

John Curran: Here, here encouraging IPv6 adoption. And the statement was he wants to say “here, here” with respect to encouraging IPv6 adoption. Microphones remain open. If anyone would like to speak to any of the policies that we’ve discussed, if anyone would like to speak to the items on the Policy Experience Report, now would be the time to raise them.

Scott Leibrand: Scott Leibrand. Addendum to what I said earlier: I’ll probably search and replace LIR with ISP, and I’m thinking about making that a definition of ISP and making the NRPM consistent. If anybody has any thoughts on that, let me know here, offline, whatever.

John Curran: Okay.

Heather Schiller: I still have to stand on my toes. So what I’m about to say might not make any difference if we’re out of space in a few months anyway, but there’s been some discussion on the list about providers or smaller providers not being able to get address space from their upstreams.

I think there’s sort of an unintended consequence that we might not – I really haven’t heard anyone else sort of talking about we might not have noticed or might not have seen coming in that providers are choosing, potentially choosing, who to give address space to and denying requests not based on whether they have space or whether space is available to them, but whether they want to give address space to a particular set of users because it may be difficult for them to get address space later. And they may be able to have – give address space to higher revenue generating users than other users, and sort of these interesting side effects happening. And it’s interesting to me that it’s occurring while folks can still get address space.

John Curran: Can I ask, is this with respect to service providers giving their customers who are enterprise and end users, or giving customers who are ISPs, you’re thinking?

Heather Schiller: So the case that came up on PPML, I think they were an ISP. Yeah, they were an ISP. So from what I understood of that, he was saying that he did not directly – as a small ISP could not qualify for address space.

John Curran: Right.

Heather Schiller: From ARIN, he was a small ISP so he did not qualify for address space from ARIN as an ISP. He did not meet the requirements. And so the sort of suggestion was do we – what do we do about these small ISPs where in the past the recommendation has been you go to your provider and get address space, but now the provider is saying: We’re denying your request not because you don’t meet some set of requirements to get space, but because we want to save the space for someone else.

John Curran: Right. Now, obviously we don’t want to get between the provider and his relationship with his customer, the smaller ISP. And so we’re not in a position to review whether the provider is acting fair or unfair or not, because that’s his relationship. In a healthy, robust market, the ISP, little ISP goes to another provider who doesn’t do such horrible things, doesn’t that answer the question?

Heather Schiller: No, there may not be an option, right? Because that’s part of what he was saying.

John Curran: So there may not be an option – there might not be a nice ISP who is willing to give them space.

Heather Schiller: Sure. And I think the thing that I want to like poke at more is like is this happening more often, like is this going to start happening more often? I don’t feel like that was a consequence that I foresaw coming.

John Curran: Would anyone like to comment on that? Dave.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I would just say that there are plenty of places in the US where there’s really only one primary access, upstream provider. You, in theory, could find others, but they’re economically infeasible, even if they are nice.

John Curran: Good to know.

David Farmer: And I was just going to finish. In that – forget it.

Kevin Blumberg: Kevin Blumberg, The Wire. My understanding is in Canada there’s hundreds upon hundreds of wireless ISPs, very small, that have very small customer bases without their own ISP space; they’re getting it from their upstream in many cases. They can’t go to ARIN in the first place. I’m actually more worried about when run out does occur and the ISPs realize that this is a great pool of cheap IPs because these customers, quote/unquote, aren’t actually paying them that much because they’re only transit.

So that’s actually precarious that they’re not using ARIN and they don’t have their own IPs right now, and I don’t think that they’re aware how volatile having a larger block of upstream space can be. That being said, I think the solution to this is to align the end user a /24 to the ISP to lower the requirement. I don’t think – which would bring it down to a /26 of space. And I don’t think that anything beyond that we could deal with unless we totally take out the slow start for the initial allocation of an ISP, which I would also potentially at this point in the game be happy with.

John Curran: Presumably the slow start is there for a reason, but if it’s putting ISPs in a situation where their upstreams won’t give them space and they can’t turn to us as a result of it, it needs to be looked at. To the remote.

Stacy Hughes: Marla Azinger, Frontier: I’ve not seen an event where selective granting has been conducted at Frontier. The only ones I see increasing with complaints are unjustified requests. They want to hoard and they don’t get to and then they complain they’re getting unjustly denied. What I question is how many, if any, companies are getting denied space that is actually justified.

John Curran: Okay. Good point. Center front.

Jason Schiller: Jason Schiller, Google. I think that this is also a problem in the residential space as well. We have seen – we’ve heard a number of residential providers that are feeling the address crunch and are moving to CGN, and they’re making conscious decisions about which customers get placed behind CGN and which don’t. For example, single play customers might be behind a CGN but triple play is not, or power users paying extra for high bandwidth get a non CGN IP address.

John Curran: Right. I believe we’ve seen some of that. Microphones remain open on this topic. Yes, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I would like to actually suggest that I think the best solution to this is to simply eliminate the from an upstream ISP clause in the current requirements and that the person be able to show use of a /24, /23, whatever, efficiently, whether that’s using RFC 1918 space or upstream space, or whatever space they’ve had to cobble together to get those customers running in the interim, and it is actually merely the from an upstream ISP clause on those two sentences that has become most problematic.

John Curran: Interesting approach.

Owen DeLong: In general, however, again IPv4 hurts. IPv4 will hurt more. IPv6 hurts less.

John Curran: Okay. Microphones remain open. Center front, Scott.

Scott Leibrand: Scott Leibrand, ARIN AC. I think in that context it’s worth reiterating something said on the mailing list, to count users who should be justified to get IPv4 space is users who have been given IPv6 delegations. If you’ve given /64s to 500 users, then you’re pretty justified in getting a /23 or a /22. I think that is something that we should consider as a possible – we’ve had v6 policy dependent on v4 before. It’s not out of the question that we should have v4 policy somewhat dependent on v6 in some cases.

John Curran: As long as you understand whether you’re talking about assigned or used, or it’s very easy to assign a lot of v6 space to things. You can assign them to tables, chairs. So you just want to – AC needs to be clear in what it’s saying has to happen for that IPv6 usage.

Scott Leibrand: Device is using, yeah.

John Curran: Microphones remain open on this topic or any other topic. Any other topics? I’ll be closing the microphones shortly. This will be the end of the open microphone session. Any other policy thoughts? Last chance. Closing the microphones, closing the remotes. Okay. Thank you everyone.

(Applause.)

Closing Announcements And Adjournment

John Curran: So this brings us to the end of the second day. I’d like to thank our sponsors. LIME.

(Applause.)

John Curran: Also Google, of course, our webcast sponsor.

(Applause.)

John Curran: Some announcements. Karaoke tonight. Okay. If you join us between 9:00 and 11:00 in the Careenage Bar, we’ll have karaoke. We’ll be hosting the bar for the beginning of the event. So if you get there, there’s drinks available for that period. After that it switches over to you. So for folks looking for something to do tonight between 9:00 and 11:00, you can belt out those favorite songs. Great opportunity. Don’t forget the meeting survey. Go to www.arin.net/ARIN 31/surveys. All respondents will be entered to win a Google Nexus 10.

Reminders: Tomorrow breakfast is at 8:00 a.m. and the Member Meeting will open at 9:00 a.m. The ARIN Member Meeting is open to everyone. You can see the meeting materials online. We’ll hear reports from all the departments as well as the Advisory Council and Board of Trustees. So thank you very much. This concludes today. I hope you folks enjoy the social evening. We’ll look forward to seeing you tomorrow at 9:00 a.m. Where is the Careenage Bar? It’s on the property. Lobby level. Okay. Thank you very much.

Network Sponsor

Webcast Sponsor