ARIN 33 Public Policy Meeting Transcript - Monday, 14 April 2014 [Archived]

Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting.

Opening And Announcements

John Curran: Good morning, everyone. My name is John Curran. I’m the president and CEO of ARIN. I’d like to welcome us all to ARIN 33 in Chicago. If you’re out in the hall, come on in. Get a seat. We’ll get started. Okay.

So I’d first like to say welcome, everyone. I’m going to do some introductions up here. At the meeting this week, we have our Board of Trustees: Paul Andersen, our Vice Chair and Treasurer; Vint Cerf, our Chairman of the Board; myself; Tim Denton, Secretary; Aaron Hughes, out in the audience; Bill Sandiford, also out there somewhere; and Bill Woodcock. Very good.

We have our Advisory Council here, including Chairman Sweeting and Vice Chair Dan Alexander. And then if the AC will all raise your hands or stand up. Raise your hand. Stand up. Go ahead. Fine. These are the members of the Advisory Council, and they’re here elected by you to help with the Policy Development Process. They’re the ones who shepherd the proposals through the process, reflect the conversations that happen on the mailing list and at this Public Policy Meeting. If you have any questions, you can find them. They all have badges that say Advisory Council.

Feel free to ask them any questions you might have about the Policy Development Process or what’s happening with the proposals at any time. We have the NRO Number Council: Ron da Silva, Louie Lee, and Jason. Can you stand up? Ron, Louie, I’ve got Ron. I’ve got Jason. And I don’t see Louie or the hat. No? Okay. So Ron, Louie, and Jason are elected to the NRO Number Council, there’s Louie. Good morning, Louie, which is the body which works within ICANN as the Address Supporting Organization that harmonizes global policy.

So they work on the policies that are proposed between the regions that will ultimately be executed by IANA for administration of number resources.

We have our RIR colleagues here. I’ll ask you to stand up if you’re from one of the RIRs: Ernest and Arthur from AfriNIC; from RIPE, Dmitry, Andrew, and Kaveh; from LACNIC, Sergio; from APNIC, Pablo, Guangliang, Byron, and Gaurab. Yes, yes, yes, yes.

Our RIR colleagues come to the meetings because they’re monitoring our developments in policy, because obviously we all have one global number resource pool to manage. Obviously things that happen here of interest to us, and things that happen in their regions and vice versa are of interest.

The ARIN management team is here. Myself, Nate Davis, Chief Operating Officer. Nate? Cathy Handley is not here. I think she’s in Geneva or traveling. Somewhere. Richard Jimmerson, our Chief Information Officer; Erin, HR and Administration in the back; Susan Hamlin, who runs the staff that run the meeting; Mark Kosters, our head of engineering in back; Leslie Nobile, who runs the Registration Services desk; and Val, who runs our Financial Services Department also in back.

I’d like to welcome our ARIN 33 Fellowship recipients. The Fellowship Program provides for funding and travel support for those people who might not otherwise be able to attend the meeting in order to help get outreach of ARIN to other communities.

So we have three recipients: Jose Alvarado, yes, Jose; Brett Henrich, Brett, yes; and Kevin Powell. Those are our three recipients who will be participating in the meeting and helping bring the message back to their communities. And they all have Advisory Council mentors. Stacy Hughes, Owen, and John Springer are acting as mentors for those Fellowship recipients.

I’d like to introduce ARIN has a new PR firm. Occasionally we have to get our message out to the public at large. We’ve hired a PR firm to help us with that. Meredith and Lori, are you here? Meredith and Lori. You may have them come up to you during the meeting ask you about what you think of ARIN, our messaging. Don’t be surprised. We invited them here to the meeting to get an idea what we’re really about. A lot of what ARIN is takes place in these meetings as opposed to just back at the office.

Okay. I’d like to welcome the first timers. I know folks here for the first time met the management team yesterday and some of our elected representatives. For those people who were there from the first time meeting, we have a prize drawing now.

I look here at your survey forms and I ask Owen DeLong to come up. This way it’s above his head. Reach in and grab one survey. Very good. Thank you, Owen.

And our winner of the $100 gift certificate to ThinkGeek, for completing their survey, is Jason Craft. Jason? Yes.

(applause)

John Curran: We will email that to you, Jason. The money is in the mail.

Okay. I’d like to welcome our remote participants. Our remote participants have access to the webcast of the proceedings, have a live transcript, which they get to follow. They have the same downloadable meeting materials, including the Discussion Guide.

There’s an online chat room which includes a virtual microphone they can ask questions at, and they can participate in policy consensus, show of hands in that same chat room.

Okay. Attendance for the ARIN meeting. We have 139 attendees from the United States; eight from Canada; two from the Caribbean; 16 from outside the ARIN region; and 25 remote participants.

I’d like to thank our sponsors. Network connectivity is provided by ServerCentral.
(applause)

John Curran: And RCN Business as well. Thank you, RCN Business.
(applause)

John Curran: We actually have the President and Chief Executive Officer of ServerCentral, and I’d like to invite him up, Jordan Lowe, to say a few words.

Jordan Lowe: Good morning, everybody. Thanks for flying into Chicago. Chicago recently got a rare distinction of having the top two airports in the country: We recently won the first and second place for most delayed departures.

(applause and laughter)

Jordan Lowe: Again, number one and number two; that’s O’Hare and Midway, both about 48 percent delayed departure. Good luck getting out of here. You can say it was for our weather. I do want to say it was 75 degrees on Saturday, but that’s going to be the end of it for season.

Many of you don’t know this, but back in 2003 we also hosted the ARIN meeting; that was a joint meeting with NANOG. Quite a lot of fun back then. Back when you were able to borrow wireless cards for your laptops, there was a terminal room to Telnet back to your routers and fix whatever was broken. If you can raise your hands if you were here back in 2003, put your names up there? Can we get a round of applause for everyone that was, still with us.

(applause)

Jordan Lowe: Which is really great. Everyone stayed.

So back then things were very different. We weren’t able to just get a fast connection out to the hotel. So back then we had to build a wireless network to get anything more than a T1 into the building for ARIN 2003. We ended up building a really cool wireless network with the help of some of our customers, but there wasn’t any infrastructure in the building to support this. So we ended up coming in on a Saturday before the meeting and running cable all the way down the riser, which was through all the maid closets through the entire hotel to get cable down from the roof to give us a great connection.

A lot easier these days. RCN has fiber into the building. We asked RCN if they would do us favor of giving us one of their fibers; they said we’d love to. We wanted to thank RCN very much. Now we have a nice gigabit connection here, which is really only limited only by the router we have just because it only has gig ports. Hope you enjoy the Internet.

That’s it. Thank you guys for coming out. We appreciate it.
(applause)

John Curran: A little history lesson. A lot of fun. Okay. I’d like to now move us ahead to the opening. We have a pretty busy schedule. More sponsors. I’d like to thank Google for our webcast.
(applause)

John Curran: I’d like to thank our social and break sponsors, Level4 Hardware, ServerHub, Eonix.
(applause)

John Curran: Okay. ARIN 33, there’s an app for that. We’re working with new technology. If you want to track the meeting on your phone, including the agenda and materials, you actually can get an app. Everyone who is registered should have gotten a link. If you haven’t, you can drop a note to info@arin.net and we’ll send you a link for the app. And it actually will not only help you keep track of this meeting, but it will help you with the registration for future meetings.

Tonight we have a social, major social taking place at The Field Museum. We’re going to have The Field Museum, the famous Chicago museum of natural history. We’re going to have buses depart at 6:30, 6:45, and 7:00. And then we’ll have buses returning from 8:00 PM on. Bring your badge so you can get into the exhibit.

Today’s agenda. We have a pretty full day today. We have the AC On-docket Proposals Report, which will be given by John Sweeting. We have the Regional PDP Report, which Einar Bohlin will give, talking about developments on the policy. We have a Policy Implementation and Experience Report, which Leslie Nobile will give. That’s where we provide feedback on how implementation of policy is going at ARIN. We have Cathy Aronson will be giving the IPv6 IAB/IETF Activities Report. And we’ll have an update on API software development toolkit.

Later on in the day, we’ll handle quite a few policies, but later on in the day we’ll handle the results of our first customer satisfaction survey. We’ll have the ARIN Consultation and Suggestion Process Report and an update on our software development efforts.

A lot of activity. In terms of policies, well, even more. Today’s agenda, policy discussions. We have six policies on the docket today. So we’re going to have a very busy day. And that includes the Policy Cleanup; includes 2014-4, the Remove Web Hosting Policy; includes 2014-10, Removing Sections 4.6 and 4.7 from NRPM; 2013-8 for Subsequent Allocations; the Maintaining IN-ADDR Policy; and the Lame Delegation Policy. Quite a bit.

So when we have the discussion, the Chair or Vice Chair will be moderating the discussions. Please speak clearly so that everyone can hear you. Please state your name and your affiliation each time you’re recognized at the mic. Please comply with the courtesies that are in the Discussion Guide.

Okay. At the head table, we have Scott Leibrand, John Springer, Dan, John Sweeting, myself, Vint Cerf, Paul Andersen, and Rob Seastrom. First one I’ve ever made it through. Thank you.

I’d like to start right in. The first presentation will be the On-docket Proposals Report, and it will be given by John Sweeting.

AC On-Docket Proposals Report

John Sweeting: Good morning, everyone. I’ll try to get through this real quick, if I can get, all right. So this is just a quick picture. You can find this on the Web page. This is the AC. If you want to flag anybody down during this meeting, if you want to go to the ARIN.net web page and pick somebody out that you want to identify and run down, that’s how you can do it.

Mainly what we do is we’re engaged in the ARIN Policy Development Process and we are charged as the primary facilitators for the Policy Development Process.

Current Draft Policies and proposals that we have on the docket. We have four recommended Draft Policies. These policies are ones that we’ve already recommended as fair, sound, and good policy. And what we’re trying to determine over the next few days is if the community agrees with that, and we have consensus and we then forward them off to last call.

There’s ten Draft Policies that we have not moved to a recommended status, because we’re still looking for input and we’re still developing those policies to perform as the community would like to see them.

So we’re looking for input on should we continue to work on them, should we change them, edit them, what do we need to do to these to get them either to recommended status or maybe possibly you want us just to abandon them and stop working on them.

And we have zero policy proposals at this time, which doesn’t present any kind of challenge, Einar.

So there’s also, for this meeting there’s going to be a breakout room, and it’s the Astor Room. It’s a breakout room for the policy discussion. Anyone can make use of it. If you want an AC member to be part of your discussion, see me and/or use the signup sheet at the registration desk and we’ll try to get somebody there for you depending on who is presenting. If you want a specific AC member, then make sure they’re not presenting during that time that you would want to have your discussion.

We’re going to continue with the lunch table topics, as we’ve done in the past. There’s going to be five tables with two Draft Policies per table. The tables will have signs. And there will be an AC member at each one of those tables to lead the discussion, take notes and bring that input back to the AC after that.

I do want to make one, point out one thing. If everybody, if you’re not familiar with the rules of discussion here since we have so many policies to get through, I really ask that you read the rules of discussion on page four of the handout that you received when you registered and please try to adhere to that, and especially the time limits and how many times they get up, and continue to give everybody a chance to have their say is what I’m asking.

Thank you. Any questions? Thank you.

(applause)

John Curran: I’ll help John. Under the rules of discussion, we ask the people not speak a second time on the same topic if anyone else who has not spoken is in line. And that’s just a polite courtesy, because we have so many policy proposals. We want to make sure we get to hear everyone’s input.

Some people have a high level of enthusiasm for discussion, and so there’s nothing wrong with coming back again and again, but defer to the people who haven’t spoken yet if you have a chance to do so.

Okay. So I’d like to move right ahead. Next item on the agenda is the regional Policy Development Process Report with Einar Bohlin, our Policy Analyst.

Regional PDP Report

Einar Bohlin: Thank you, John. Here’s a graph I show at every ARIN meeting. I go to all of the RIR’s websites and I look at their proposal tracking pages, and I take everything that’s under discussion or has been recently implemented or abandoned, I throw them all in Excel, and I categorize them by what topic the proposals were on and try to get a sense at a very high level of what’s being discussed around the world.

And as you can see, today, or at this time, in the second quarter of 2014, there are, among the five RIRs, 32 proposals that are in some stage of recent discussion. And the bulk of them are still on the topic of IPv4. And those range from last minute changes to changes to transfers, policy proposals about what to do with our last pieces, all sorts of things.

A couple of proposals on v6 are being discussed. One on directory services. And then a catch all at the end, the other category, which has decreased. And those other proposals are pretty much the topics of reverse DNS and Autonomous System Numbers.

So here’s some highlights. I can’t do all 32. So things that might interest you that are happening at the other RIRs include on the topic of IPv4 proposals. There are still proposals about inter-RIR transfers at LACNIC and RIPE. As you know, ARIN and APNIC have reciprocal, needs-based inter-RIR transfer policies. The way things look now, LACNIC could join ARIN and APNIC, but it’s unclear that RIPE could do that with their current policy set.

The RIPE region is discussing a proposal to do away utterly and completely with the minimum allocation size. They recognize that this could have something to do with routing, but they’re deciding that that’s not the RIR’s, the discussion says that’s not the RIR’s decision and perhaps shouldn’t be in policy.

And in the LACNIC region, they have two reserve pools for the very end of v4, one for new customers and one for existing customers. And before they run out of space, they’re trying to double the size of those pools, from 12s, from two 12s to two 11s, and they’re doing it with the PDP they have which allows them to switch last call and presentation. So they can go discussion on the list, last call, could actually implement and then present after implementation to make sure that all the community has a chance to discuss it. But it’s an expedited PDP they’re making use of.

In the APNIC region, there’s a v6 proposal that would pretty much automatically increase any organization’s 32, in IPv6, size to a 29. That’s if they have one 32 or multiple 32s, they could say please increase my allocations.

Interesting proposal from AfriNIC. This one concerns reassignment information. ISPs are supposed to create customer network records. You’re supposed to, when you’re giving a network to a customer, you’re supposed to create a record in WHOIS that shows what the network is and who it’s assigned to. And this AfriNIC policy, which is actually ratified and going to be implemented, says if an ISP doesn’t submit and keep its reassignment information up to date, then they’ll jeopardize and possibly lose their reverse DNS services. So that’s the stick to get them to keep doing assignment information.

So if you want to get more information about these proposals and all the other things that the RIRs are discussing, then go to these URLs and you will find everything that’s under discussion and been recently adopted or recently abandoned.

And then finally I’d like to mention the NRO, the policy comparison overview. The five RIRs once a quarter update this document, and it gives you an abridged version of all five RIRs’ policy sets.

If you want to compare any of the RIRs’ v4 policy on transfers, for example, you can go to this document and get an abridged, high level look at whether they have it and is it similar or different, that kind of thing.

That’s it. Thank you.

(applause)

John Curran: Any questions for Einar? Thank you.

Next up we’ll have the Policy Implementation and Experience Report by Leslie Nobile, head of Registration Services.

Policy Implementation And Experience Report

Leslie Nobile: Good morning, everyone. So this time it’s actually just the Policy Experience Report. We haven’t implemented any policies that have anything operational, so there’s nothing really to report on since the last meeting.

We’re just going to jump into Policy Experience Report. As John said, this is the staff’s opportunity to let you know, the community know, how well the policy set is working, whether there are issues, problems, gaps, ambiguous text, inconsistencies, all kinds of things like that.

This is our chance to give you feedback on how we see it working and what we’re hearing from you all as we interact with you. So we typically will identify areas where new or modified policy might be needed, and, as I said, we base that on our experience from dealing with our community and our customers.

And we use customer feedback, and then we put this into this report and we’ll provide the feedback to the community and we make recommendations when appropriate.

So this time there’s one big issue that we’ve cited, and the basic question is: Will new or first time ISP requesters be able to qualify for IPv4 space under existing ARIN policies after free pool depletion.?

We started thinking about this, and we thought that there may be some potential issues for new ISPs who need to qualify for space in this post depletion world.

So what we’re seeing right now is a lot of first time requesters coming to us and they’re getting space directly from ARIN. And this is, this is kind of new. I mean, we’ve always had first timers, obviously, but we’re now starting to hear that upstream providers are directing their customers to come to ARIN directly for their own space and to return the space that they have to the upstream.

We looked at our numbers, and about 25 to 30 percent of our current requesters are first timers to ARIN, and that is end users and ISPs.

And the thing that we note is ARIN is the only RIR without a general austerity policy in this last /8 world. So looking at other RIRs’ last /8 or austerity policies, or just austerity policies, APNIC and RIPE NCC have a similar policy, and it says that all new LIRs, new and existing, sorry, LIRs can get a single /22 one time, and they have to qualify under an existing policy. And this is when they reach their last /8. Both of them have reached their last /8, so this is actually the current policy in effect. There’s also a /16 that they’ve reserved in both regions for future unidentified use. Not quite sure what that is.

LACNIC and AfriNIC also have austerity policies. And this is going towards depletion. They’re a little different than the other two. I think Einar just mentioned this. LACNIC has a policy where they’ve set aside two /12s. One is reserved for their new members, and they can receive one /22 to /24, and they do have to qualify under existing policy. And this is a one time thing. And then they’ve got a 12 reserved for their existing members, and they can receive the same /22 to /24 to 22 every six months and, by qualifying under existing policy.

AfriNIC has a slightly different policy. When they reach their last /8, they’re not very close at this point, but their maximum allocation size changes to a /13; when they reach their last /11, their maximum allocation and assignment size moves down to a /22. And with the stipulation that they can come back for more space as needed and they do have to qualify under existing policy.

So some of the potential pitfalls that we thought about for new ISPs coming to ARIN. We don’t have any address space reserved for new organizations. 8.3 and 8.4 transfers require qualification under existing policy. We’re assuming in this post depletion world that that’s the policies that they’re going to use, the 8.3 and 8.4, if they still need to v4. In the ARIN region right now all the IPv4 ISP policies require you to have space to get space, so, with the exception of immediate need.

That doesn’t apply to end users, and that’s why we’re only talking about ISPs here. The end users policy is very different. You don’t have to have space to get space; you just have to show that you’re going to use 25 percent of what you’re asking for immediately and 50 percent within a year.

So we think that it’s possible that first time ISP requesters might get caught in this situation, where they won’t have space from an upstream and can’t get space from an upstream and may not be able to qualify for IPv4 address space from ARIN, whether it be via transfer policies or through some waiting list through the IPv4 policies.

So I just took a quick look at some of the policies we’re talking about, 8.3 and 8.4, where it specifically calls out that you have to qualify under a current ARIN policy. That is highlighted in red. So under ARIN current policies for 8.3 between specified recipients, that’s the condition on the recipient of the transfer. And an inter RIR transfer is 8.4, same thing, condition on the recipient will be subject to current ARIN policies.

When you look at the current ARIN policy set in IPv4, these are them. 4.2.2.11 says you have to be using a 20 in order to get a 20. Highlighted in red. The same thing in the multi-homed policy. You have to be using some amount of space to get some amount of space.

So we looked at what the options might be right now for these new first time ISPs, what could they do using the existing policy set, are there some policies they might be able to qualify under.? We came up with two. And these are ISP requesters with no upstream space, mind you. We looked at immediate need. That’s a possibility. That’s offered to anyone. Not used very often, but it’s available.

There’s that last /10 to facilitate IPv6 deployment policy, but that’s a very specific policy. You can get a /24 to a /28. And it’s for a very specific reason, and at this point it doesn’t look like that would be an ideal option.

So we thought ,are there existing policies we could modify, could something be modified to accommodate these first time ISPs? 8.3 and 8.4 we thought maybe a clause could be added to allow first time ISPs to get a small initial allocation without already having provider assigned space. I don’t know.

We looked at the /10 for v6 transition policy and thought, well, maybe its purpose could be expanded and it could include small allocations for first time requesters. That’s an option.

Then we looked at a third option, which is to create a new policy. Does this merit a new policy? So the thought is create our own austerity policy in the ARIN region, set aside a specified prefix size, maybe a /13 or /14 for first time ISP requesters who have no space themselves, no provider assigned space.

So the thing about that is we have a very long policy development cycle, and that could be really problematic. We could be out of space before this policy would ever go into effect. And the thought is would this need to be an emergency policy enacted by the Board. I was just throwing that out there.

So that’s all I have. Any questions?

John Curran: Microphones are open for questions on the Policy Experience Report. No questions about that report. Reactions? Thoughts? Comments? Okay. We probably need to check this morning’s coffee to make sure it was all decaf, black water that serves no purpose. But that’s okay. We will move ahead. Thank you, Leslie.

(applause)

John Curran: Let me get us going. Cathy Aronson is next up with the IPv6 IAB/IETF Activities Report.

IPv6 IAB/IETF Activities Report

Cathy Aronson: Just because I can, this is by my house and I took it. Is there a thing? And a woman asked me, When does that happen? And I said, Pretty much every night you look outside when it’s dark and look up. Lifetime resident of the valley didn’t know the Milky Way was there. Awesome.

Anyway, where are we? This is my little disclaimer thingy I show every time. I could probably skip it.

So since we last had this presentation, there have been two IETFs. And thanks to Vint I did a little bit of blogging. London I was really jetlagged, so you’ll notice there were no blog entries from there. But I have plenty to talk about.

And since we had 500 inches of snow, I did a lot of snowboarding. Okay.

So some highlights, because I’m going to have to breeze through this pretty fast. This Why 64 thing. So there’s a lot of, in the beginning of IPv6, there were a lot of auto-configuration mechanisms and a few things that required you to have a 64-bit host identifier, so therefore a 64-bit network length, and some of that’s hardcoded and some of that’s written specifically in specification.

So there’s a document that was written assessing, not really making any recommendations or requesting any changes, but assessing where that existed and what it affected. And for anybody in the room who runs a network, this is something you might want to pay attention to, because, boy, if you got something on your network that doesn’t let you have a prefix that’s longer than a 64-bit prefix in v6, that might be a problem. It might be a problem for your customers like in their homes or whatever. So it’s a pretty interesting read. It’s sort of like going back to before we had CIDR. I don’t know.

Anyway, another thing I blogged about was this geo-networking BoF, which is interesting. They’re starting to look at the applications where maybe you have an electric car and you’re driving down the road and it tells you there’s a place to charge it with an open bay, two exits up on the right. And I thought at first they were talking about geographic addressing to do this, which would be insane.

And I’m still not entirely sure. So I’m sort of following it to see if it affects address space at all. But it could just be this humongous database of people and geo coordinates. I don’t know how they’re going to make it happen. Anyway, those are my little…Let’s see. Oh. This is my little rant about what happens on the attendee list. And we’ve discovered that there really isn’t good coffee there. Just in case you’re wondering. It’s pretty universally bad coffee.

So the IEPG meeting. The Internet Engineering Planning Group is a group of network operators that meet at the IETF since I don’t even know when. A long time.

Some of the things they talked about. They did a whole RPKI implementation with almost all of Ecuador. So there’s one ISP, and they’re 97 percent of the traffic. So they did a really cool, pretty much deployed RPKI in all of Ecuador.

There’s a paper that Roque wrote about, if you’re interested. He said they have the chicken and egg situation, which is a little bit different than how we say it, but people don’t want to do it because they don’t have experience with it. They don’t have experience with it so they don’t want to do it. Anyway.

Then Geoff Huston did a great talk about measuring Google’s DNS 8.8.8.8 and with respect to DNSSEC. So there’s a lot of really interesting information in his paper that he wrote.

Let’s see. Where are we at? Some other things we talked about. IPv6 fragments are still an issue. And then this making special better. So the special assignments and prefixes and protocol numbers in the IANA, they’re starting to do, I’m sure Leo can talk about this better than I can, but they’re starting to document that in a way that it’s easier to automate filters. So it’d be good to take a look at that if you need that sort of information. But they’re putting together, it’s easier to automate to. I don’t know if Leo wants to say anything about that at the end.

And then there’s a - Paul Vixie has a really interesting paper out about problems with the DNS and security things that the IETF should be working on, which is linked there. I tried to put all the papers in here because I don’t have a lot of time to talk about any of them in detail. 15 minutes and two IETFs is a lot.

Let’s see. Measuring IPv6 deployment. There’s a lot of work being done on that right now. IPv6Matrix.org, if you’re interested in that.

Geoff’s been looking at the BGP and how it hasn’t changed in the last how many years. The same amount of address space is represented and the same amount of ASs are added every day and it hasn’t really exponentially exploded, so that’s pretty interesting.

I don’t know why these are animated. Sorry. Let’s see. Oh. This is really interesting. So the BGP tables may not be exploding, but the size of the configs required to filter appropriately has grown exponentially. And the amount of time it takes to commit a config has gone up a lot. And 96 percent of those configs that are 16 megs, I guess, is filtering, basically filtering prefixes and things like blocks that you shouldn’t be routing, like Net10 and all that kind of stuff.

Then there was some work done on people using Autonomous System Numbers that aren’t assigned and that there are 900 bogus Autonomous System Numbers. What’s really bad is when you have a bogus Autonomous System number announcing a bogus prefix. Apparently there are some of those out there too.

So the IPv6 Maintenance Group is a group that looks at going forward, things that have to happen to v6 to make it compatible, work in a v4-v6 Internet and to keep it going forward, as opposed to Operations, which is a different group.

Let’s see. They’re getting rid of the EUI based prefixes, and there’s a lot of Neighbor Discovery work going on. So you figure out who your router is and who your neighbors are and how you do that; there’s a lot of work being done on which mechanisms to be used.

Let’s see. I talked about Brian’s paper about Why 64.

And then node discovery is a really chatty process, and there’s more and more over time nodes that are sleepy. Like maybe they don’t, like if your cell phone is constantly discovering the network, then your battery life is like almost non-existent.

So there’s a lot of work being done as nodes become what they call sleepy or sleepier. So there’s node discovery work being done so it’s not as chatty so your battery won’t die as fast. Those are just some examples. There are examples that aren’t always, initially the network was set up, you know, we didn’t care, so we were like, yeah, I’m always going to check every certain amount of time and see if the network’s up or whatever. Now there’s a lot more things that you don’t want to be that chatty.

So we had a technical plenary in London. There were a lot of complaints about it because it, one of the talks was, a lot of marketing. But I found a couple of things really interesting from this talk. One of them was just the dynamics of paying in other countries, which I never thought about before.

Like in certain countries people will sit there, they’ll have an app where they can just split the bill up amongst their friends and everybody, everybody gets their part of the bill and stuff. And I thought that was really cool.

There’s also a whole mechanism where you pay, you go into a convenience store and you pay and you get a little sheet, and then you go and then you get your item. Because a lot of the world doesn’t have a bank account.

So some of the stuff is, I thought that part of it was really interesting. The marketing guy, not so much. But this part of it was pretty interesting. I never really thought about the cultural differences in how we pay. I don’t know, I never thought about that.

There’s a new video out: Ten Things to Know Before You Go to an IETF. Which is, if you haven’t listened to it, it’s pretty hilarious because some of those geeks aren’t very nice. And you might need to learn to interact with them (chuckling). It’s pretty cool, actually. If you’re going to go to an IETF, watch the video. If you’re not, it’s still pretty funny.

And that reminds me. They made a video. This hotel in London was insane. It was like you needed some sort of, I don’t know, major map to find your way around. And they had these, like a centaur and a, I don’t know, some things like if you got really lost and you found one and you took a selfie with it, then you won a prize. It was hilarious.

There was a whole video on finding your way around the hotel because it was just like nothing you’ve ever seen before. There were downs and ups and different towers and nothing connected together and there were arrows on the floor.

There was a lot of talk about hardening the Internet and with the stuff with Snowden and the NSA. People are really trying to, starting to look at how do we make the Internet secure like we should have in the beginning.

And I like this “Security is like a birthday cake” quote. I collect those things.

Homenet. This is the quote of the IETF: “Multiple routing protocols in the home…are you on crack?” Homenet is still insane. It’s still arbitrarily complex. But they do have a more simplified way of discovering your network now. And they’re talking about maybe you buy something at the computer store and you come home and you have a little app on your phone that you can tell your homenet, oh, this really is mine and I want you to connect it to my network.

So some of that work might actually make it easier for regular people to have a homenet. But we’ll see, because anybody who thinks you’re going to have two routing protocols in a home, I don’t know. Maybe people in this room, but not somebody’s mom. I don’t know. Anyway, there are moms in the room, so I guess, or dad. Like an ordinary, I guess that was a bad example.

But some of my neighbors, they’re so not going to have two routing protocols in their home. They’re just not.

And I don’t know. Yeah, sorry. And then the Internet Society has their briefing panel every IETF, and the one last fall was about what does success look like in IPv6. And these are some of the things that some of the panelists suggested might be good to have when IPv6 is successful, v4 is trending downward, you could actually VPN with IPv6, v6-only devices, which right now probably wouldn’t be a good idea. I don’t know. Anyway, these are some of the ideas.

This is some information, this is from last fall, though. This is some information about one of the speakers from Comcast and what their network looked like. And they’re supposed to have v6 on their whole network by this year, which is pretty awesome.

Let’s see. And this is some things, some things that matter when you’re rolling out v6. And one of the things I thought was interesting is maybe you can get to the website with v6 but not update the software on your iPhone. Or the software or, and things like Skype don’t support v6 yet, so even though you might be able to get to the website, you probably can’t download it with v6 or use it with v6. And, yeah, the divergence of the Internet is something we should all start thinking about.

Then there was another talk that wasn’t about v6; about end-to-end, if you’re interested. All of that is up online. So v6 Operations is another v6 working group. Looks like they’re going to turn off Teredo this year for real, which is a transition mechanism.
(applause)

Cathy Aronson: Except they’re going to start, they’re going to keep it in some parts of the Xbox at Microsoft, but I think that’s more of a localized application than something you would access to do a transition.

Some work on NAT64s being done. There’s a paper about that.

This I thought was really interesting. As the network becomes more and more of a hybrid, v4 and v6, when you start roaming, there could be a lot of problems where maybe your device is only v6 and you roam into a v4 network or maybe there’s speed problems because of the gateway that’s translating between one of the other, I mean, I don’t know if we’re really seeing that a lot right now, but I think long term we might start seeing that.

And then there’s the debate about which auto configuration mechanism, DHCPv6 or, yeah, there are different auto configuration mechanisms, neighbor discovery, which one to use, what happens if you’re using both, what happens if you get two addresses. So there’s some of that work happening.

Let’s see. They’re defining blocks of addresses to use in documentation so that they’re just put away for the documentation and you can just use them like, well, whatever we use now.

Let’s see. Dropping fragments. If I’m going to intentionally drop fragments, I’m going to do it deliberately. Awesome. Some of this stuff is really esoteric. I don’t know how many minutes I have left.

John Curran: Take your time.

Cathy Aronson: You say that now, but when we’re behind schedule, you’ll wish you hadn’t.

John Curran: Then we’ll know who to blame.

Cathy Aronson: Let’s see. This is if you use both auto-configuration mechanisms you can have interaction problems. There’s a bunch of work defining how to use ULAs which are using unique local addresses. And there’s a big debate about whether your network’s isolated or not, because eventually we learned with RFC 1918 space like you might be using Net 10 and they’re using Net 10 and then maybe your company buys their company and all of a sudden you have the same address space so even though you’re not connected to the Internet you have a conflict. There’s a bunch of work being done there.

So IGOV update. I’m sure we’ll be talking about Internet governance here, but I go to this from the IETF perspective because I find it to be really interesting, and as always, I believe it’s the same person who I don’t know who stood up and said: Well, we should just give all these countries big blocks of address space and that will make them happy.

And I guess what I’d like to say to everyone here is that if you’re out and about and somebody stands up and says, “We’ll just give them big blocks of address space,” especially somebody as an Internet standards body, stand up and say something. Because this community exists. We’re like “Horton Hears a Who!” We exist. I stood up and I explained that. And they should all know that. But apparently they don’t.

So let’s see. Then there’s some other work on the coalition. You can click on the link and read about it.

Let’s see. And they’re looking at the relationship with the IETF and the IANA, and they’re trying to codify that some more and document it. Because, you know, the IETF uses the IANA for like protocol numbers and different, a very specific function that our community doesn’t really have a part in.

So there was some concern, if the contract changed, would the IETF own the content of the database. And Steve Crocker says that the IETF owns the content of the database.

Homenet. Why do I have two homenet slides. Sorry about that. LISP doesn’t have much to do with IPv6 except they’re doing this EID block thing. Looks like they’ve determined it won’t be globally routed. So it doesn’t really affect us. They’ll go to the IANA and they’ll probably get a block, if they haven’t already, and they’ll do their LISP thing.

WEIRDS. So they’re talking about, Mark and those guys here, they do a lot more of this than I do, but how to get the database so you know which RIR has the information you want. There was some talk about that. I think that was last fall, though. I don’t think I went to the one in London.

This is really interesting. The benchmarking folks, they do like testing protocols for evaluating like equipment, like you can go and you can get the information about if you’re going to buy, you’re choosing among different routers, you can look at the benchmarking testing. And they write these specs for how to tell whether your router can really handle 100,000 routes or whatever.

So they’re looking at different pathologies in v6 and how to test to see how the device would handle that, like chaining the stuff together. Or like Igor’s paper where people report scanning massive numbers of addresses, how do these devices handle that, if somebody attacks in the scanning two to the 64th addresses. So that’s some pretty interesting work going on there.

Dynamic host configuration is all about how to get your address. And there’s some architecture things going on there. Naming for homenet. Hopefully it will be simple and people, ordinary people, can do it.

Geo Privacy is another group that I went to. There’s some drafts going on there about privacy concerns. This one, I’m not so sure about this, but the IRTF is talking about autonomic networks where your device comes up and figures it all out by itself. I’m not sure I want my routers figuring it out all by themselves. It’s a little terrifying. Not sure it’s practical. Or they discover the network management system by themselves. I don’t know. But they’re working on that.

Yes, self-managing, self-configuring, self-protecting, self-healing. It will be a miracle. So excited.

John Curran: You left off self-failing.

Cathy Aronson: Did it say that? That should have been my little clippy Cathyism, huh? I don’t know. But it’s good to follow these things because you can see what people are thinking about might be the, maybe this will do away with everyone’s job. It could happen. It’s a little terrifying.

Pervasive monitoring BoF. There’s some good quotes from that. So if you’re interested in pervasive monitoring. I love that sticker. I’m going to have to get one of those.

DNS Operations. There’s some work being done again with the AS 112 project. So like what do you do with the queries that don’t go anywhere and they just happen over and over again. It’s a way of sucking them in so they don’t take over.

“Technically correct, possibly pointless” was the discussion at one of the drafts, was the quote about it.

And then there’s this Special Use Domain Name Registry. I think maybe I have another slide about it. Maybe I don’t. But they’re looking at how you tell the difference between domain query and search. And maybe internally you want to have, you want to have an internal DNS, I don’t even know how to explain it, like so that it doesn’t go out to the global Internet if you type a certain string, then it searches internally, and so then they’re looking at the differences.

Vint Cerf: I think this may have to do with the domain collision problem and you’re using DNS people typing in a prefix, not a fully qualified domain name, for an internal system and it sneaks out and tries to find out in the open net, and then you get a collision.

Cathy Aronson: Yes. So they’re trying to come up with standard ways of dealing with that so that there’s not so much garbage going out on the Internet that doesn’t need to be.

Vint Cerf: I’m sorry, it’s more than just a question of garbage going out; it’s a problem of resolving to the wrong place. When you intend to resolve to something internal but because it’s registered in the public domain name system, it actually resolves to something outside. So now you’re trying to send something internally, but it ends up on an outside target. That’s what the concern is. And they’re trying to find an alternative to simply preventing people from using certain prefixes in domain name structure.

Cathy Aronson: Right. What he said. So the 6LO group again deals with all kinds of different low power, low, sleepy nodes. And there’s some work being done. And this draft, I don’t know, IPv6 addresses for things that don’t do IPv6. I’m still trying to get my head around that.

You have some really dumb device that’s in a machine shop and it doesn’t do IPv6 but you’re going to give it an address. I still don’t understand why, I don’t know. Because it could, some of them can’t ever do v6. But there’s a draft for that. And it’s IPv6. So I put it in here.

Let’s see. Gotta be getting close to the, and then there’s more work being done with the data defined networking. I talked about that last time where Lixia Zhang and her group are doing some, and now there’s an IRTF group that’s starting to look at that. And I put a little thing about what it is, if you’re interested. It could be the new phase of the Internet, data defined.

I went to this SPRING group because there wasn’t a v6 thing really going on then. But basically, well, it has to do with v6, but using v6 and MPLS to do source routing, which destination based routing has its problems and people have been trying to solve it for a while, and this is another mechanism.

This is a list of drafts. I can’t really talk about all of them. But I thought of the ones I saw they would be the ones that would be interested in checking out.

Did Vint have something to say? He’s got his hand on the button.

These are the way to find most of the drafts.

John Curran: Microphones are open for questions.

Vint Cerf: Since nobody jumped up. I want to say, first of all, thank you. This is the most amazing summary I’ve ever seen, you must have gone to every damn session. Have you cloned yourself or something?

Cathy Aronson: Have I what?

Vint Cerf: Cloned yourself. That’s a remarkable summary of an awful lot of material. Thank you for that.

Cathy Aronson: I get sent there, so I go to everything I can go to. Thanks.
(applause)

John Curran: As someone who often goes to IETF meetings but doesn’t make them all, I will confess an addiction to Cathy’s updates at these meetings. They are truly wonderful documents, and I think we’re all blessed by getting to see them.

If you have the chance to go to an IETF, it is just as adventurous as she depicts it. If you can only get the IETF in 20 minutes, those are the 20 minutes to get.

ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

John Curran: Okay. We’re now going to jump into our policy block. This morning we have two policies before our break. The first one is Recommended Draft Policy ARIN 2013-7: NRPM IPv4 Policy Cleanup. I’m going to do the introduction and then turn it over to Scott Leibrand who will do the AC presentation.

So 2013-7 originated as ARIN Proposal 190 in July 2013. The shepherds are Scott Leibrand, Kevin Blumberg, and John Springer. They accepted it as the Draft Policy in August 2013. It was presented at NANOG 59, ARIN 32, and NANOG 60. It’s been updated. The AC recommended adoption of it in March 2014. The Draft Policy text is online and in your guide.

The intent of the proposal is to modify several existing sections as the author believes that they’re becoming increasingly irrelevant as we move closer to runout. The sections modified are 4.1.1, 4.1.5, 4.1.7, 4.1.9, 4.2.4.3 and 4.2.4.4.

The changes do not appear to alter the staff’s ability to obtain appropriate justification for resource requests nor create any potential operational impact. It’s predominantly a clarity and clarification update.

So no legal concerns were noted in the staff review.

And I’ll turn it over to Scott now. Scott.

Scott Leibrand: Good morning. So as mentioned, this, we’ll wait for my presentation. There we go. This is cleanup. The idea behind this proposal is that there are certain parts of the NRPM that aren’t needed anymore and those ones that are uncontroversial, not needed, should be removed. That’s for clarification, for getting rid of stuff that is no longer being done. Just basically cleanup.

So as John mentioned, there are several updates in here. I’ll go through the details of those in a moment. But you can just glance over them, get an idea of the thing we’re talking about.

So the first thing suggested is that we remove the 4.1.1 section on routability. This is the part of the NRPM that tells people that they should be going to ARIN if they have a big enough request and otherwise they should be going to their upstream, and is rather prescriptive in how that should be done.

The author felt and we agreed that that is a little bit dated in terms of the actual nature of the advice and, in any event, is not necessary because organizations can figure out for themselves where they can get addresses, where they’re available, what’s going to be most appropriate, whether they qualify, et cetera.

So that’s proposed to be removed.

The next thing that’s proposed to be changed in this case is relaxing the language around ARIN determining the IP address allocation size, because what really happens and what really should happen is that ARIN validates that the request is appropriate.

So, strictly speaking, that original language would have ARIN saying no, no, no, you don’t need a /24; you need a /22. Here, have a bigger block. That doesn’t happen, shouldn’t happen, and in a world of transfers is a really bad idea.

So this proposed just cleaning up that language and clarifying that what ARIN is really doing is determining the validity of the requested size.

There is a section of 4.1.7 that references 2050. RFC 2050 was a document that detailed how the RIR system works. It is very dated and has recently been superseded by RFC 7020, given that there’s no longer a need for a reference to 2050 in the NRPM, so that’s to be removed.

There’s a section that speaks about how members who have been around less than a year should get a certain amount of requestable space and once they’ve been around for more than a year, they should get more. However, that has been superseded by Section 10.4.2.2, which says once ARIN has received its last /8 from IANA, or once IANA executes the last /8, anyway, once that has all happened, which happened in the past, that this would no longer apply; that everyone qualifies for 24 months. So this is a portion of the NRPM that’s now orphaned and no longer relevant and should be removed.

So the question for the community is: Are we doing anything controversial? Is there anything in here that you don’t think is minor cleanup, that you think needs improvement or more discussion or whatever.

The idea here is that this is all minor cleanup and stuff that should be done. And we’ve removed everything that was even the slightest bit controversial from this policy, so what’s left is cleanup.

If you agree with that, then say so and we’ll move on; if you think that there’s anything that’s not a complete open and shut case that should be discussed, let’s discuss it. If we need to remove anything from this policy to move it forward, we can break things out into separate proposals or do whatever else is appropriate.

So questions, comments?

Discussion

John Curran: Microphones are open. Vint, if you want to,

Vint Cerf: I’ll be happy to moderate this part of our discussion. Is there anyone who wants to raise any issues with the proposal as it currently stands?

John Curran: Microphones are open.

Vint Cerf: I have a feeling people are eager for coffee. Is the coffee better here than it is in the U.K.

John Curran: I’m presuming.

Vint Cerf: That’s an unusual comment, because Europe usually prides itself on its quality of coffee.

Microphones are going, going. I see Jason leaping to a microphone. Yes. Thank you for announcing who you are.

Jason Schiller: Jason Schiller, Google and the NRO NC. Could you go back to your slide about 4.2.4.3? Yes. My concern here is that this is not just a no-op, and if we remove Section 4.2.4.3 that we completely remove slow start and remove this need to provide a three-month projection.

My question is: What text would remain to suggest what somebody would qualify for if this portion of the text is removed.

Scott Leibrand: I can always count on you to bring up something I haven’t thought of, so give me a second to look over that. If anyone else has any comments or answers to that question, speak up. Otherwise, I might have an idea here in a minute.

Let me summarize the question, see if I understood it. If not, you can repeat it. So your concern is that by removing 4.2.4.4, it appears, or removing both of them, that the current, the past policy of getting a small block, verifying that you used it before you get a bigger one, which we colloquially refer to as slow start, would be impeded.

Having just opened my Discussion Guide and looked at 4.2.4.3 and 4.2.4.4, I see that the last paragraph seems to be the operative one here, which is when ARIN receives its last /8 by IANA implementing Section 10.4.2.2, the lengths of supply that an organization may request will be reduced, an organization may choose to request up to a three month supply of addresses.

So the requests from ARIN’s free pool are limited to three months regardless of whether you’ve been around for less than a year or more than a year.

Separately, 8.3 and 8.4 have a 24-month timeframe.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. That paragraph that you’re counting on is part of 4.2.4.4, which you’re removing.

Scott Leibrand: My point is that the 4.2.4.4 says after last /8 everybody’s down to three months. So now that we are after last /8, everyone is three months and there’s no need for the distinction between less than a year and more than a year. That’s the change that’s attempting to be made here.

Vint Cerf: John.

John Curran: I believe, Owen, the sentence he’s talking about, you’re right, is one that would be removed if you remove this. But it’s being replaced with a single sentence, which covers it: ISPs may request up to a three-month supply.

Scott Leibrand: That last red line there.

John Curran: Got it?

Vint Cerf: This is Vint. I think that the three-month supply introduces slow start for everybody in this new state. Is that not correct.

Scott Leibrand: So maybe what I didn’t mention earlier is that this last line in the diff here is basically saying ISP, well, it says: ISPs may request up to a three-month supply of IPv4 addresses from ARIN or a 24 month supply via 8.3 or 8.4 transfer.

That is replacing all of the previous text differentiating less than one year and more than one year.

You seem to have a concern about that.

Jason Schiller: Yes, I still have a concern. And I believe staff shares my concern. Let me try to restate this.

The policy as written, before any of these changes, suggests that if I’m a known ISP with more than a year’s history, based on my previous year, I could previously get a 12-month supply, but now that we’re in the last /8, I can get a three-month supply.

So I go to ARIN and I say: Last year I used a /10; can I please have a /12? Based on my 24-month utilization last year, based on what that, a quarter of that should be what I’m allowed to get.

As a new ISP, today, I come in and say: I am slow started. I get a small block. I use it. If I use it in less than a month and a half, I come back and I get the next biggest block.

The way it reads now, the text that you’re proposing, I believe, if I am a new ISP, I can come in and say: In the next three months I intend to use a /8. Here is my business case for that. I am buying this many devices; I am buying this many computers. I have a really good justification for why I need a /8 in the next three months. Please give it to me.

I believe the text as proposed allows a new ISP to simply present what their anticipated use is over the next three months and get that amount of address space.

And I’m not sure that’s what you intended to do, because it sounds like what you’re intending to do is a no op to simply line up known ISPs with a year history and new ISPs on the three-month window. I don’t oppose that. What I oppose is someone being able to come in and say: My anticipated usage for the next three months is X. Give me the block; I qualify for it.

John Curran: If I can respond.

Vint Cerf: Go ahead, John.

John Curran: What Jason identified is a valid concern with the text. It wouldn’t occur in the implementation because a new ISP coming in, we would, we’re still in the circumstance where we would ask them under present policy what their utilization of an allocated block from their existing transit provider was.

Remember, under current policy, when you’re coming to us as an ISP, you already are, you’re already being served by someone else.

So we would ask for your past utilization of your upstream assigned block. Even if this was changed, we’d ask for it. The difference is it’s no longer as clear why we would be asking for it under the revised text.

Jason Schiller: My read of the revised text: ISPs may request up to a three-month supply of IPv4 addresses from ARIN post op.

John Curran: Right. And so what’s missing from here is the carry over of the thought based on the previous utilization of previously assigned blocks.

Jason Schiller: Yes.

John Curran: That’s a worthwhile addition since we would be seeking that from all ISPs, new and existing, but particularly from new ISPs coming from us. So I think that that’s probably a worthwhile addition to say based on previous, utilization of previously assigned blocks.

Scott Leibrand: We have two remote participants on both sides of me, but I want to point out one more thing, which is if you turn your Discussion Guide to page 37, you’ll see that 4.2.1.4, section titled “Slow Start,” still exists and would still be operative in the NRPM, which says, after some introduction: IP address space is allocated to ISPs using a slow start model. Allocations are based on justified need, not solely on a projected customer base.

My opinion, I’ll defer to staff, is that that covers your concern, which it says you can’t just get addresses based on projected, predicted customer base; you must do it based on customer need.

I believe that is and has always been what actually dictates slow start, not this one-year/three-month thing.

John Curran: I believe the section and principles is applicable. But Jason is correct in that in explaining it to someone requesting for space, it might be worthwhile to include “based on previous utilization of existing blocks” to prevent the number of times we have to point people back to the principles as opposed to having it in the line that they’re requesting under.

Scott Leibrand: Message received. I will work with the author and the AC to attempt to clarify this.

This is important for whether we can get this done in the next policy cycle. Would you consider that clarification to be a major change to the policy or is it consistent with the intent and would constitute a minor change? Pending seeing the text itself.

Jason Schiller: I think if the text is carefully worded, I would consider that to be a minor change.

Scott Leibrand: Okay. Thank you.

Jason Schiller: I do have one other concern with the policy as written, but I’m going to sit down for now and see if anyone else wants to discuss it.

Vint Cerf: I don’t see anyone else at a microphone,

Scott Leibrand: There’s a remote,

Vint Cerf: That’s right. Okay.

John Sweeting: I have a remote. Marla Azinger, who was having a few problems registering with jabber, so she IM’d me. She states she does not support these changes, and now I’m just going to read this as her: Replace and retitle Section 4.2.4.3, subscriber members less than one year. Maybe support if you fix it. Should say “and,” not “or.” A business can purchase a business set in the same year they need to do a market transfer of addresses. This should not be limited to either/or as that is ignorant of how organizations can function. Replace with 4.2.4.3, request size, ISPs may request up to a three-month supply of IPv4 addresses from ARIN or a 24-month supply via 8.3 and 8.4 transfer.

Vint Cerf: Is the difference in “and” and in “or”.

John Sweeting: I think she’s saying that you could do both of those rather than just one of them as it kind of…

John Curran: I do not believe it’s a material change regarding the via 8.3 or 8.4 transfer. A party would request under one or the other. We would treat that as both if they were doing somehow a transfer of both.

The prior comments with regards to purchase of a business, and those are 8.2 transfers, which are not subject to any of this, so I don’t, I guess I’d welcome additional clarification from Marla on the point. This doesn’t, none of this language would be operative in an 8.2 transfer.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I think Marla is confused between 8.2 and 8.4, not realizing 8.4 is an inter-RIR version of 8.3.

Vint Cerf: One more comment in the back.

David Farmer: David Farmer, University of Minnesota, ARIN AC. In English “or” is not the exclusive or, and so I think it’s fine the way it is.

Vint Cerf: Would it be helpful if it said “and/or” in that case.

David Farmer: Possibly. But I get in trouble when I use and/or, so…

(laughter)

Vint Cerf: Other comments? Anything from remote? Here we are at the front, please.

Tim Huffman: Tim Huffman, Business Only Broadband. So going back to the replacing the language where you can request a three-month supply, my concern is that if we’re getting rid of Section 4.1.1 where essentially you’re telling somebody to go somewhere else and request IP addresses before coming to ARIN, what’s preventing a new ISP from doing the scenario that the first gentleman suggested where you come in and basically you’re a brand new business and you need a /8 and here’s your business model?

Vint Cerf: John.

Robert Seastrom: Robert Seastrom, Time Warner Cable, ARIN AC. Typically when someone comes in and says “I need a whole bunch of address space and here’s my business model,” and I have no previous history with ARIN, they would be doing it under the immediate-need policy. And that requires a fair amount of substantial documentation. Requires you to use it immediately, and the immediately is within some number of hours after you get it. It’s not a three-month sort of thing. And it’s for a /16 to a /24, completely different section.

That’s not what’s being addressed here. Yes, it’s limited. /16 and /20, whatever our minimum allocation is right now for where you are, actually.

John Curran: Under existing policy, a new ISP who comes in is immediately asked their utilization of the block they receive from their upstream; hence, the Policy Experience Report that Leslie gave earlier today. Because at runout, if you’re a new ISP and the first thing we ask you is “What was your utilization of the block you received from your upstream,” and you say, “My upstream wouldn’t give me a block,” we sort of have a problem because there’s no way for you to get address space from ARIN as an ISP without first having a upstream utilization except under the immediate-need policy.

This language wouldn’t change ARIN’s practices at all. Even if 4.1.1 was removed, we would still for an ISP require the use of their existing utilized blocks. And if they have none, we would say: You don’t qualify by policy. We say it today, and we’d say it after this was adopted.

Vint Cerf: Other comments.

John Sweeting: Just one from Marla: Owen, I’m not confused.

Vint Cerf: I don’t see any others standing at the microphones, no other remotes, which means Jason could come back if he wishes.

Jason Schiller: Jason Schiller, Google, NRO NC. My other concern was the removal of Section 4.2.5, the Web-hosting policy, but I believe, as it’s currently written, that is no longer being removed. So thank you.

Scott Leibrand: The original proposal was to include that because another proposal came in that does the exact same thing. We elected to remove that from this proposal. We’re going to discuss that next.

Vint Cerf: Let’s see if we could summarize where we are on this discussion. It sounds like the word changes which Jason considered to be minor could be considered by the AC.

And I’m not detecting, except for Marla’s comment, I’m not detecting any other requests for modification. If that’s the case, we may be very close to being able to adopt the recommendation.

So shall we find out?

John Curran: If we can have our tabulation engine get ready. I’m looking for my people. Yes, very good.

Vint Cerf: So I think the question we need to ask is that the people will raise their hand if they agree with the proposal and with the suggested slight modification in order to cover the slow start question.

So if you are in agreement with all of that, please raise your hand and keep it up until the tabulators say that they have completed their task.

John Curran: As always, if you’re raising your hand, it’s nice and high. And your elbow should not be bent. Please keep your hand up until I nod. Okay.

Vint Cerf: Let’s now find out, I see more hands going up and down.

I think we’re done with the tabulation on the vote for. How many people are against this proposal?

John Curran: If against, raise your hand high.

John Sweeting: Since I seem to be Marla’s proxy jabber right now, she is against.

Vint Cerf: Thank you. I have a question, John. Is it normal to ask for abstentions since not everyone raised their hand, which is very peculiar.

John Curran: There are many people who have very exciting email that they’re attending to during the show of hands. I can’t explain this, but I know this to be the case.

Vint Cerf: Pay attention!

(laughter)

Vint Cerf: May we have the results of the tabulation, please.

We need background music of some sort to go along with this to increase the drama.

Thank you very much.

It says the total number of people in the room is 101. Those in favor, 21; those against, one. That suggests that there is support for this proposal and that we will proceed.

I have a comment, I guess, coming from the back of the room. Yes.

David Huberman: Hi. David Huberman from Microsoft. Mr. Chairman, I know this is totally off topic, but it seems like the appropriate time. This brings back to something we’ve been discussing a little bit on PPML. We have 22 people showing consensus or not saying yay or nay to an ARIN proposal. We have another 10 or 20 on the mailing list. And I would beg the Board to look at, if we are doing proper participation, if these people really represent the North American Internet operators community, who this directly impacts. Like participation is too low and we as a community and the ARIN Board, as our Board, I think have a responsibility to address this low participation.

John Curran: What’s your suggestion on that?

David Huberman: As I wrote on the mailing list, I don’t feel I’m sufficiently wise enough to have a really good answer. I’m willing to put in any time and effort required to assist with that. It’s something we need to think about as smart individuals, as smart engineers, or look at other organizations who have successful participation and see what they’re doing differently than us.

I’m sorry, I don’t have a good solution. I can only point out what I perceive as a problem.

Vint Cerf: Of course, we can only proceed with what we get in some sense. There are some places where fines are imposed for failing to vote. One wonders: Take away some of your address space if you don’t participate.

(laughter)

Vint Cerf: Let’s go to the next topic.

John Curran: We have a remote comment.

John Sweeting: Yes. So Marla suggested possibly putting voting up on the website of these proposals.

John Curran: Okay. That’s a suggestion we’ve heard. We’ll talk about that.

We actually are at the point in time where we have four minutes before break. The policy that we are looking at actually has time before and after the break. Rather than starting on that four minutes, I’m going to actually say we’re not going to start. We’ll start after break.

So we are going to take a brief refreshment break. We will resume at 11:00 where we will pick up with the ARIN Recommended Policy 2014-4, the Web Hosting Policy.

ARIN-2014-4: Remove 4.2.5 Web Hosting Policy

John Curran: Okay. Welcome back, everyone. If you’re out in the hallway, please find your way back in. We’ll be picking up on the schedule of the policy block.

Next up is our Recommended Draft Policy ARIN 2014-4: Remove 4.2.5 Web Hosting Policy.

So I’m going to cover the staff introduction to that, and then I’m going to ask John Springer to come up and do the AC presentation.

So 2014-4. History. Started as ARIN Proposition 196 on January 2014. The AC shepherds, John Springer and Andrew Dul. The AC accepted as a Draft Policy in 2013. It was presented at the Public Policy Consultation at NANOG 60. AC recommended adoption in March 2014. The policy text is, of course, online and in your Discussion Guide.

Policy would remove the existing NRPM 4.2.5 as technology specific language that’s obsolete and not in sync with current network practices. If the policy were removed, ARIN staff would still be able to require technical justification for web-based hosting using the overall requirement to show efficient use as outlined in NRPM Section 4. The proposal could be implemented as written. Minimal resource impact.

Legal assessment. The policy does not create any legal concerns.

I will now turn it over to John Springer to do the AC presentation. Thank you.

John Springer: Good morning, ladies and gentlemen. So this is another bit of cleanup that we’re doing.

The author identified an area that is a purported no op. The current language and policy reads: When an ISP submits a request for IP address space to be used for IP-based web hosting, it, meaning the ISP, will supply (for informational purposes only) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy change.

The proposed policy amendment is to remove that section.

The referenced technical justifications for informational purposes only appear never to have taken place. Needless to say, because they didn’t take place, they haven’t been analyzed. It is therefore not necessary to collect this information going forward.

As the gentleman in the audience mentioned earlier, this was duplicated earlier in the previous policy proposal, Recommended Draft Policy 2013-7, but was removed because we felt it didn’t need to be duplicated.

Questions?

Discussion

Vint Cerf: The floor is open for questions or comments.

John Curran: People who wish to speak in favor or opposed to this recommended Draft Policy please come to the microphones.

Scott Leibrand: Scott Leibrand, Limelight Networks. I’m in favor of removing this. It doesn’t do anything, hasn’t done anything for a while, and is not needed.

Vint Cerf: So there.

(laughter)

Vint Cerf: Here comes Jason again. Jason.

John Curran: You say with such enthusiasm.

Jason Schiller: Jason Schiller, Google, NRO NC. I’d like some clarification from staff. 4.2.5 seems to suggest that maybe the rules for what an organization qualifies for is different, whether they are a transit provider or a web hoster. And the operational practice seems to suggest that they’re treated differently.

Would removal of this section then treat transit providers and ISPs identically with regards to how much space they qualify for and how utilization is justified and considered?

John Curran: So if I can respond to that. The section on Web Hosting Policy, 4.2.5, says: When a request is, when an ISP submits a request for IP address space to be used for IP-based web hosting, it will supply (for informational purposes) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy change.

At the time that this was first put in, there was a question of whether or not web hosters could universally use domain-based hosting and eschew IP-based hosting. The idea was if someone specifically requests addresses because they have to do IP-based hosting, we should ask the reason why.

Subsequent actual practice in the industry, because of things like SSL certs, have shown that everyone does IP based Web hosting. And that’s prevalent. The requirements for what a web hoster must meet is the same as any other ISP in terms of utilization.

The only question is whether or not we repeatedly asked people are you doing IP-based web hosting for purposes of, for example, certs and they say yes and we record that.

Staff has fallen down in analyzing the repeated yeses of every web hoster who comes to us since this policy was adopted.

Jason Schiller: John, I want clarification on something you said. Hypothetically, if a transit provider asks ARIN for a /20, puts 80 percent of those addresses in use by assigning it to customers, come back subsequently, asks for another /20, puts 80 percent of those in use by assigning them to downstream customers, comes back and asks for another /20 and does 80 percent and so on and so on, they can continue to justify for addresses and the same is true for web hosters?

John Curran: No, the same policy applies to both, but, remember, your prior blocks have to be utilized, not 80 percent. The last block is 80 percent.

Jason Schiller: What about all the previous blocks.

John Curran: Previous blocks have to be fully utilized.

Jason Schiller: What does that mean?

John Curran: Fully utilized. But it’s not different between web hosters and any other service provider. Fully utilized sometimes means there’s stranded addresses. Sometimes people can’t move because of technical reasons, so you’re not going to achieve 100 percent utilization. But you need to show that you could not reallocate those addresses wherever they are even if they’re stranded. Fully utilized for all prior blocks; 80 percent for the most recent.

Jason Schiller: Removal of this text does not change that?

John Curran: Does not change that.

Vint Cerf: Does that mean you’re not objecting to the proposed removal at this point.

Jason Schiller: Jason Schiller. I do not object to the proposed removal at this point.

Vint Cerf: Any other comments, questions, issues? Are we ready to find out the opinion in the room? Looks that way. Anything coming from remote?

Robert Seastrom: We’re still having issues with the remote.

John Curran: We’re having issues with remote. Meaning are they currently able to participate in polls or not?

Robert Seastrom: It’s a problem with this particular laptop or area. The poll participation is not a problem; I just periodically end up hung.

John Curran: Do we have any remote questions? I see we can participate in a poll. We can do a remote poll; is that correct? I see my people saying yes.

Vint Cerf: In that case, I think we can go ahead with the local and remote polling on this question.

If you vote yes for this, you will be conveying to the AC that removal of Section 4.2.5 is an acceptable action.

Let me ask: All those who are in favor of that, raise your hand. And please keep them up. I ask the same question for remote, assuming that our remote managers will relay that to them as well. Please keep your hands up so the tabulators can catch the vote.

We really need to have an electronic way of doing this, don’t we? This is so archaic.

John Curran: You can put your hands down.

Vint Cerf: Any who wish to oppose this removal? Raise your hands.

John Curran: Nice and high if you’re raising your hand.

Vint Cerf: I see none. Can I get confirmation that the remote, a remote response has been received on both positive and negative?

John Curran: Mark confirms that.

Vint Cerf: In that case, we’ll ask the tabulators to come and report.

John Curran: In the past the tabulation was done by our financial team. Now it’s done by the lawyers. And I note it takes longer to add numbers.

(laughter)

Vint Cerf: So for the AC there are 103 people in the room, 32 are in favor of this; zero are against. And I gather that since there’s no indication of any incoming from remote, maybe no one voted on the remote side.

So that’s the feedback.

John Curran: What was the remote tabulation?
In the remote room, there were 11 remotely in and seven of them were yes. And they’re in that count.

Vint Cerf: Oh, they’re in the 32. I see. Okay.

John Curran: We don’t distinguish.

Vint Cerf: In that case, I see it includes meeting room and remote. I misread this. My fault. We’re good. So.

32 are in favor. So there’s the feedback.

John Curran: Okay. Thank you very much. Thank you, John. We truly do not distinguish the remote participants.

Jason, I see you at the microphone.

Jason Schiller: Can we get the total count in the room and remote.

Vint Cerf: Total count in the room and remote was 103. I misread it to be only in the room. That was my mistake.

John Curran: Moving ahead. We’re going to move to the next policy, and the next one we have is our Recommended Draft Policy ARIN 2014-7: Section 4.4 Micro Allocation Conservation Update.

ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update

John Curran: So I will do the introduction, and then I will ask Andrew Dul to come up and do the AC presentation.

This originated as ARIN Policy Proposal 200 in January 2014. Andrew Dul and Robert Seastrom are the shepherds. The AC accepted this as a Draft Policy in January 2014. It was presented at the Public Policy Consultation held at NANOG 60. AC recommended adoption in March 2014. The Draft Policy text is online and in your Discussion Guide.

This proposal would modify existing NRPM Section 4.4 to require Exchange Point Operators to have a minimum of three participants.

Staff assessment. This proposal would have no operational impact and could be implemented as written. Minimal resource impact to implement. Predominantly internal procedures and staff training.

Legal assessment. Does not create legal concerns.

I’ll now turn it over to Andrew Dul to do the AC presentation.

Andrew Dul: Thank you, John. Good morning, everyone. This is probably one of the simplest policy changes we ever had at this point. There’s a one-word change in this policy proposal.

John Curran: Famous last words.

Andrew Dul: So to deal with the problem statement. In an Internet exchange point, generally, you consider two people to be a private peering and more than two to be more of a public peering. And the current policy is that two people present could come and get a micro-allocation from ARIN for an exchange point, and this policy would change that to be three people.

So here’s the big change: The word “two” becomes the word “three.” Nothing else changes in the policy. The policy originally contained some changes to another sentence, but for clarity purposes we removed that change after feedback from the meeting at NANOG.

We believe that what the author was originally intending was to really change the number, not to deal with some of the other issues that exist within this Section 4.4.

So, as the shepherds, we believe that it was in the best interests to just move forward with the single word change. That was the most substantive of the issues that we were dealing with. And we will look at the other issue the author raised at a separate time I believe.

So the main question is does the community support raising the minimum requirement from two to three, and that is the discussion on the table.

Discussion

Vint Cerf: Microphones are now open for discussion. I recognize the gentleman from Microsoft at the rear microphone.

David Huberman: David Huberman from Microsoft. I stand in support of the proposal. Simply I believe the time will come where we will run out of IP address space for IXs, public IXs to avail themselves of. I support not only raising this requirement from two to three but I would support a higher requirement. I think this is a good proactive proposal by the community.

Vint Cerf: Thank you. Other comments?

Martin Hannigan: I’m Martin Hannigan, and I am the co-founder and treasurer of the Open IX Association. For the purposes of the micro allocation proposal change, I represent the Open IX Association, an Internet industry created effort to tackle serious issues in the infrastructure related to IXPs, data centers, and physical Internet interconnectivity and directly related to the security, stability, and resiliency of the Internet.

Open IX is a nonprofit, open, transparent, and membership-based organization with public participation in standards development and a certification service to support the standards framework.

We have two standards: OIX 1 for IXPs, OIX 2 for data centers, both ratified by the public community and the members and the Board.

I want to voice our support for this minimum change. Our community developed and ratified OIX 1 standard defines an IXP. Quoting OIX 1: A physical network infrastructure operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Autonomous Systems. The intention is to connect more than two Autonomous Systems.

Thank you.

Vint Cerf: Thank you, Martin. Mr. Woodcock.

Bill Woodcock: Bill Woodcock, PCH at this point. So the definition of an exchange point has always been three or more peers interconnected. The issue is the startup phase. So at the point which an exchange is starting, it may be difficult for them to show three parties actually committed. I’m not opposed to the change. I don’t think it’s an unreasonable burden.

Just for purposes of discussion, I think there are a lot of exchanges that try and get off the ground and fail and are gone within a year. If they don’t have three participants within the first, say, three or four months, it’s unlikely that they ever will.

But I see a lot of exchanges that get started with two participants in the first couple of months, and then number three and number four and number five all show up in the first year.

So three is a reasonable requirement. But in implementation, you might want to be relatively casual about the requirements for demonstrating the commitment of the third one and relatively rigorous in the cleanup and reclamation of things that have failed, which I doubt there’s very much of at all.

John Curran: May I respond? Recognize that your advocacy regarding being rigorous in the cleanup is problematic, because reclaim of anything has potential for business impact, reclaim of something operating an exchange point could have some significant business impact if reissued.

Bill Woodcock: Well, the thing is an exchange point is not like a company where it has assets that go on for a long time and customers and things get blocked by different people. When it disappears, it’s just gone. There’s nobody left to advocate for it, no participants, no assets. Right? So usually you can track down one of the original founders who can attest to that. So there is some cleanup.

John Curran: Got it. You mean aggressive cleanup at demise, not at stumbling?

Bill Woodcock: Correct. Because there’s a significant number that actually…

Vint Cerf: Go ahead at the front microphone first.

Owen DeLong: Owen DeLong, Hurricaine Electric, ARIN AC. I don’t care one way or the other about the proposal. In general I’m inclined to oppose it because it’s pretty much a no-op, and we’ve already wasted more time than we should have on it.

Vint Cerf: Martin.

Martin Hannigan: Thanks, Vint. So someone also asked me where they could see these standards. They’re at www.open ix.org. There’s a public membership list, all of our incorporation, all of our DoJ filings and whatnot are on the website. Our members list is there.

With respect to Bill’s comments, I think we mostly agree there. The one thing I disagree with, and I believe I posted to PPML, with respect to the state of the current allocations, it’s a disaster actually.

I pointed out three, but I did a pretty comprehensive review. There are some errors, which I’ll be happy to point out to Registration Services. The six recent allocation is encountered as a /22, it’s a/24, et cetera. There are multiple allocations that are being used by individuals that did fail long, long ago; they just kind of flew under the radar.

We discussed the issue with respect to new entrants and getting started and the difficulties, but we basically came to the consensus that renumbering is not hard. I’ll also point out that there are other references to renumbering in the NRPM, and it actually appears to us as though ARIN doesn’t believe renumbering is difficult, especially when you go from a /30 to a /24.

So that’s basically our position. And we’re willing to work with new IXPs to help them succeed, but we do think in light of exhaustion that conservation is a reasonable approach, especially with the recent proliferation of IXPs in the United States. I’m sure that you’re probably aware that there’s a giant, enormous amount of activity in Ashburn, in New York City, and as a result of Open IX we actually have competition for once for data centers for interconnectivity on cross connects and on IXP ports and things.

So we generally support, I support what Bill is saying, but we discussed the renumbering issue and we think it’s valid. Thank you.

Vint Cerf: Thank you. One more comment from the back microphone, please.

Albert Daniels: Albert Daniels, ICANN representative from the Caribbean where it is a lot warmer than it is in Chicago right now.

(laughter)

Albert Daniels: First I’d like to refer to the comment on participation, because I saw that slide indicating that there are only two participants from the Caribbean. But I know ARIN supports far more than two members in the Caribbean region where the scale of things tends to be much lower than in many of the parts of the world.

There are some IXPs coming off the ground in the last six to ten months, and in many cases those IXPs would have a maximum of two participants. So I just wanted to throw that into the mix so there’s consideration to some regions where it is in some cases unlikely there would be more than two participants participating in an IXP.

John Curran: Could I ask a question about your statement? You said there will be some potential exchange points where the maximum number of participants might be two. Did you mean the initial number of participants, or did you truly mean maximum?

Albert Daniels: The long term situation because we typically have two or three ISPs in each of the islands or territories.

The larger companies, maybe they just all flow aligned. And when there is an agreement to pair, it’s likely that it would just be those two who would be pairing with nobody else coming later on.

John Curran: Right. And when two ISPs peer bilaterally, I did this a while ago, but I don’t think it’s changed that much, they can directly interconnect and directly use addresses that are already assigned to their equipment.

I only see people doing exchange points where there’s three participants, otherwise a bilateral connection is easily affected.

Albert Daniels: John is right, but the reality in the Caribbean is typically it tends to be two, sometimes three.

John Curran: Thank you.

Bill Woodcock: Well, while that is certainly the case starting out, I think the whole point of getting an actual exchange in rather than just doing bilateral interconnection is to enable new market entrants, which, because of the very low populations and small economies, may not happen on the access side but may happen on the content side.

So, for example, in almost all of those new exchanges, you actually have root servers going in and ccTLD nameservers going in in addition to the carrier. So you may be thinking of this as a carrier only situation, but actually it’s the content providers that are mostly going to be enabled by this.

Vint Cerf: Martin.

Martin Hannigan: I’m Martin Hannigan from Akamai Technologies, switching hats. If there’s any two member IXP that would like a third, please contact me and I’ll be happy to consider being number three AS.

Andrew Dul: I just want to point out there’s an interesting mathematical issue with the number two versus the number three, although it’s not really an issue, but if you have three and one of them leaves, you don’t have an exchange anymore. And if you have three participants and one of them leaves, you still have two people there.

And where the address space comes from with a three participant organization versus a two participant organization, in a two participant organization, one of them can always supply a /30. And if it goes away, it just goes away. But in the case of a three person participation, you can’t just, one of them just can’t supply the address space, because if that party leaves, then the entire exchange point is then in limbo of what happens with the address space.

So there’s a distinction that happens between the number two and the number three in terms of operability.

Vint Cerf: Mr. Seastrom, you have a comment from outside.

Robert Seastrom: Rob Seastrom, ARIN AC. This is a question for a gentleman from ICANN, whose name I unfortunately did not remember, and for Bill, which is we have traditionally done /24s for Internet exchange points, sometimes bigger if they can justify it, and that’s sort of the lower bounds of what has been traditionally carried in the global routing table. But it makes sense to not carry exchange points in the global routing table.

And is now the time we ought to be thinking about smaller allocations for places that are geographically sized such that /24 would be unreasonably large and we would be able to keep the barrier of number of participants at the beginning as a smaller number if we were perhaps doing a sparse allocation thing with the initial /28 with the /27 reserved or /27 reserved to /26 or something like that? Thank you.

Vint Cerf: Bill.

Bill Woodcock: So as part of the OECD five-year interconnection survey thing, one of the things that we were expecting to find was that there would be a pileup of exchange points that had 255 participants, another pileup of exchange points that had 511 participants or whatever; that the renumbering, the combination of renumbering friction and getting more address space friction, would cause exchange points to hit a bit of a wall before they could move on.

We did not in fact find that. And so part of the interesting thing or the necessary thing is that there be the ability for exchange points to grow beyond 256 or 512 participants.

But, realistically speaking, not that many actually do, as you’re saying. Right? So you could draw a curve of exchange point sizes. And obviously each exchange point that’s successful is growing over time, but there are only a small handful that ever need more than 512 addresses and a small minority, far less than 10 percent, need 256. Right? So then the question is: How many need 128.

And for a small exchange point in the Caribbean countries, some of these countries with, say, fewer than 100,000 people in them, same thing, bunch of Pacific Island countries that are not in our remit, I think 64 addresses is probably enough to support all of the competition in those economies for the duration of the relevance of IPv4.

I think they need to decide whether they think they’re going to have the kind of exchange that is going to warrant the larger block or not. So if they’re in a small economy and they charge a lot of money, then they’re never going to have very many participants. If they’re in a medium sized economy and they’re free, they may well grow because they have a lot of sort of new market entrants.

But, yes, what you’re saying would preserve the length or the run time of the IXP reserve pool, and I very much believe that we need to be looking at reduced minimum allocation sizes.

Robert Seastrom: I would be interested in further discussion on that and right sizing from anyone who’s interested. Please get in touch with me.

Vint Cerf: Do we have somebody from remote comment at this point?

John Sweeting: Yes, Vint. Marla Azinger, Frontier Communications, states: On the topic at hand, yes, I support this. Operationally and technically this makes good sense.

Vint Cerf: Martin.

Martin Hannigan: Thanks, Vint. Martin Hannigan, Open IX Association. This is not a “me too.” I just wanted to elaborate a little bit more on what Bill said.

So to be clear, the definition that we established defines more than two AS numbers, not devices or addresses.

I think that we would be willing to work on defining/redefining a more suitable definition that would be conducive to the Caribbean. But I also want to point out that we have IXPs in rural areas in the United States like Omaha, Minnesota, and other places that were similarly disadvantaged and were able to maneuver at least some of the initial requirements to get beyond the two participant limit.

I don’t think the Caribbean is that different, to be honest with you. I think that some of the problems that we have with success down there, and I’ll note I have experience in the Caribbean working for the Bahamian telephone company, is more related to the recipe.

I think Curaçao was a good example of success in the Caribbean that could be copied to other exchange points.

But with respect to scope, I just don’t see it. I think that there may be a minimum or a maximum of two or three parties that could potentially be affected, and it should be easy to find up there, especially with the Internet growing at 80 to 70 percent a year.

So, one, the definition is more than two Autonomous Systems. And, two, Open IX would love to work on this definition with anybody interested. And we have a public mailing list, and it’s www.open ix.org/mailman/public.

Thank you.

Vint Cerf: Let me remind everyone that we’re trying to keep to a limit of three minutes, so let’s keep that in mind. Yes, next, I’m sorry, John.

John Curran: Very sorry. I just want to also remind everyone: To the extent that we’re all speaking, it’s good not to specifically refer to other companies or business plans. You might need to use examples, you might want to talk about something, but we really are supposed to be focused on ARIN and ARIN’s policy. And to the extent possible, we can do that without referring to specific companies and their business plans.

That’s probably best in this forum, just a brief reminder.

Vint Cerf: Please go ahead.

Albert Daniels: The name again, Albert Daniels from ICANN. Just to support the comments from Bill. Bill has been very active in the Caribbean region encouraging the deployment of IXPs. I fully support the statements he made.

Vint Cerf: Thank you.

Aaron Hughes: Hi. Aaron Hughes, in this case peering DB admin hat on.

We frequently use reverse DNS to help verify whether or not an IP address within a subnet belongs to a given exchange point participant. And it’s worth noting that there may be a cost associated with reverse DNS delegation for smaller than /24s in ARIN’s infrastructure, and that cost may be more than the savings of allocating smaller than /24 allocations such as worth consideration in further discussion on that topic.

Vint Cerf: Where does that put you with regard to the proposal on the table?

Aaron Hughes: I’m unsure at the moment.

Vint Cerf: I see. All right.

Any other comments either local or remote?

Vint Cerf: Sounds like our tabulating crew needs to get busy again. The question on the table is whether to make this one word change to define the minimum requirement for IXPs to be three rather than two.

So if you raise your hand, you will be voting in favor of the change. Let me ask all who are in favor of this proposed change to raise their hands and keep them up until the tabulating committee is done.

John Curran: Again I remind people nice and high.

Vint Cerf: Do we have a similar response from our remote participants? I want to find out whether we’ve got, all right. Now, all those who are against this proposal should raise their hand now. Please keep your hands up. Same question to the remote participants. Put your hands down now. Thank you very much.

Andrew Dul: To the Chair, I have a question, if we could ask a subsequent question after this is tabulated, about if the community believes the AC should continue working on the issue of smaller blocks for IXPs.

Vint Cerf: Okay, I’ll raise that after we finish this tabulation.

John Curran: We have jabber counts. We have one participant who said they could not vote via jabber and they were in favor.

Vint Cerf: They were in favor. So the implication is, the statistics are that there are 88 in the room and 13 remote, thank you for splitting that out, total of 101. 31 voted in favor, two voted against, and this last comment suggests that it’s actually 32 who voted in favor.

So you have some positive feedback from that. I’d like to ask whether we can also address this other question, reducing the minimum size that is allocated to an IXP. Is there an interest in this community in pursuing that further in the AC? If there is interest, I wonder if I could ask for a show of hands that would like to continue that work, would like the AC to continue that work.

If you’re in favor of working on that, please raise your hand. Keep them up. A slow wave is happening. This is fascinating.

John Curran: If the hand is up, it needs to be up. If it’s wavering, maybe you need coffee.

Vint Cerf: Those who are against this. I see two so far. Three. Could I have the tabulators bring the results. You can put your hands down now.

John Curran: You need a microphone, but the question is can we re-ask the question for jabber.

For the people in the remote: Do you want the AC to work on the question of smaller micro-allocations for exchanges? If so, yes; if no, no.

Vint Cerf: I’m terribly tempted to ask that this process include a sealed envelope so that I could add to the drama when the answers come back.

John Curran: We have a drum roll if you want it. That’s all I can give you.

John Sweeting: One remote.

Vint Cerf: In the interest of efficiency, I see that we have two people lined up at the microphone. Here comes the answer. So this will be feedback for further work by AC on this question of micro-allocations for IXPs.

The response is 88 in the room, 13 remote; 101 total. 21 were in favor of continuing to work on reducing this minimum size; three were against.

So that’s the feedback for AC, which sounds like you should continue work.

Mr. Hannigan.

Martin Hannigan: Thank you, Vint. Martin Hannigan, Open IX Association. I want to point out that there was, at least in the room, overwhelming support for the single change. And my suggestion would be that the AC actually create a policy with respect to changing the minimum allocation size versus drag this one on because we have the overwhelming support and we have the standard, and I think it would be reasonable to at least go forward with what we seem to agree on. Thank you.

John Curran: Just to respond. I presume that was the question, was to continue independent work on a separate proposal for this purpose.

I would advise the AC if they actually touch 2014.7 for this purpose, that would recommend a significant change and would reset it, making it no longer a recommended Draft Policy.

So I think the AC knows about that, but it’s worth saying, yes.

Vint Cerf: We have one last comment at the rear microphone, please.

Bill Darte: I’m Bill Darte. I’m on the Advisory Council, and I would like to remind everyone we have a room set aside for policy discussion.

So on anything that’s been said this morning or in the future in this meeting you want to gather a group of people who are like minded and want to communicate with something like this and bring it back to the meeting yet in this meeting, that’s what that’s for.

So just a reminder that it’s available for people who would like to have discussions around policies or other issues.

Vint Cerf: That room is marked with a big arrow saying Policy Meeting. I think also you could invite people who were not necessarily like-minded because that would be part of the debate.

Bill Darte: I meant like-minded about the discussion.

John Curran: Now I’d like to, we’re done with the morning policies, which has been very productive. I thank everyone. We’re now going to have a brief update from Andy Newton about our API and Software Development Toolkit, and then we’ll break for lunch.

Vint Cerf: Stunningly, we’re precisely on time.

API Software And Development Toolkit

Andy Newton: Hi. I’m Andy Newton, Chief Engineer for ARIN. I’m here to talk about our APIs and our toolsets that we have available. We have over the years had some APIs that we’re continuing to refine and add to our systems so that it better enables the community to write their own tools as opposed to depending on the limited resources that we have in the ARIN staff to do things for you.

So the purpose of this is to help you create your own tools that are better customized for your own needs.

We have a series of tools that are available on projects.arin.net, and as always, if you have questions about our APIs or our tools, you can send questions to arin-tech-discuss and someone will answer you.

The set of APIs and tools we have can be categorized into two sets. We have the legacy tools, which were given to ARIN when operations were handed over to us from Network Solutions way back in the day, and those are the email templates and essentially Whois.

Over the years we’ve added things to that, so the new set of tools we have, and we haven’t decommissioned any of the legacy stuff; I want to make that clear. But over the years we have the new set of tools, like Reg-RWS, which is the RESTful way of doing the provisioning, kind of the counterpart to email templates; Bulk Whois, the Whois-RWS system; and now a new thing called RDAP. And on top of that we have a couple of open source tools, again, available on projects.arin.net, which you can access.

The other way to kind of think about it is it’s a kind of public versus provisioning. So some of the tools are more geared towards giving public data out even if it does require an API Key. Because sometimes, even though it’s public data, we require an AUP to be signed. And then in other cases it’s just flat out public data.

And then for the provisioning, of course, we always need to know who you are when you’re doing a SWIP or asking for resources.

To get an API Key, it’s quite simple. You log into ARIN Online and go to your Web account tab over on the left navigation, and you get an, request an API Key, and one will be generated for you. It’s that easy.

Do keep in mind that API Keys are secret. So if you’re asking for help from anybody or posting things on arin-tech-discuss, it would be advisable not to put your API Key in any type of examples you hand us.

So from the provisioning side we have the classic email templates. Email templates aren’t going away; in fact, their usage is up. And we do see from time to time, actually, when we do our maintenance upgrades, we come in on a Saturday morning at 7:00 and we shut the systems down, and when we turn things back up, we see hand email templates coming through, people who have gotten SWIP templates, and they’re obviously hand-edited.

So people are still doing this. They still use them. They still do it by hand. And it kind of speaks to a need of having a better way than our more automated way of doing that for SWIPs.

The other thing is that email templates, even though your system may not be able to put an API Key in the email template itself, you can associate an email address with it to get the email templates through.

Reg-RWS is the newer interface for doing that. It’s the RESTful system. It’s XML over http. It’s very popular. The usage is up considerably. We have more transactions going on over Reg-RWS than we do with templates today. Much more actually.

And in many ways there’s things you can do over the RESTful system that you cannot do with templates. And I’ve got that list there.

The other thing that’s not listed on there is a lot of people will, and we don’t put these in the stats, a lot of people will constantly ask for what ARIN considers their data to look like. They do this constantly all the time, hundreds of times a second every day.

One of the new features we just added in with our last release was the ability to use Reg-RWS to maintain your ROAs if you have a hosted system with us in the RPKI system.

The other thing that’s kind of useful with Reg-RWS is that you can use our OT&E environment, the Operational Test and Evaluation environment. So this allows you to write your programs, test your code against our APIs with real data, but you’re not affecting your data in any way. This is a copy of our production database which gets put into our OT&E environment every month. You can go ahead and play with that data, change it to what you need to do to make sure code is working. You can find more information on OT&E at that URL.

As I said, the usage for Reg-RWS is way up. I guess about a year ago was when the swing point occurred. You can see those red bars keep growing. As I did say, the templates are also growing, so template usage hasn’t gone down, it’s gone up, but RESTful usage has gone way up.

These numbers don’t include the GETs that are going on. Those aren’t transactions; they’re just reads from our database. And those happen, like I said, hundreds of times a second.

The other thing is you can get Bulk Whois programmatically as well, also a REST API call. Requires an API Key because you have to sign an AUP with ARIN in order to get bulk Whois data in any form. But you can do this RESTfully. So if you have a process where you need to actually get bulk Whois on a daily basis as opposed to manually coming into the website and logging in and clicking the button, you can write a simple little program to get it.

On the public access side, the data that’s publicly available, we have Whois, which is the old classic Port 43, and then Whois-RWS. Whois-RWS is XML and JSON over RESTful http. We had for quite some time a higher query load over that channel than we do with the classic Port 43.

The problem, the downside with both of these is that with Port 43 everyone does it differently. So if you have to write some program in order to go against Whois, you do it different for ARIN versus RIPE versus LACNIC or whoever. And then the domain registries are also different as well.

Unfortunately with Whois-RWS that’s still kind of true. We developed this before there were any standards around this. And we still had people using it all the time. So what you see with Whois-RWS is really only an ARIN standard. But I’ll talk about this other thing called RDAP in a minute to kind of get around that problem.

The query load is up slightly over this time last year. And you can see it does sort of reflect Port 43, but it did pass back somewhere in 2011.

Vint Cerf: What was that big peak?

Andy Newton: That was interesting. That was, I believe, Mark, correct me if I’m wrong. That was a bot someone had written,

John Curran: That looked up itself,

Andy Newton: That looked up itself, yeah.

John Curran: The first thing it did is tried to do a Whois query on the host it was running on; is that right, Mark?

Mark Kosters: Yes. That was one of the very interesting characteristics that we saw. In fact, that was the first little spike. The larger spike was even more interesting. That was going after single sign on with various large social media sites.

So both of those have quieted down quite a bit. But we’re ready to handle the load if someone decides to do something like that again.

Andrew Newton: Should they decide to do that, we have all the infrastructure still there.

So I said at projects.arin.net we have tools available. What we have there that specifically addresses our APIs is a set of command line tools, and we call it ARINcli. And what you can do there is you can access both the Whois-RWS side of things and also Reg-RWS with these tools.

Arininfo is a command that uses, it’s basically a Whois-RWS client. If you ever wanted an example of how to write a client against our Whois-RWS system, it would be a good place to go looking. But it’s also very useful just in and of itself in the fact that it will present the data in a lot prettier format than classic Port 43.

So one of the things you can do with this that’s a little more difficult with Port 43 is you can get a tree structure printed out for you. It will sort the networks for you and put the ASs in sorted order as well. Does a lot for you.

You can look for your tickets in this command. So you don’t just have to log onto ARIN Online to do that. If you want to use the tickets command, you can actually go look up your tickets. You can even post replies to tickets using this tool.

This is a really cool feature. We have this command called RDNS which helps you with your reverse DNS management. You can actually hand it a zone file, it will parse the zone file and then decompose that information into RESTful calls, into Reg-RWS, and help you provision your NS and DNS records into our systems. You don’t have to do that by hand. It’s not very easy to do with the website because there’s a lot of cutting and pasting that has to go on if you do it that way.

And then there’s more you can do. You can manage POCs, you can request reports. I incorrectly put down that the tool can do RPKI ROAs right now. That’s kind of in a branch and not ready for prime time, but that will be there soon.

And then there’s RDAP. I mentioned earlier that Whois-RWS is kind of an ARIN standard only. The way, the XML that we have over that is very specific to how our data model looks. RIPE has their own system as well, and I think one of the other RIRs has a system.

So we got together, a bunch of us got together, and we decided to try to come up with a standard for doing this that all the RIRs use. And then we took it to the IETF, and the IETF got the domain registries involved because Whois is not actually, a lot of people think it’s a simple topic, but it really gets quite complicated very fast, especially when you bring in the domain registries. They have a simpler data model than the RIRs, but they have a lot more policy implications.

But, anyway, we have a number of big domain registries involved in the working group. All five RIRs are there. All five RIRs have pilots up. And then for the domain side, VeriSign, Afilias, and Neustar also have pilots up. And with VeriSign and Afilias, you’ve got 90 percent of the domain market doing RDAP.

ICANN, I believe, as I’ve been told, ICANN is requiring this now in all new TLD contracts. So all these new domains that are showing up in the root, they’re also going to have to have RDAP going once the standard actually reaches RFC status.

So we do have our own, like I said, we have our own pilot registry running. There’s the URL for it.

And we also have another thing called the bootstrap server. So one of the interesting issues you have with both Whois and with RDAP is how do you find the correct server to go talk to, what’s the authoritative server for the information you’re looking for.

And the IETF WEIRDS working group, which is working on the RDAP standard, has come up with a way of basically using the IANA registry. One of the issues with that, though, is that parsing these registry files for a simple client is not that easy.

What we’ve done is we’ve created what’s called a bootstrap server. It’s a piece of code, you can run it on any Web server, I guess, and it will go download the IANA files for you, parse them, and then you can point a simple http client at that bootstrap server and it will direct you to the right place.

The other thing we have, and that’s open source code, by the way. You can get that at projects.arin.net as well.

The other thing we have is a command line client for RDAP called NicInfo. It is actually the only RDAP client currently available, and it is also open source. It will also do its own bootstrapping, but it can use the bootstrap server as well.

Any questions?

Discussion

Vint Cerf: So I will – do we have questions online? Oh, I’m sorry, go ahead.

Andrew Dul: The question I have, Andy, is have you started thinking about how you move from the current ARIN standard to the real maybe future standard?

Andrew Newton: The current implementation, current pilot we have actually builds upon that same code base. So it wouldn’t be terribly difficult for us to support both going forward. And, in fact, so we continue, we support both the Port 43 and the Whois-RWS thing today. It’s all the same code base. Couple little differences on the presentation layer.

But moving forward doing both RDAP and Whois-RWS is not going to be a big deal for us.

Andrew Dul: Thank you.

Vint Cerf: Online comments as well, please.

John Sweeting: Again from Marla Azinger: What is the predicted IETF RFC approve date for RDAP.

Andrew Newton: I wish I knew that. Good question. I thought it would be done now. Currently the working group is dealing with the bootstrapping. That was the big issue that came out of the last IETF.

There is a decided upon method going forward. There are, I don’t know how to put this politely, political issues in dealing with certain I* (I – star) registries that aren’t represented here, but, and how you overcome that. I’m not the one dealing with those talks, but they’re trying to figure that out.

Vint Cerf: Question in the back of the room as well, please.

Ralph Bischof: Good morning. Ralph Bischof with SAIC. Happy 50th birthday to the Ford Mustang. Just got a question on the Bulk Whois. Do you happen to have the requirements for the authorization to receive such?

Andrew Newton: I do not. We have an AUP.

John Curran: There is a Bulk Whois AUP that you must agree to in order to receive a key for Bulk Whois access. The AUP is online. Is there a question about it?

Ralph Bischof: No, just where to find it.

John Curran: Oh, I’m sorry. It is online. If you go into ARIN Online, you go to Bulk Whois, request key. You can find it. It’s also on the website. There’s a section under Services, and you can look up Bulk Whois access.

Vint Cerf: I have a question. This is not related to anything that you specifically spoke about, but we’ve all been hearing about Heartbleed problem. The question is whether you were affected by it and is there something that anyone involved in ARIN should do? We have an answer. Thank you.

Mark Kosters: As soon as that came out, it quickly passed all our systems. We are not adversely affected by it any worse than anyone else that’s out there. But we are patched now and we’re good to go.

Vint Cerf: Having patched, of course, it still leaves you with the potential two-year period during which that bug was available. Are you making recommendations to any of the ARIN participants as to passwords or other mechanisms for authentication?

Mark Kosters: There’s a couple of latent issues underneath that need to be fixed. One example is the secret of the actual cert itself being exposed. And we’re working with our CA right now to get a new cert to get that taken care of.

The other part is that as user authentication, we’re going to have to work through a plan on getting passwords to be changed.

John Curran: Let me ask a question, Mark. Right now someone who used ARIN Online, potentially, if there was an interested party trying to access the interesting aspects of the library, they might have been able to obtain a password of an ARIN Online user?

Mark Kosters: Yes. You’ve read this as much as I have. So the likelihood of that happening seems to be on the low side.

John Curran: Extremely remote. My question is: That was present right up until last week; now we’ve rebuilt the library for ARIN Online.

Mark Kosters: Excuse me?

John Curran: Have we rebuilt the OpenSSL library so that’s no longer possible to happen?

Mark Kosters: We’re actually using the TLS features through our Apache Web server. So there’s nothing that has to be changed through ARIN Online to make this happen.

John Curran: Okay. So my question then is there’s a remote chance that people could have had their ARIN Online password compromised, and if they change it at this point, that’s no longer an issue, no longer a risk.

Mark Kosters: That’s correct.

John Curran: We probably should send a message out for those people who are interested in changing that password, as remote as the chance of the sniffing actually was.

Mark Kosters: Yes. So there’s multiple things going on here. So one of the things that we’re going to do is we have to get a new cert. And once that new cert is out, we’ll announce that. Once we announce that, then we can, people can feel very confident that they can change their passwords.

John Curran: At that time we’ll tell people.

Mark Kosters: Yep, yep. And that communication has gone out from our CA: Hey, look, we’ve got to reissue all these certs; we know, we’re working on it.

So they’re really under the gun themselves as well.

John Curran: Got it. We’re waiting on their timing in order to address that.

Mark Kosters: Exactly.

Vint Cerf: Seems to me that it would not hurt to say exactly what you just said about what the conditions are, what you’re waiting for and so on.

Mark Kosters: Exactly.

Vint Cerf: One other question, if you don’t mind my intervening this way. Some people use two-factor authentication as a belt and suspenders tactic. Is that also available for people who are making use of ARIN’s services.

Mark Kosters: One of the things that Andy brought up, I think it was at the last ARIN meeting, was a proposal way for us to go forward was a simple two-factor authentication method. We’d love to get feedback from the community if this is the right way to go forward. And then we’ll put it on a docket.

John Curran: We received very lukewarm interest in that. It’s not that we don’t want to do it, but we really need people to say they want it in order to make sure we justify the engineering involved. Because it does have a bit of effort.

Vint Cerf: Jason, are you coming to the microphone? Is this a discussion, is this a discussion, if it’s a side discussion, then please take it outside. Thank you.

John Curran: Any other questions for Andy? Thank you.
(applause)

John Curran: Okay. Very good. We are about five minutes, we’re almost on schedule. We’re five minutes late. This is actually time for us to break for lunch. We are going to break now. We’re going to resume here, coming back at the next policy block at 1:30. So you have an hour and 25 minutes.

Lunch is, here we go. Lunch table topics. At the tables you’ll see signs. AC council representatives will be hosting discussions at the various tables around the room. If you have an interest in a policy, you can find a lunch table discussion.

TeamARIN is our hashtag. Use it and go to the Facebook page and talk about the meeting.

Take your valuables with you. The room is not locked. We’re going to resume at 1:30. Lunch is where? Susan? Straight across the hall.

ARIN-2014-10: Remove Sections 4.6 and 4.7

John Curran: Let’s get going. So the first one we have is Recommended Draft Policy 2014-10: Remove Sections 4.6 and 4.7. Right. Yes. Thank you. You’ve got “2014-10: Micro Allocation Conservation Update” on this slide, but I’m thinking the title is wrong. The slide’s right. It is 2014-10, but it is not “Section 4.4 Micro Allocation Conservation Update.”

The title slide should say “Recommended Draft Policy ARIN 2013-10: Remove Sections 4.6 and 4.7,” which is what this says.

Okay. 2014-10. Origin. Was ARIN Policy Proposal 201 in January ‘14. It was a result, the ARIN Board of Trustees suspended Sections 4.6 and 4.7 of the Number Resource Policy Manual at their January 6th meeting.

That was per the Policy Development Process. The Board has the ability, if it recognizes a significant risk, to suspend the policy and ask for an ARIN Advisory Council recommendation. That happened January 6th and was announced to the community.

As a result of that, a proposal was put in. The AC shepherds, Tina Morris and Robert Seastrom. It was presented at the PPC at NANOG 60. The AC accepted it as a Draft Policy in February 2014 and recommended adoption on March 2014. The online policy, the text is online and in your Discussion Guide.

The proposal seeks to permanently remove the suspended NRPM policies 4.6 and 4.7 based on the rationale that any number of large organizations could potentially abuse these policies and request enough address space to completely deplete ARIN’s available pool of addresses in one request.

These are sections that allow return of address space to get an equivalent amount for purposes of renumbering in aggregation. There are organizations that have more space outstanding than we have left in the free pool. So this would be a very quick depletion process.

These policies have been rarely used by the community since their implementation and, in fact, have not been used at all in the last six years. The last request to use Section 4.6 was in 2004; the last 4.7 aggregation request was in 2008.

Customers wishing to return resources to ARIN have always been able to and can continue to do so even without this policy in place.

The proposal could be implemented as written and would have no operational impact. We need to update our guidelines and online materials, obviously.

The policy does not create any legal concerns.

And I’m going to ask Tina to come up and give the AC presentation.

Tina Morris: As he just said, this is pretty straightforward. It came to light that Sections 4.6 and 4.7 could be abused. They are little-used policies. The last request using 4.6 was in 2004; the last request using 4.7 was in 2008.

Given the potential for abuse with v4 runout approaching, it was determined that they should be suspended. The Board suspended them. The AC agreed. This is just to formally remove them from the policy.

Had a lot of discussion on PPML. Not much debate. Everybody seems to be in favor of it.

Any questions or discussions?

Discussion

John Curran: Okay. Microphones are open for questions or discussion of this.

Vint Cerf: The gentlemen at the rear microphone, please.

John Springer: John Springer, Inland Telephone, ARIN AC. I support the policy as written.

Vint Cerf: That was nice and quick.

I have a question. Is this policy specific to IPv4 only?

John Curran: So the removal, the policy is to permanently remove them. And when you remove something, it’s not specific to anything once it’s gone.

Vint Cerf: Of course, but the question was whether they were specific to v4 at the time they were prepared.

John Curran: I will look briefly. That’s actually a good thought. I don’t think it was ever envisioned to be applied, but I can tell you in a moment.

Leif Sawyer: John? Leif Sawyer, GCI. 4.7 actually includes the aggregation requests must be evaluated via ARIN in accordance with the current IPv4 allocation policy.

John Curran: Right. So they were specifically v4.

Vint Cerf: I think that’s an important thing to be made.

Did we have a remote come in.

Scott Leibrand: Yes. Remote comment from Marla Azinger: Yes, support. This can’t be supported any longer due to runout and the need or use of it is poor planning to the address market.

So Marla Azinger supports the removal of these.

Vint Cerf: Any other comments? Seeing and hearing none, says the deaf guy, I’ll ask the tabulation committee to prepare themselves. Microphone access is going,

John Curran: They’re up and ready. Okay.

Vint Cerf: So all those in favor of adopting the policy, which is to remove Sections 4.6 and 4.7 permanently, please raise your hand and keep them high until the tabulation is complete. I ask the remote people to perform a similar action.

John Curran: Okay.

Vint Cerf: That’s good. Any opposed?

John Curran: Nice and high.

Vint Cerf: That was pretty easy. Do we have confirmation from the online folks as well?

John Curran: We do.

Vint Cerf: All right. In that case we’d like to hear what the results of the tabulation are.

Thank you very much. The tabulation says that there were 83 in the room, nine remote; 92 total. The vote in favor is 32; the vote against is zero. So it sounds like we have a fairly significant response.

John Curran: Excellent. I’ll say confirming the wisdom of the Board.

ARIN-2013-8: Subsequent Allocations For New Multiple Discrete Networks

John Curran: So moving on to the next policy, Draft Policy 2013-8: Subsequent Allocations for New Multiple Discrete Networks.

ARIN staff, this originated as ARIN Policy Proposal 191. ARIN staff reported on this issue at ARIN 32. The AC shepherds, Cathy Aronson, Owen DeLong, and Robert Seastrom. AC accepted it as Draft Policy in November of 2013; recommended adoption in March 2014. It was presented at NANOG 60 PPC. It was revised and reverted to draft status at that point. It’s now back before us. And it is available, of course, in your Discussion Guide and online.

It is a work in progress, so this is a seeking feedback. Is this good number policy? Is it fair and impartial? Is it technically sound? Should the AC continue work on this or get rid of it.

I’m now going to turn over to Cathy to do the AC presentation about it.

Cathy Aronson: Hi, it’s me again. Super excited. I can tell. Wait, where are my slides? There they are. Thank you whoever made that happen.

So this came directly from the Policy Experience Report and we have changed it slightly. Well, I’ll get to that.

Anyway, the staff, I just got really loud, the staff wanted us to codify in policy what they’re actually doing with this policy because it wasn’t actually written down. So that’s what we’re trying to do here.

This is really small text. What we did before the PPC is we changed this little italicized text to be what it is right here, “has demonstrated need.” Because when we were at the PPC, people weren’t comfortable with has connectivity at the new location.

And then we found from staff that that wasn’t, perhaps was too ambiguous for a policy text. So what this is what’s in your Discussion Guide, but the current text is this. The current text is “has a contract for connectivity” at the new discrete network.

So basically there wasn’t any written down policy for, if you became an MDN, there was a policy for that. So you had your multiple discrete networks and there were policies to get address space for an existing discrete network. But there wasn’t a policy written down for a new discrete network. So the title’s a little bit wonky.

That’s what we’re trying to do here. These are the two changes that would write down the criteria.

This is what we’d really like feedback on as opposed to what’s in your Discussion Guide, and the only difference is the change in the little bit of italicized text.

And I think that’s basically all we really wanted to discuss here, because we’re just at draft status.

Discussion

Vint Cerf: Just to confirm: The only thing that you’re proposing are the two italicized highlighted elements or not? No.

Cathy Aronson: This is the whole policy text. All I’m saying is what’s different in the Discussion Guide is the little bit of italicized text. Sorry if I wasn’t clear. I was trying so hard.

Vint Cerf: Just confirming.

Okay. This is the gentleman from Microsoft.

David Huberman: Good afternoon. David Huberman from Microsoft. I have a question. I’m not sure how it would work.

Cathy Aronson: How what would work?

David Huberman: So I’m of the opinion, and my opinion would be this “contract for connectivity” stuff is way overbearing.

I think, but I’m not sure, which is why I’m asking at the microphone, that the additional allocation criteria, the math, would stop somebody from abusing this if we were worried about abuse.

So let me take a step back. Sorry. So I’m not in favor of requiring in policy a contract for connectivity. I think that’s operational. I think that’s up to the ARIN staff to determine what level of verification is needed for a new allocation under the multiple discrete policy.

Okay. Second of all, if it’s in there because we’re worried about abuse, I think the math of how you get more space takes care of that anyway.

Cathy Aronson: Okay. It’s in there because the ARIN staff asked us to put it in there, because that’s what they do.

David Huberman: That’s nice, but they can do other things. I don’t want that in policy.

Cathy Aronson: But you’re saying, I’m sorry. You’re saying it’s up to their discretion, but they’re asking for it to be written down so that what they’re doing is in the policy. So I’m not sure, I don’t know. Maybe somebody can help me here.

Vint Cerf: John wants to help. Go ahead.

John Curran: John Curran, ARIN staff. We have hit the point in time now where people are remarkably creative about additional requests, need for additional address space, and that’s putting staff in a situation where if we’re going to be administering particularly the MDN, because the MDN policy allows for new network sites, the idea of demonstrated need could be highly variable.

If we turn someone down because they claim demonstrated need for a site and we don’t have a clearer criteria, we are likely to get more disputes over the administration of IP address space.

So we’ll administer whatever this community sets, obviously. But the difference between demonstrated need and a contract for connectivity is a contract for connectivity is objective and a demonstrated need becomes, is less objective and becomes more in dispute as we get people far more anxious.

David Huberman: If the problem you’re trying to solve is the first sentence you made, which is people getting more and more creative, then I’m strongly against this policy because I don’t think we should be making operational policy taking care of the 1 or 2 or 3 percent who cheat versus the 97 percent who are just trying to get IP address to run their networks.

John Curran: 97 percent don’t use this policy. This is a policy,

David Huberman: Of the people who use this policy.

John Curran: Yes.

David Huberman: Some who are very large; some immediate; some just trying to build the network that has disconnected sites. I don’t like writing policy for the others who are actually trying to cheat the system.

John Curran: Right. I agree that the percentage of people using this policy is very high percentage of the people using this policy. It’s 100 percent.

Unfortunately, that doesn’t actually address what I was saying, which is that the, as I said, we’ll implement whatever the community wants.

If you put in demonstrated need, we have to recognize that that is ultimately a subjective judgment when compared to something like a contract for connectivity. If the community wants that, that’s fine, but we’re finding ourselves in a greater and greater disconnect with applicants under the MDN policy.

Vint Cerf: Bill, can I call on you next?

Bill Woodcock: So as the operator of a network with more than 100 disconnected sites and 28,000 disconnections and fewer than two dozen contracts across those 28,000, that means that at the very most we have one contract per four disconnected locations; that is, at least 75 percent of our locations have no contracts associated with them.

How would we use this policy?

John Curran: This might not be the right policy, then.

Bill Woodcock: The disconnected networks policy is not the right policy for an operator of a disconnected network.

John Curran: My question is what criteria do you want us to use for that purpose?

Bill Woodcock: I’m not sure you can just sort of pick one and expect that that one is going to make it impossible for anybody to cheat and is not going to have unintended consequences for everybody else.

Vint Cerf: Thank you, Bill. Martin.

Martin Hannigan: Good afternoon. Martin Hannigan from Akamai Technologies. I’m one of the extra large users of this policy. I oppose the policy. It’s unbearable. I don’t think ARIN even knows what they’re looking at half the time or what you actually want. Do you want the MSA in Amendment 1 or Amendment 1001? Do you want the MoU? Do you want the Akamai Accelerated Network Partner’s agreement version 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10.

There’s multiple ways to enter into agreements with facilities and partners. As Bill pointed out, they don’t always involve contracts.

I can point to multiple locations I have MDN space at that I don’t have a formal agreement in place because there’s mutual benefit for me to be there.

I recently went through this exercise with ARIN after the PPC and after it was made abundantly clear that the contracts issue was a problem, which I guess I think in the preamble to this it said that there was really not a lot of objection. I think people should go back to the tapes and watch because there was significant objection to the contract issue here.

I don’t think you can make it work for us or for yourself. I don’t think that you have the manpower to actually understand what you’re looking at and to verify the contents of the contract, and I think that you actually open yourself up for more abuse than not. And I just don’t think this works at all. Thank you.

Vint Cerf: Yes, John.

John Curran: Just a question. You’re referring to the modified policy statement. The prior policy statement, if you go back, which still cleans up the MDN policy but says demonstrated need, could you comment on that?

Martin Hannigan: They’re equally useless, to be honest with you. Has demonstrated need is just a mechanism to pick and choose and cherry pick what you want to look at to verify need.

I also agree that ambiguous policy is not necessarily a good thing and it’s ripe for abuse, especially for individual parties.

Not sure what to tell you here. I think that you guys don’t even sound sure yourselves when you talk about this. I think you should go back to the drawing board.

John Curran: You’re saying we should stay with the current policy, but we should revise,

Martin Hannigan: I think you should completely go back to the drawing board and rethink the whole thing. Not MDN, just this particular, the old text and the new text.

Vint Cerf: Jason.

Jason Schiller: Jason Schiller, Google and the NRO NC. Seems like there’s a couple of different cases that somebody might come back with multiple discrete networks. Certainly there’s the case where they don’t have any multiple discrete networks and they’re carving into multiple discrete networks. We know how to deal with that. We have a history of usage, and we can use that history of usage as divided among multiple discrete networks.

It also seems to me that there are cases where a provider might have a service, let’s call it Service A, and that Service A exists in five locations that are five multiple discrete networks. And they might have decided that one of those regions has gotten too big and they want to cleave it in half, so Region 5 becomes Region 5 and Region 6.

In this case there also seems to be a history of usage that would support going forward what the growth of the new smaller Region 5 and new Region 6 would be. You can go back, do the math, figure out what the utilization was over the course of the year for that region had you cleaved it a year ago. So it seems to me to put those back to slow start seems unfair.

Also, if you already have five regions because you’re in five metro regions and you’re going into a sixth metro region and you’ve got history for growth for a new metro region and you’ve got history of growth for the servers overall, seems to me you could put together a case that suggests you should get more than just the initial slow start allocation.

Certainly, however, if a provider is offering Service A and they then decide that they want to offer a new service, Service B, and that is a multiple discrete network, certainly there’s no history that suggests what the run rate should be, and in that case certainly they should be slow started.

And the reason why I make reference to slow start is because the policy suggests that you should go back to the minimum allocation under 4.2.1.5.

Vint Cerf: John.

John Curran: Just to be clear. Are you in favor or opposed to this policy?

Jason Schiller: I guess I have a question. I want to know what does ARIN staff today do with multiple discrete networks under those three cases and are we now suddenly penalizing people into slow start that previously weren’t.

Cathy Aronson: No, because you can use immediate need.

John Curran: Right. We apply slow start. It’s very easy to extrapolate someone’s past demand and utilization going forward for the period for the next three months, which is what’s applicable.

It’s when someone shows up and says, By the way, my need is larger than what would be extrapolated by a slow start because I am also adding 34 sites. And we go, Oh. And those 34 sites, because I had 20 and now I’m adding 34, I actually don’t need just the growth you projected; I need two and a half times that to roll out my services at the additional sites. And we go, Well, that’s obviously a valid need, that’s demonstrated need, and we’re trying to clarify with MDN organizations, please explain to us why those 34 sites are real.

Well, it’s not crystal clear what would be objective criteria for those sites being real. And so it’s not a question of whether or not we can provide people additional address space under slow start. That’s not a problem. It’s when they want to go multiples of their slow start to accommodate their new needs.

And we’re trying to figure out how to validate that business growth above and beyond slow start. Does that help?

Jason Schiller: I think the concern here is when somebody says, I’ve got a new multiple discrete network because I’m in a new location, you want some proof of that.

I am not concerned about that. I feel like,

John Curran: When they say we have dozens of new ones,

Jason Schiller: Sure. Whatever. One, 12, it makes no difference. I assume that there’s some justification. They can show they’ve leased space, they’ve shipped equipment to locations,

Cathy Aronson: That’s what we’re trying to codify in the principle.

John Curran: That’s what we’re trying to get more clearly in policy.

Jason Schiller: Yes. I’m trying to address a different aspect of this. The other aspect seems to be, as written, when I come back with a discrete location, I will get the minimum. And I’m not sure if that is the current ARIN practice and if that’s what the community desires, if my new discrete network clearly has a year’s worth of history that suggests I should get more than the minimum.

John Curran: Your model of how people are using this policy is somewhat simple. It’s people seeking far more than the minimum for those sites that we’re trying to get some better criteria for how to assess need. Not the case of getting them the minimum.

Cathy Aronson: But he’s saying he thinks they’re going to get defaulted back to the minimum when they could show justification for more than the minimum.

Jason Schiller: The way I read it, it says: The new network shall be allocated the minimum allocation size under Section 4.2.1.5.

Cathy Aronson: Unless it can be justified,

Jason Schiller: Unless under immediate need.

Cathy Aronson: Right. That’s how the staff functions right now. That’s what we were told.

John Curran: That’s how we function now.

Cathy Aronson: Andrew wrote this back in the day.

Andrew Dul: Andrew Dul. So my understanding of how staff is doing this now, they are only using immediate need; they are not using the minimum allocation size. So the minimum allocation size is a new option. If you have 35 new sites and the minimum is /22, then you can have 35 /22s.

And the question is: What criteria do we apply, if any, to the legitimacy of those 35 new sites? If the answer is you just have to say you have 35 new sites and you get 35 /22s and that’s what the community wants to do, that’s fine.

But the other question is: If not, what checks do you want ARIN to do to have an organization prove something along those lines of what you have to do to say that those 35 sites are real? They’re not just something on the end of a tunnel with six things.

John Curran: Right. It is if they meet the 50 percent qualification presently, if an organization is unable to satisfy this 50 percent minimum utilization, the organization may alternatively qualify for additional Internet address registrations by having all unallocated block sizes smaller than ARIN’s minimum allocation size.

That’s the present policy.

I agree, the question is what constitutes a new site, and presently there are no criteria that make that clear in the MDN policy.

Andrew Dul: No, I think the criteria for what constitutes a new site is clear, but the trigger of when a new site is real is the question here.

John Curran: Okay. I’ll take that phrasing.

Andrew Dul: Whatever. But I don’t know. Like people have objected to the word “connectivity contract,” can you use the word agreement with connectivity. If not, what other mechanisms, if any? If people don’t want any mechanisms, then that’s fine. But people have said: We don’t want to just give away /22s to everybody. So what criteria? If we need a list, let’s write a list. But if we need a criteria, let’s come up with some criteria. If we don’t need criteria, then let’s move on without any criteria.

John Curran: In today’s age of virtualization, a party can claim a new site with no externally measurable entity. So I guess if there’s a belief that that’s a physical site, if there’s a belief that that has connectivity, if there’s a belief that that involves equipment, it would be nice to have the members provide us any further qualifications of a site that they can, but they don’t have to. We can live with the existing policy. We’re just noting that the existing policy provides no framework to judge the reality of a site.

Vint Cerf: I think we need to take the gentleman in the back first.

Robert Seastrom: Rob Seastrom, Time Warner Cable. I’m on the ARIN AC, but I also operate a very small organization with a friends and family colo, and contracts are pretty thin on the ground for us. Moreover, can we go back to the contract page, please? Yeah, contract connectivity. There we go.

I’m going to do a little bit of role playing here, and I’m going to play the role of somebody who is trying to game this.

I can show you a contract for one of two things. Which would you like, a cross connect to an unspecified location in your favorite colo provider with nothing about what it may be hooked to router wise on the far end? It’s just fiber. That’s a contract for connectivity. I can also show you a POTS line, and that’s contract for connectivity. Now give me my space. That’s what this policy requires.

I think that this level of codification is so vague as to represent a no-op functionally. So I’m opposed to this as worded.

Vint Cerf: I have, it’s Vint. I have a question that I’d just like people to think about, and that’s the two complications here. One of them is a policy which might make some people’s lives, maybe yours, more complicated and difficult, and the other side of that is how to protect people from abuse.

So I think that we’re struggling here with figuring out what the best path is to assure that there’s not so much abuse that the address space disappears improperly.

Bill, let me take you next and then Martin.

Bill Woodcock: So Rob games the system with a $7 a month POTS line whereas I have upwards of a million dollars investment in every new 100 gig sites and no contracts to show.

So I think we have a problem if you can spend $100 million, sorry, 100,000 or a million dollars on turning out the site and being unable to meet the criteria or $7 to game the policy and be in with no additional documentation.

Shipping equipment was suggested as one mechanism, and we have customs and way bill documentation for international shipments, like into the Caribbean, but for domestic shipments, you know, what’s in the box is sort of up to what somebody types in on the FedEx form, right?

John Curran: Do you have a recommendation, Bill, regarding text?

Vint Cerf: If I can intervene one more time. It seems to me that Bill has put his finger on the problem, which is that any particular thing we pick can probably be discounted and gamed.

So now we’re back to this awkward question of do we trust everybody’s assertions and is there anything that could be done post hoc to deal with the possibility of a fraudulent request. I don’t know what the answer is, but we’re clearly struggling with that.

Let me get Martin and Owen.

Martin Hannigan: Martin Hannigan from Akamai Technologies again. I also wanted to comment on the minimum allocation language. I would caution ARIN to be extremely careful when applying such language to existing services. Limiting market share is a very dangerous thing. Thank you.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Just to throw it out here, it’s a little bit less concrete than a contract for connectivity, but what about evidence of deployment?

Vint Cerf: I have this handful of nuts and bolts unscrewed from a shipping container, and here they are, all 722 of them. Jason.

Jason Schiller: Jason Schiller, Google. I think I like Owen’s suggestion, evidence of deployment. I think we can give some more guidelines that make it stronger, proof of acquisition of space, whether that be a contract to rent space, purchase of a facility, proof that equipment has been shipped, deployed and installed, whatever. Some commitment that you’re actually deploying building a network.

We can ask for these things; they may or may not be easily verifiable. But I suspect ARIN is fairly good at looking through the requests and guessing when there is a legitimate request and when there’s not. And when they suspect there’s not, then they can hold the requester to the standards that they think are appropriate, and that could theoretically be show me your facility, unlock the door to me, if need be. I think ARIN can figure that out, though.

Vint Cerf: So, Jason, just for clarification, you’re suggesting, along Owen’s lines, the language, if there is any at all, says something about evidence of deployment and not any more specific than that allowing, this may be allow the staff to choose a variety of means for trying to validate the credibility of the request.

And although it’s not as precise as the one that’s being proposed here, it has the benefit that it allows, a range of possible ways of assuring, or at least determining whether or not this site is real.

Jason Schiller: Absolutely. And I think that this community can also give some suggestions of things that might be considered acceptable in addition to a contract for connectivity.

Vint Cerf: One might anticipate, for example, a list of things but not excluding some others, as a way of making it more precise but not excluding or not limiting the mechanism. That’s a fairly flexible proposal.

Jason Schiller: And based on the strength or the weakness of the request, ARIN can further investigate as needed.

Vint Cerf: Thank you very much, Jason. Next.

David Huberman: David Huberman from Microsoft. My question is: Why do we care? By the time this gets through, if we had total consensus in this room right now, by the time this actually gets implemented, we expect ARIN is either out of address space or sufficiently close, it doesn’t really matter.

So in a post exhaustion world, where we’re dealing with mostly the transfer market, why is this relevant, please.

John Curran: If I could respond.

Vint Cerf: Yes, John, go ahead.

John Curran: If we’re post-depletion, I’m not sure an MDN policy is necessary. Someone needs to figure out the interaction of MDN and transfers. But that’s more of a transfer question than anything else.

We presently are not post-depletion. People shouldn’t give up on making good policy until we are post-depletion. So I think your spirit is right, but I can’t guarantee that we won’t be in a position of executing this policy at the end of this year.

It’s unlikely, but I would not, there’s no reason to stop in the race and start walking now when we’re actually not across the finish line.

David Huberman: I respect that, but I strongly disagree with that, because I think we have to make policy today for tomorrow. I think what we should consider in policies is what’s going to work in 2014 and beyond when we’re out of space. Because the last bits are the last bits, you know.

John Curran: I’ve got slides for the last five years that show depletion dates of ARIN running out starting as early as 2011. So I understand the belief, but I also, policy for 2014 could easily still have us making allocations.

Vint Cerf: Let’s continue. First, let me check: Is there anything online? Let’s take the gentleman at the rear microphone.

Gaurab Upadhaya: Gaurab Upadhaya from Limelight Networks. I think I agree with Bill and Marty about, it’s going to be very difficult for me to give a contract for connecting really to anywhere, because I don’t think even my legal people will agree that the contract between two mutual parties is something I can share with a third party at all. But what Owen insisted earlier, evidence that something has been deployed or is going to be deployed is something that we could probably give at an engineering level, might be more acceptable.

But having dealt with our legal department over the last six months, I think they will not allow me to give my contracts to ARIN. Thank you.

Vint Cerf: Thank you. I was about to say last comment but it isn’t. So let’s continue.

John Springer: John Springer, Inland Telephone, ARIN AC. In terms of Owen’s suggestions, perhaps credible evidence of connectivity or deployment. I like the idea of examples.

And then to respond to the gentleman from Microsoft, I don’t think the Policy Development Process allows us to abandon policy proposals just because we’re at a certain stage of the game. I’m willing to be corrected on that.

Vint Cerf: Martin.

Martin Hannigan: Martin Hannigan, Akamai Technologies again. Sorry to keep popping up, but I wanted to acknowledge that I agree with Gaurab. There potentially is some middle ground here with respect to the deployment suggestion.

I think that I could, and perhaps others could as well, provide some sort of evidence of deployment. Now, if that meant code word for contracts, then we’re back at square one. But if that actually means like I have a project and I have deployment plans and I have the officer at a station I think that should be good enough and that’s probably something that we can compromise on. Thank you.

Vint Cerf: Thank you, Martin.

Any more comments online or in the room.

Scott Leibrand: Christoph Blecker from Disney Interactive: I’m inclined to agree with Jason/Owen’s suggestion around evidence of deployment. This allows flexibility while still having some level of proof needed to give out space based on multiple sites.

Vint Cerf: Thank you. I have a question of John, I guess. This doesn’t feel like the sort of thing that a vote is needed for. This is feedback. So let me ask you what the practice would be.

John Curran: At this point no poll of the community is necessary unless the shepherds would want a poll to abandon or not continue work.

I don’t know if they want that or not. Do you actually want a poll saying should we continue work on this.

Cathy Aronson: I think that would be a fine idea.

Vint Cerf: In that case, we’ll conduct such a poll. The question on the table is should the SHERPA team continue to work on the policies and the language therein for purposes of dealing with these multiple discrete network questions.

So if you raise your hand and you say yes, then the AC will take that as advice to continue work. The pollers are ready. If you want to continue this work, please raise your hand. Those online, please signify your support for this.

John Curran: Raise your hand high if you want the AC to continue work on this policy proposal. Nice and high.

Vint Cerf: What is it about high that people don’t understand.

John Curran: After lunch, people’s hands don’t go as high.

Vint Cerf: Let’s see if there’s opposition. How many people would like the AC to stop working on this.

John Curran: Raise your hand if you want the AC to stop working on this. Nice and high.

Vint Cerf: Thank you. You can put your hands down now. Let’s make sure we get the online community response.

The answer is: With 97 people in the room and 12 remote, that’s 109, high point for today so far. 21 people were in favor of continuing the work and seven were against. So that’s the input.

John Curran: Okay. We’re going to take a little departure from,

Vint Cerf: Sorry to interrupt. Every time you stand in front of this thing I get a huge pile of noise. I know that you’re a noisemaker, generally speaking, but I’m trying to figure out,

The guys who are responsible, I’m not listening to a football game or something, I’m trying to hear what you’re saying, and I’m using this to connect into the PA system.

But what happens is the people who are standing here, they wiggle around and I get huge amounts of noise. So we need to go figure that out. Meanwhile, go ahead, John.

John Curran: I’m wondering if the remote is RF.

Vint Cerf: Well, this is at 72 megahertz.

John Curran: That would be interesting. We’ll take a slight departure from Draft Policy. And we’re going to have Richard come up and give the results of our Customer Satisfaction Survey.

Vint Cerf: I can’t hear.

John Curran: When I’m standing here,

Vint Cerf: If you stand this way for the rest of the meeting it should be okay.

John Curran: That works.

Vint Cerf: Maybe it’s the mobile. Try that. I’m okay now.

John Curran: I’m going to put this back on. Let me know if we lose you. Give me a moment. Come on up, Richard.

Customer Survey Results

Richard Jimmerson: I’m Richard Jimmerson. Recently ARIN has conducted a fully open Customer Satisfaction Survey. This is the first time that we’ve ever done that. We have transaction surveys that we make available to people every time they come in to request resources.

At the beginning of the process, we send them a link to a survey that they can take to let us know how we’re doing and processing the request.

It’s a ten-question long survey. We’ve gotten a lot of good feedback from that over the years. And we’ve recently updated the questions that go on there, and we continue to get good feedback there.

We thought it was very important, though, to go out and do a completely open Customer Satisfaction Survey to see where we were, to see what people thought about our services, so we could take that information and move forward and do something about that.

So the purpose of the survey that we conducted was greatly to gain better understanding of our customer needs.

We hear from all of you in the room here at the meeting, at the microphone, in the hallways. We go out on booths at different events around the world.

We have the NANOG PPCs. We have online interaction. There are a lot of places where we hear from our customers, but we’ve never asked them a completely common question set all across the board to see what they would have to say when they were all asked the same thing.

So we wanted to identify the areas that need improvement inside the ARIN organization, and we wanted to establish a baseline to measure future progress. We wanted to identify the areas to improve and be able to show if we’ve made marked improvement over time. And the first step to that was to conduct this first survey.

So the timeline for this survey is in the fourth quarter of last year, we issued an RFP. Several people came in and responded to that, organizations, and ultimately we selected an organization named Rockbridge Associates.

Immediately they got to work. They came in, sat down with us. They went over everything that we’ve been doing over the last 15 years and started building a survey with us.

And they wanted to go out and they wanted to speak to members of our community in a qualitative phase to actually do interviews.

So what we did is we set up interviews with them where they could reach out to folks and talk to them over the telephone. And what they did is they used those interviews to inform the process of creating the larger survey that went out to the entire community.

There are several of you in this room that actually participated in that qualitative phase in the fourth quarter of last year. And I thank you very much for that.

I think it helped put together a very good survey that went out to the rest of the community. And I want to share those results with you here in the coming slides.

Now, in the first quarter of this year we actually did the survey. It went out. In the second quarter of this year, now that we have the survey results that we’re getting back to share with you, we’re reporting the survey. And inside the organization we are working to respond to this survey to establish and implement a plan to improve customer service in the ARIN organization in response to this survey, in response to what we’ve been hearing from you in the transaction surveys here at these meetings and other places. But this survey has produced some very interesting results.

Tentatively, we’re planning to do a second open survey in the third quarter of next year, in 2015. And one of the reasons why we want to do that is, after we’ve had a year to actually make some changes and put some effort into aggressively going after improving customer service practices, we want to see what the changes have been made over time.

So how did we promote this survey? We sent out an ARIN announcement, of course. I’m sure many of you received that announcement. We did a Team ARIN blog.

And there was an announcement at the NANOG meeting. Betty, at the beginning of the last NANOG meeting, actually had it in the opening slides of the NANOG event and invited people to go to our link and take the survey.

We promoted it over social media. But where we think we got the best response from was we identified all the points of contact that had conducted transactions with us over the years. We de-duped them from the Mailing List and other places they would have gotten an announcement from. We actually sent an invitation email out to all of them.

And the survey was two weeks long. What we found was during that first week we got the largest response. And every time we would send a bulk of these emails out to those points of contact, we would immediately see a surge in responses to the survey.

So it was quite interesting. I think we got a lot of responses that way. Every slide from here on out in this presentation is exactly as it was provided to us in the final report by our contractor, unedited by ARIN.

And what we’re going to be doing, this is an abbreviated version for time on this agenda. We can’t get through the entire results set. But in the coming week, with the publishing of the ARIN Meeting Report, we’ll also be publishing the fully unedited results as provided to us by the contractor so that you can see all the detail.

That will be available online for you to download. But going for the rest of this presentation, these slides all came directly from the contractor unedited from ARIN.

So as you can see, we had 699 people respond to this survey. Initially we put it out there and we had wondered how many people would actually respond to this. And one of our goals was internally we would really like to see over 500 people respond to this survey the first time out that we did it. And we were very happy to have 699 people come in and respond.

Of those people that did respond, 324 of them said that they had direct allocations from ARIN and that they were a member. 353 said that they received direct assignments of number resources from ARIN but didn’t necessarily identify themselves as a member. 16 said they had resources from ARIN and they had no direct resources from ARIN, used some of our services, and six were basically outside of our region that participated in the survey.

So the general overarching questions before we get into the detail are provided here first. Now, we asked some very hard-hitting questions in the survey. We thought that, we asked one question in particular that might be hard to ask as a community to everyone. But I want to go through these with you.

One of the first questions we asked is basically what’s your overall satisfaction with the ARIN organization and its services. And 70 percent of the people said they were highly satisfied. 23 percent said they were somewhat satisfied. And seven percent said they were dissatisfied with ARIN’s services.

Then we asked a similar question but added what is the value you received from ARIN based on the fees you pay. And we received a similar response. 67 highly satisfied percent. 25 percent somewhat satisfied and eight percent dissatisfied.

Now, that third bar up on that chart, I know the text is really small here, but we didn’t want to edit it at all. And I’ll read it out to you. It’s “If you had the option to choose another registry services provider, how likely would you be to continue using ARIN’s services.”

68 percent of the respondents said they’d be highly likely to continue using ARIN’s services. 19 percent were somewhat likely. And 13 percent said they were not likely to continue using ARIN’s services, if they had the option to choose another registry services provider. Very interesting feedback.

So in this final, in this report that you get, you’ll be able to download online, you’ll see there’s a lot of text responses you can read in there.

But we listed some of the reasons here in this report for overall satisfaction. A lot of the reasons people said they were satisfied had to do with our online services. They liked ARIN Online.

And that was prevalent throughout the things that we heard. But when we asked, when people described why they were not satisfied with ARIN’s services, there was a word that came out quite a bit. And that word was “bureaucracy.”

And that was mentioned several times. It was really hard to ignore that that word was used so many times in response to the survey. And that’s something that we need to pay very close attention to and that we are.

So this next slide describes this. But basically what I’m going to do now is I’m going to go into some detail. We split the question set into different areas of performance. We asked people to grade the ARIN organization in different areas.

What you see here on this slide is the full color part on that top bar, 72 percent, is how they rated the ARIN organization. And the dotted line, where it says 89 percent, that’s how they rate their expectation, what their expectation is of an excellent registry services organization.

And the number just to the right of that, 17, is the distance in percentage points we have between how they rated the ARIN organization in that area and what their expectation of an excellent registry services organization is. Basically identifying a gap that they would like us to close.

So with that, that’s how you’re going to see the rest of these slides. Now, in the major grading areas overall, you’ll see that Internet governance was the area where there was the smallest gap between how they rated us and what their expectation was of an excellent registry services organization.

Followed by financial services, engineering, ARIN meetings. And you’ll find that some of the areas where they have the most interaction with the organization are the areas where they’ve identified the largest gaps, where they would like those gaps to be closed.

And those areas are registration services, communications outreach at the bottom.

You’ll find that as we go through these detailed slides, that the area with the largest gap will be on the bottom of the slide.

So just above that, though, is policy development. And what I’ve done is I pulled out several of the slides pertaining to interaction with the Policy Development Process in our meetings.

And I’ve got them towards the end of this presentation so you can see in detail what they had to say about this process for those people who participated in this survey.

So as you can see, with the Internet governance, these are the types of questions we asked them about Internet governance.

We asked if they thought ARIN took an active role in Internet governance. And there was a very small gap there. And we asked if they thought that ARIN supports efforts to keep Internet Number Registry self-governed as defined by the needs of their respective communities. This is the area where we received the highest remarks.

Financial services: There was a gap where invoices and payment processing procedures are clearly explained. They thought that was the largest gap in the financial services area, and they thought we should do a better job of explaining how that all works. By the way, not in direct response to the Customer Satisfaction Survey, but at the same time we actually did, as we’ll find in one of the presentations that are happening here later this afternoon, just recently made some improvements in that area and we’re continuing to work in that space.

Engineering: The largest gap in the engineering space: New technical services and enhancements are delivered in a timely manner. People have identified that their expectation is lower than it is in some other areas. It was at an 85 percent. However, they identified it as the largest gap, when it comes to our engineering services. They would like us to deliver engineering products and services in a more timely manner.

ARIN meetings: The expectation, this is interesting, I think, for this meeting. The content and activities of meetings are at a level of importance and interest that I want to attend. The expectation of an excellent registry services organization was 67 percent, and they rated the ARIN organization at a 53 percent inside that space.

So, basically, of these 699 people that took the survey, they’ve indicated to us that for many of them they’re not interested in the content of the meetings to actually come to the meetings. That’s important for us to note, I think.

We also asked them about things like the election process. The election process is easy to understand and to use by eligible voters. There was a 13 point gap there.

Customer service, general customer service: There’s a very high expectation where it comes to staff works with customers to resolve complex issues. There was a 94 percent expectation. That’s a very high level of expectation.

When we received this final report from the organization that conducted this for us, Rockbridge Associates, they explained to us that anything above 90 percent is usually really high expectation for organizations. And they noted that the ARIN community, the ARIN membership, has very high levels of expectation in certain areas. And they noted that out.

And in this case it was a 94 percent for this complex issues, and we got a 77. So these are definitely areas that we need to work on.

Provides clear and accurate information to customers and members: There was a gap there. Provides timely responses to requests: There was a 14 point gap there. And there’s actually more detail about this that I’ll talk about here in a few minutes. But there’s high expectations in that space.

So when we asked people to describe their suggestions for improving customer service, this is an open ended question, not a rate us on a scale of 1 to 10, but it was type some words and tell us what you think inside this space.

And our consulting organization actually went through and pulled out certain pieces and identified some trends that were important to people in responding to this particular question, and they noted them here.

But when asked where we can improve, one of the number one areas was timeliness. People want us to be more timely in our responses to their requests during the request process.

They want more clarity in the process. And they had some comments about staff. Now, we know that that happens, but the word that they used quite often was “bureaucratic” and “bureaucracy.”

So I just want you to note that as we go through and we look at some of more of these things, and I want to note some things along with that.

Policy developments, we asked them about that. The largest gap between where we are in their minds and what their expectation is: Policy Development Process allows any interested individual to participate. They said they had an 89 percent expectation there out of 100 but only gave us a 71 percent in that space. There’s a perception that the Policy Development Process doesn’t allow interested individuals to participate by some people who participated in this survey.

That’s very important for us to note. And there’s more information about this in the following slides.

Policy Development Process allows policies to change quickly enough in response to changes in the industry. That was the next largest gap. And you can see the other gaps going up here. Again, you’ll get all this detail in the coming week.

Registration Services: The place where they identified we could do the most to improve is the process to obtain Internet number resources is clear and straightforward. That’s not the perception of the people who filled out this survey to a large extent for many of them. So 89 percent was the expectation, and we were rated at 65 percent. They want us to do a better job of providing clarity in the request process.

Transfer requests are processed in a timely manner, was our next largest gap. And resource requests are processed in a timely manner. A lot of the feedback that we got in the open-ended text to this survey had to do with timeliness of responses to requests.

Communications and outreach was another area where they identified some areas where we can make some improvements. I’m able to easily navigate the website and find the content I need. That was the largest area of noted improvement for ARIN.

There was a 90 percent expectation and 68 percent believed that already describes ARIN. So they want us to do more inside that space. This is all very valuable information for us to gain as an organization to help improve our customer service to all of you.

I want to note that we are as an organization working very hard to provide customer service to you. We are working, we have a very big workload like the rest of you. But what we’re doing is we’re taking all this feedback and we’re taking this to heart. We’re going to build a solid proposal for how we move forward inside the organization to make improvements in these areas. And we want you to know some of the areas we’re going to be concentrating on most, soonest, is the areas where these largest gaps exist in this Customer Satisfaction Survey, especially in the areas where they’re reinforced by things that we hear from you at these meetings and that we hear in some of the other research we’re doing.

We asked people how well do these statements describe the ARIN organization. One of them was ARIN adheres to the values of an open Internet.

13 percent of the folks weren’t sure. Four percent of the people said that that does not describe the ARIN organization. But the vast majority of the people said it does describe ARIN or somewhat describes the ARIN organization.

We asked people if they thought that ARIN cares about customers and its members. Seven percent of the people said that it doesn’t describe ARIN.

But the majority of the people did say that it does. ARIN is responsive to the needs of the community. More people were unsure about that in this survey.

And a lot of people were unsure when asked to rate us on ARIN uses its financial resources efficiently. 45 percent of the people said they weren’t sure if ARIN did that or not, because they may not be exposed to actually reading our reports and seeing what’s going on there.

And it’s interesting that the word “bureaucratic” was on this slide, but you should know that that word was used later on in the survey than where they had the opportunity to self describe it earlier on in the survey.

We had introduced that word ourselves because a lot of people have actually accused the ARIN organization of having a bureaucratic field. So we laid it right out there. So does the word “bureaucratic” describe the ARIN organization. 24 percent of the people weren’t sure. 15 percent said: No, bureaucratic does not describe ARIN. But 28 percent said it did describe ARIN. And 32 percent said that it did somewhat describe the ARIN organization.

So these are definitely things that we’re really taking a hard look and evaluation of as we move forward to improve our customer service to you.

So we wanted to point out the word “bureaucratic” here again and the importance that people put on that, how it describes ARIN. You can look at this, and you’ll see there are more slides like this one in this final report that you received. And you’ll also notice that when you do see this final report, that it is all in PowerPoint format. That’s the way that the consulting organization provided it to us.

We requested it that way because we wanted to be able to show it to you exactly as they presented it to us, and we knew we’d be doing it over PowerPoint slide here at this meeting to start with.

Use of ARIN products and services: I guess it wouldn’t be surprising to anyone to see that the most popular service was Whois. That’s the most frequently used service by customers of ARIN, followed by ARIN Online, IPv4 Registration, AS Number Registration, Reverse DNS, all the way to the bottom to Specify Transfer Listing Service. Consultation and Suggestion Process, Fraud Reporting, are some of the least used services in the organization.

We did ask people, if they said they didn’t use ARIN Online, we asked them why don’t you use ARIN Online. And community members who do not use ARIN Online, many of them said they do not need it or they have little knowledge of what it has to offer.

Some of them said they didn’t know they could use ARIN Online. It was interesting to hear that.

So the vast majority of the community does not attend ARIN events. This is the consulting organization placing, when they say community, they mean the 699 people, community that filled out the survey. Of those 699 people, Public Policy and Members Meetings, remote, seven percent of them have attended our meetings remotely. Five percent had come in contact with us at ARIN on the Road events. Five percent at the PPCs at NANOG. Three percent have attended in person, of these 699 people, the Public Policy and Members Meeting.

The majority of the people who filled out this survey don’t come and participate at this Public Policy Meeting in person.

More of them do it remotely, or more of them have come across us at a NANOG or other events. This is very interesting information for us.

How have you come in contact with ARIN in the last 12 months? We’re very interested in knowing, how are you communicating with us? What are your contacts? Email, ARIN Online. People have requested resources are the main ways that people are interacting with us.

As you would expect, there’s less interaction inside the social media space and some of our more specific features or services that are out there, like the ACSP and very few people have participated on our Mailing Lists. And I have more information about Mailing Lists up here. I want to talk a little bit about that.

So five percent of them said that they participate, they have participated in the Policy Development Process in the last 12 months. Of the 699 people, five percent said yes, they had. 95 percent of them said no, I have not.

So we gave them some radio buttons to select. What’s the reason why. And we also let them select other and describe some reasons why they don’t do that. We have some of the other in another slide here. But 26 percent said: I don’t have the time to participate in the Policy Development Process.

23 percent said: I’m happy with ARIN policy, do not see a need to get involved in the process. 22 percent said: I don’t think I can have an impact on ARIN policy; I don’t have the resources to participate, 18 percent of the people selected that. And 13 percent said they didn’t have any interest in participating.

16 percent weren’t sure. I’ll talk more about that in a slide or two here. One of the questions we did ask about is during the first qualitative phase that the contractor did in the fourth quarter of last year, several people that were interviewed had talked about an interest in training services and want us to investigate that more. So we actually asked the question. We asked the question: Which of the following topics would you be interested in formal training provided by ARIN, please select all that apply. And we provided some options. And there was an “other”, people selected other. But we also provided a radio button, allowed them to select the option: ARIN should not provide formal training purposes.

Five percent of the people who responded to the survey indicated that ARIN should not provide formal training services.

The area where people were most interested in receiving training services from ARIN, if we were to provide those services, is in the area of using ARIN tools and services, IPv4 transfers, RPKI, use of ARIN Online, also IPv6 deployment is in there. But if you group together use of ARIN Online tools and services, IPv4 transfers and use of ARIN Online, people are interested in receiving some more information from us or getting some training on how to actually use ARIN services. This is something that they’re interested in.

I don’t think it would be a surprise to anyone in the room today that people said that they need IPv6 deployment support or they need RPKI support, some of them. But we thought it was interesting that there was a very high interest in hearing more from us on how to actually use our services.

Back to the Mailing List. Our contractor said there’s certainly room for improvement on Mailing List satisfaction. Barely half of the users are satisfied with their ability to comment and participate using lists.

So we have all these lists listed here. And we asked about their satisfaction. We asked the people who said they did use the mailing list and we also asked the people who said they didn’t use the mailing list, we wanted to find out, if you don’t use mailing lists, why aren’t you satisfied; and if you do, why are you satisfied.

Mailing list users: 53 percent are satisfied, 41 percent are somewhat satisfied. Only 6 percent said they were dissatisfied. Nonusers of the list, 10 percent of those said they were dissatisfied. And they actually gave us some reasons and actually stated why it’s difficult for them, in their words, why it’s hard for them to participate.

Non-users of the mailing lists have low satisfaction largely due to low awareness of the lists. And users feel it is difficult to keep up. And that lists are for a selected group of insider members.

We heard this in the text responses quite a bit. The word “intimidating” was used several times in the responses to this. A lot of people said they’re not participating on the mailing list or actually posting to the mailing list because they feel intimidated by the knowledge of the other people that are on the list or the types of responses made to other people’s statements.

There was a group of people who said: I just didn’t know that I could participate on that mailing list. And that really says something. If you consider that we reached out not just to our core participating community to fill out the survey, but everyone who had conducted a transaction with us in the previous years.

There’s a population of people inside that space that took this survey that simply don’t understand that they can participate in this process. And that’s something that we need to be thinking about and we need to do something about.

So there were some demographics information. There’s more demographics information in the full report that you’ll see, but I just picked out some of them. Occupation wise, 46 percent of the people identified themselves as network engineers who took this survey.

26 percent said they’re in a management position. 17 percent, systems administrator. Then we had software developers, people in marketing. Attorney and legal services was one percent. Seven percent were other. One of the interesting things I found going through all these results there was a fairly large number of people from the healthcare industry that were actually participating in this survey.

And that’s not something that I expected. But when I went and I talked to other members of the ARIN staff, they said, yeah, we provide services to people in the healthcare industry, of course, and that it’s not uncommon that we would see somebody from that space.

So because this wasn’t a survey that was specific to IPv6, wasn’t specific to RPKI, we just slipped a question in there about RPKI and IPv6. Because if you do a survey on IPv6, who is going to take the survey on IPv6? People who are interested in IPv6.

So we thought it would be really interesting, where we had this sample group of people taking this survey, they didn’t know they were going to be answering a question about IPv6 or didn’t know they were answering a question about RPKI. And we asked them where they were.

So the question about RPKI was simply: Does your organization utilize RPKI? Six percent said we currently utilize it. 28 percent said we do not currently utilize RPKI but plan to in the future. 34 percent said we do not currently utilize RPKI and do not plan to in the future.

And not surprisingly, 32 percent of the people weren’t sure. They may not have even known really what RPKI is.

IPv6: Now more people are aware of what IPv6 is, of course. And with all the outreach that we’ve all done over the years, everyone in this room, not just the staff of the ARIN organization, but everyone on the Advisory Council and everyone in this room has talked IPv6 to people in the past several years, I’m sure.

So the question: What’s your organization’s current plan for IPv6 deployment? 24 percent said my organization has already deployed IPv6 in some manner. That’s awesome.

Seven percent said my organization has a formal plan to deploy IPv6 in some manner. 46 percent said my organization intends to deploy IPv6 in the future but does not have a formal plan. So they know they’re going to do it. They just don’t have a plan yet.

There’s some sort of trigger that they’re waiting for to put together this plan and actually get moving. Now, I’m not absolutely sure what that is, but it’s encouraging that this looks like a really big number to a lot of you, I’m sure, that only 17 percent said my organization has no plans to deploy IPv6.

If we hadn’t asked that question in a sampling like this five years ago, I think that number would have been significantly larger.

I’ve actually stood at outreach events with many of you in this room when we started aggressively talking to people about IPv4 depletion and IPv6 adoption. And just five years ago people were laughing at us or criticizing us for even being there talking about IPv6.

They thought it was ridiculous that we would even say anything to people about that because they didn’t think it was something that was ever going to happen. And here we are these several years later, 17 percent is still a big number, but only 17 percent of the people said they have no plan. And six percent of the people said they weren’t sure.

With that, you’ll have the full unedited report directly from our consulting organization posted to the ARIN website in the coming weeks for you all to go through and look at. I’m sure the text will be easier to read and see on your monitor on your laptop than it is up here.

But we look forward to providing that to you. And we’re happy to answer any questions you have about the survey process

Discussion

Vint Cerf: Question in the back already. Let’s take that one.

Bill Darte: Bill Darte on the Advisory Council. So I noted that you asked questions about these meetings. And you’ve got survey results. But we also survey the participants of these meetings after every meeting, and I wondered if you compared the two sets of responses to see whether they were consistent or not.

Richard Jimmerson: Haven’t done that yet. That’s a very good question. It’s certainly something that we will do. We just recently received the survey results. That would be a very interesting thing to look at, I agree.

Vint Cerf: Let me ask if there were any online questions.

Andrew Dul: Andrew Dul, ARIN AC. I have a question about the methodology with the gap analysis. I hadn’t seen that kind of survey style before.

My question is: Is there a natural tendency in those kind of questions for people to always rate the ideal higher than the organization actually performing? Because this may be a question you could ask to the people who did the survey, Rockbridge, I guess, whether they naturally see a gap in almost organization of 7 to 10 points, because people psychologically rate the ideal higher than whatever exists, even if whatever exists is perfect.

Richard Jimmerson: Right. We did ask that question. When they came in and gave us the final report, we did ask them that question, because we were curious. Because is a ten point gap good or bad or five point gap good or bad. We naturally asked them that question.

What they told us was that we were consistently rated a little bit higher when it comes to, the expectation was rated slightly higher than it typically is in other surveys they do. So they did want to note that to us.

But when it comes to the actual gap, they said you really want to concentrate hard on any gap that’s greater than ten points and aggressively go after that. And as it gets closer to five points, they thought that we would always see something like that.

We additionally asked them: What should we expect? If we aggressively went and tried to update our customer service practices to close these gaps, what should we expect in a year’s time when it comes to improvement. How quickly should we expect the gaps to close. Our answer was one to three percentage points per year.

Unless you do something that’s completely out of the ordinary or that’s extraordinary that would rapidly close the gap at a quicker rate is the answer that they provided to us.

Andrew Dul: I guess the other interesting thing about that methodology is you never saw in your survey: ARIN is the organization being rated higher than the expectation? And does that ever occur when you do this kind of analysis.

Richard Jimmerson. I don’t know. I didn’t ask that question and they didn’t say. The reason why they did it this way, by the way, is because they noted that we don’t have any natural competition inside the space, inside of our region where we would be conducting this survey.

So normally what they said they would do is they would rate an organization against others in the field or something like that. And since they couldn’t do that here, that’s why they chose to go with rating an excellent registry services organization versus the current performance of the ARIN organization.

Andrew Dul: I think that makes perfect sense. I applaud you guys for being very open and publishing it as is, because it’s good to see where improvement is needed and where we are doing well as an organization as well. So thank you.

Vint Cerf: John.

John Curran: I just want to say, I actually gave this information to the Board, and we discussed it this morning. And we are committed to using this as a benchmark to improve ARIN’s performance.

The fact that there are gaps means there’s targets of opportunity. So that’s a good thing. We’re very pleased to do it. And I am glad that I have Richard to manage the program. And it’s a very serious initiative.

Vint Cerf: I’d like to make one observation about this: It’s very helpful to have concrete examples of what would make things better, because just getting a measure saying I’m not happy and I would be happier if things were better without anything more concrete makes it a little hard.

Reminds me of the story of the lieutenant who asked the sergeant to bring him a rock. The sergeant brings him a rock. The lieutenant throws it away and says: That’s not it; bring me a rock. And he keeps going. Couldn’t figure out what kind of rock the lieutenant wants. So you guys need something better than just bring me a rock.

Milton Mueller: Milton Mueller. Just curious. You asked this question about if you had a competing registry service provider in your territory. What were you thinking?

Richard Jimmerson: There was some debate about that actually inside the organization when we asked that question. I’ll go back to the question, so we can repeat exactly what the question was to the community.

The question was: If you had the option to choose another registry service provider, how likely would you be to continue using ARIN’s services? You can see the response there all the way to the right. And that’s not a comfortable question to ask.

It certainly isn’t a comfortable question. But because people don’t have a choice, we thought it was important to ask that type of question. We thought it was fair to ask a question like that.

Milton Mueller: Those are good loyalty metrics. Again, I want to echo what Andrew said about, it’s great you threw all this information on the table and didn’t try to sugarcoat some of the things that were a little bit surprising. Good job. Thanks.

Vint Cerf: Martin. Almost got it right the first time.

Martin Hannigan: Beauty, brawn. Beauty, brawn.

Vint Cerf: No, bald and gray would be the two distinguishing factors.

Martin Hannigan: Yes, I agree with Milton. Thank you for not sugarcoating.

I guess I’ll be the fifth horseman and just ask the question: Did any legacy holders actually answer the competitive question.

John Curran: Remember, this survey was asked actually simultaneously to ARIN and NANOG members. So the people who answered the question are not just this room.

There was a lot of people at NANOG who don’t participate. If you look, you have people who identify themselves as members. You have people who identify them as having a direct assignment of resources but not a member. Those are highly likely to be legacy holders.

Martin Hannigan: Do you know what the response rate was contrasted from NANOG and ARIN.

John Curran: I do not. If you look at the numbers, we had more than 300 in both members and non-member address holders answer. Thank you, Richard.
(applause)

Vint Cerf: We’re four minutes ahead of schedule.

John Curran: I did not know how long that would take. We had a huge block of time. It was actually needed.

We are going to put the full Rockbridge report online, so you folks can pick that up. This is how we perform. You should need to see it.

We are now coming on the refreshment break. We’re going to take that. We have a half hour. We’ll be back here at 3:30 and pick up with the Draft Policy block, with two more policies, the last two of the day.

I’ll see you back here at 3:30.

ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]

John Curran: Okay. If people will come back in and get settled we’ll get started. We’re picking up with our policy considerations. And this one is Draft Policy ARIN 2014-6: Remove 7.1 [Maintaining IN-ADDRs]. This was ARIN Proposition 198 from January 2014. Rob Seastrom and Stacy Hughes, the shepherds. AC accepted it as Draft Policy in January 2014. It was presented at PPC at NANOG 60. And it is available in your guide and online.

It’s a work in progress. It has been posted to PPML and presented for community discussion. The Advisory Council needs your feedback: Is it good number policy? Is it fair and impartial? Is it technically sound and supported by the community? Should the AC continue to work on this or get rid of it.

I’m going to introduce Rob Seastrom to come up and give the AC presentation.

Robert Seastrom: Thank you, John. Okay. So situation within IN-ADDR.ARPA is that there’s no RFC that underlies this. It’s an arbitrary decision by ARIN technical staff. It doesn’t talk about IPv6.ARPA. The policy statement is remove Section 7.1. It may be the shortest policy statement ever, but there may be a tie in the next presentation.

So staff believes that removal of Section 7.1 would have no operational impact. There are a lot of things that ARIN does that are not codified in the NRPM. The NRPM, there’s sentiment that’s been expressed to me by several people. The NRPM ought to involve principally issues of how one shows that one is qualified to receive address space and justification. And the details of how to run Whois and IN-ADDR and things like that are either best left at an extremely high level, like saying ARIN shall do this and nothing further, or removed entirely.

Legal says no legal issues. So as I was saying, there’s, this is operational practice. It’s out of scope. So if this does belong in the NRPM, it would make sense to at least have a policy proposal that makes the changes so that it addresses IPv6.ARPA as well as IN-ADDR.ARPA.

Discussion

Vint Cerf: You’re right, it was brief. Well, are there any questions or comments or positions in the room here? We have one online, thank you.

Scott Leibrand: This is actually me speaking for myself. Scott Leibrand, ARIN AC in this case, also Limelight.

Vint Cerf: I didn’t know you were allowed to do that, Scott. Go ahead.

Scott Leibrand: Everyone else at the mic please speak first, and then,

(laughter)

Scott Leibrand: I’m not quite sure I understand this whole we’re not doing this for v6 as well. Because Section 6.5.6 says that ARIN delegates responsibility to manage reverse lookup zone corresponding to the IPv6 space, organizations should properly manage reverse lookup zone, et cetera, et cetera. There’s even more text around how to do this in v6 than there is about how to do it in v4 in 7.1.

Now, I don’t object to removing 7.1 because ARIN staff says it’s not, doesn’t change anything. They can still do their job.

But I’m concerned that if we’re looking at this as a legacy v4 only thing that there’s no equivalent for in v6, that we’re ignoring Section 6.5.6 which is on page 34 of your Discussion Guide.

Vint Cerf: Good point. Maybe everybody stopped reading at page 42.

Any other comments? Yes, John.

John Curran: So, Scott, given that, are you saying that you don’t support this policy and we should leave it as is or you think this policy should be revised to drop it from 7.1 and put the corresponding text in the v4 section of NRPM?

Scott Leibrand: I do not support this policy. I don’t really oppose it either. I don’t think it much matters whether we leave this text in or remove it. It’s not doing any harm. It’s not doing any good. I don’t care.

Vint Cerf: I think, if I may jump in, I think Scott is saying it’s inconsistent to take it out of the one portion of the document and leave implications for IPv6 in. Because if it was inappropriate for v4, then why is it appropriate for v6. Is that a fair statement?

Scott Leibrand: That is a minor point that I would make, but it’s not enough to make me oppose the policy.

Vint Cerf: Yes, please, microphone in front.

Andrew Dul: Andrew Dul, ARIN AC. I oppose this policy currently. While it doesn’t do much, I believe that reverse DNS is a vital function that ARIN performs for the community and, thus, should be recognized somewhere in the policy document.

Vint Cerf: Scott, do you want to respond to that?

Scott Leibrand: No, but I have a remote, though. Marla Azinger says she’s not comfortable with removing things from NRPM until ARIN creates an operational document and publishes it.

So this is me editorializing for context.

There have been other discussions around ARIN publishing its operational practices in various forms that have been referred to at previous meetings, which I think Marla’s talking about.

Vint Cerf: So I notice someone levitating at the back of the room there. Yes, please.

Leif Sawyer: Leif Sawyer, GCI. In 7.1 it does mention /16s as the cutoff. I’m assuming that’s a /16 in IPv4 and not a /16 in IPv6, in which case it would behoove us, if we were keeping this, to, as John says, bring us in line with IPv6.

Vint Cerf: That sounds like a very practical suggestion. One more comment.

David Huberman: David Huberman from Microsoft. I’m also the policy author. I want to be honest why I put this proposal in as well as the next one.

One of the criticisms of ARIN, and surprisingly it came up in, I think it came up in the survey, there’s a lot of legalese. There’s a lot of policy. We have a Discussion Guide, 46 or 50 or 60 pages or whatever.

The NRPM is too big, it’s too unclear, and it lacks conciseness. I would love to see us continue to make ARIN policy where the NRPM is readable by an engineer and a lawyer and his lawyer and talks about how you qualify or don’t qualify for requests from ARIN.

Everything else, Section 6 that Scott brings up, Section 6 is a nightmare. Section 6 has so much nonoperational and fluff text in there.

So being completely honest with you, I proposed this because it doesn’t need to be in the NRPM. It doesn’t help me decide do I get space or not. ARIN is never going to stop providing reverse DNS until the IETF tells them to. And that’s not even negotiable. John will stand in front of the server and protect it from the masses.

(laughter)

David Huberman: That’s why I proposed it, just trying to get a simpler and conciser NRPM.

Vint Cerf: I have a question if I’m allowed to ask one. Is it your belief that the reverse DNS is important or not?

David Huberman: It’s the single most important thing ARIN does to an operator. It’s the only thing that ARIN does that actually affects the minute-to-minute, second-to- second operations of the Internet.

Vint Cerf: So having it show up in the NRPM in some fashion has the benefit that if somebody resists using it you can point to that and say no, no, no, you have to help us with that, because,

David Huberman: Resistance using it.

Vint Cerf: No, I mean in providing the information that needs to go into it.

David Huberman: Well, the reverse the DNS system is an opt-in system.

I’m sorry. I don’t know what you mean, Mr. Chairman.

Vint Cerf: If you say it’s the single most important thing that ARIN does, then the presence of this reference to it in the NRPM has the benefit that if somebody doesn’t want to use it, could they not use this to say wait a minute, you really need to, it’s important? Bill.

Bill Woodcock: He didn’t say it was the single most important thing; he said it was the thing with minute-to-minute operational responsibility. The most important thing is unique address allocation.

Vint Cerf: Okay. Fair enough. I accept that.

David Huberman: The reverse DNS is an opt in thing? Operators only use it when they choose to populate delegation records in ARIN.

John Curran: If I could say a word. So ARIN doesn’t have a way, or you have not told us to, and I’m not sure we want to be told to enforce population reversals.

Robert Seastrom: That’s the next proposal.

John Curran: We do provide, we do provide reverse delegations on byte boundaries for v4. So if you’ve got a /24, we’ll delegate you that. If you’ve got a /20, you’ve got 16, 16 reverse zone delegations. If you’ve got a /16, we’ll delegate that. If you’ve got a /12, we’ll give you a whole bunch 16 reverse zone delegations at the 16 boundary. We provide IN.ADDR reverse zone delegation for the space that you are allocated.

Now, whether this needs to be in NRPM or not is up to the community. I don’t know. I will say the current text is interesting, because it does sort of say all ISPs receiving one or more distinct /16 blocks will be responsible for maintaining IN-ADDR.ARPA records for their respective customers. And for blocks smaller ARIN, can maintain the IN-ADDR.

It makes it appear as though if you’re a large ISP there’s this magic boundary. Unless there’s a way of enforcing it, that boundary is meaningless. It’s opt-in, either way, and we want to delegate the reverse to you, but it’s in all cases up to the ISP.

So we don’t, I guess what I’m saying is the current language implies that there’s this magic boundary at which an ISP is going to have to provide IN-ADDR service, and I don’t know how ARIN has any role in enforcing that. So it’s questionable whether this belongs in NRPM. I’m not sure what responsibility ARIN has here that you’re trying to document.

Vint Cerf: Was that in favor of its removal.

John Curran: We’ll follow whatever we can perceive the instructions from the community are. That’s actually one of the highest marks on the survey is policy adherence.

Vint Cerf: Yes, Scott.

Scott Leibrand: I have a comment from Kevin Otte: I don’t think it necessarily needs to be in a separate operational document, but an equivalent to 6.5.6 needs to be written for Section 4 IPv4 policy.

Vint Cerf: Robert, you’re getting mixed responses.

Robert Seastrom: I am. So maybe we can ask the room.

Vint Cerf: We can.

John Curran: What do you wish to ask the room? Do they wish to continue work.

Vint Cerf: Specifically you want to know whether, as opposed to whether we should take things out, we want to know whether we want to continue working on this.

Unless there’s an objection, I would like to find out whether the assembled body wants to continue work on this question. So tabulators are ready. Please raise your hands high if you want to continue or you want the AC to continue work on this question. Raise your hands if you want to continue work. Same question to the online community.

Please keep your hands up, how many people would like to stop working on this item. Raise your hand if you want the AC to stop working on this item. I can see two from here.

Okay. Could we have the results, please?

Aaron, while we’re waiting for the results, would you like to make a comment?

Aaron Hughes: It sounds like the message that I’m hearing is the request is really to clean up the NRPM and potentially there are some things that don’t necessarily belong in them and they may belong somewhere else.

So the questions that might be useful to poll are is there interest in continuing to clean up the NRPM to make it more succinct and understandable, and, secondly, is there another document or another place for the data that’s in there, somewhere it should live, for operational related data, rather than specifically going through each of these points.

John Curran: Can I approach the second half of that question? In other Regional Internet Registries, they have a more collaborative service approach. In some cases they have a services working group which sits down during meetings like this in a corner somewhere for a couple of hours and talks about what services should be offered and how they should be offered and policies that are applicable to that and they write that up as a registry document, not a policy manual, but a registry document.

If there’s interest in us doing that here, doing that with this community and the other half of this community that meets at NANOG, we can do a services working group approach, which is where you’d document ARIN shall delegate reverse services and similar.

I would be interested in people talking to me about that. I’ve had a few people raise it in the past. But I don’t know, this would be a great topic for one of the open mics today or tomorrow to bring up.

That is the second half of your question, Aaron. I don’t know about the first half.

Vint Cerf: I do have a response, Robert. There were 82 people in the room and 12 remote at the time; 94 total. 16 are in favor of continuing work on this topic and three against.

But you might also take as input the comment that Aaron made to modulate your thinking.

Aaron, are you asking for a poll now or should we let this be the choice of the AC committee?

Aaron Hughes: Certainly the AC is welcome to pose the question. I was just bringing it up as does it make more sense to go through each of these separately, as I just heard from David. It sounds like there’s going to be some more of these coming from 4.6. If the general intent is for cleanup, it would be good to have a sense what the membership thinks on that subject, if I were the AC.

Vint Cerf: I’m almost tempted to poll to find out if anybody wants me to ask that question.

Actually I would like to, I think it’s not an unreasonable question, John, to see whether or not there’s a desire to continue working on making more crisp and cleaning up these documents, so the NRPM in particular.

There’s a comment, no? Yes, there is a comment. Please go ahead.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I would love to propose a question along the lines of what John was suggesting, because just saying we want to clean up more without giving the AC a little bit of guidance on how to do so may not be all that fruitful.

So if there was a suggestion along the lines of how the AC should go about it, would be very helpful.

Vint Cerf: Thank you. I guess there’s one more comment. Yes, please.

John Springer: John Springer, Inland Telephone, ARIN AC. I am in favor of generalized cleanup of the NRPM.

I’m unpersuaded by the argument that we should not do so because some subject only has one instance in the NRPM, and that is in a useless location.

Vint Cerf: Okay. Yes, John.

John Curran: I think the question of cleaning up the NRPM is one that’s a valid question, but it’s hard for people to wrap their head around unless they know where some of the stuff in the NRPM is going to end up when they’re done.

So because just cleaning up the NRPM, particularly when you’re removing service related items, it’s like I’m cleaning it up, but where did it go?

So I’m not saying it’s not a good question, but I’d like to defer it possibly a couple of days and see if we can come up with some discussion on this and then revisit it maybe tomorrow at the close because there might be a more concrete proposal that would enable cleanup.

Vint Cerf: Fair enough, John. I’m happy to delay that question. It feels almost like an IETF design team needs to be put together to think about this.

Scott Leibrand: Comment from remote. Marla Azinger says she officially submitted a suggestion via the suggestion process that you create the operational practices document.

Vint Cerf: That’s one concrete example of the suggestion. So we will pass on asking the question yet, John, and turn this back over to you.

ARIN-2014-5: Remove 7.2 Lame Delegations

John Curran: I’d like to now introduce the final policy of the day that we’re going to be discussing, Draft Policy 2014-5: Remove 7.2 Lame Delegations. And this was initiated in January 2014 as ARIN Policy Proposal 197. The AC shepherds are Stacy Hughes and Rob Seastrom. The AC accepted it as Draft Policy in January and presented at the PPC at NANOG 60. The text is online and in your Discussion Guide.

It was posted to PPML and presented for community discussion. The Advisory Council as always needs your feedback on this work in progress. Is it good number policy, is it fair and impartial, is it technically sound, and is it supported by the community. Should the AC continue work on this or get rid of it.

The introduction will be done by Rob Seastrom. R.S., come on up.

Robert Seastrom: So I’ve been under the impression that we were going to present these in numerical order, so you’ll see some comments here that seem to be setups for 2014-6 or, more to the point, references back to the 2014-6, which I just gave.

So there’s a section in NRPM that talks about lame delegations in IN-ADDR.ARPA. However, we don’t actively enforce the lame delegations language or policy. And the same statements that referred to in the previous policy statement about we should be using the NRPM principally to determine people’s eligibility for number resources, likewise forcing people to properly run their networks after address space has been allocated to them, is sort of out of scope for ARIN.

There was a discussion regarding the last proposal where the question was, well, can we force people to do this? How important is this? And, you know, if you don’t want to run proper IN-ADDR.ARPA, you’re sort of the one who suffers from that.

So is this something that really ought to be in Whois? Or, I’m sorry, in the NRPM.

So here’s the second three-word policy statement of the day. Get rid of Section 7.2. Staff says this would cause no operational changes. The software issues that have caused the checking to be suspended are not as simple as you would think. There are edge cases where things could be working in a wave that is satisfactory and still appear to be lame.

Legal says there’s no legal issue brought up here.

So 7.2 codifies operational practice. Never been effectively implemented. But there’s one concern here that was not a concern with previous proposal, which was that here we have a section in the NRPM which we are actively and conspicuously ignoring.

And is that a bad thing to have for us, to set a precedent of having stuff in the NRPM which we’re just not adhering to.

So it is arguable that we should either fix the practice or fix the policy to bring one in line with the other.

Discussion or questions?

Discussion

John Curran: If this policy proposal is abandoned, ARIN staff will come back to the next meeting with a report on how we will resume lame delegation testing and suspension. We note that several years back, at the Dearborn meeting, we reported to the community that this was very problematic because of the potential impacting production service due to DNS suspension.

However, we haven’t picked that up. The community hasn’t asked us to pick that up. We consider this, at this point, if folks abandon this, we will come back with a proposal to bring operational practice back in line.

I do not know whether it’s preferable to not do this at all or to bring operational practice back, but I do agree alignment is necessary here.

Vint Cerf: The term “abandon” in this case is interesting, John. If people approve the proposal, we will abandon the practice, correct?

John Curran: If people approve this proposed policy, we will no longer, the language will be struck from the NRPM and we will not do lame delegation testing. If people abandon this policy proposal, then obviously they want us to come back and talk about how to resume lame delegation testing which was suspended some years back.

Robert Seastrom: The subtlety, if I can underline, is in the third paragraph, which is if we’re concentrating on this, it might be to the exception of other things that the community might rather have us concentrating on.

Vint Cerf: Are there comments?

David Huberman: David Huberman from Microsoft. Real quick request to the audience. There are a number of people in this audience who have root operations experience. If some of them would could come up and describe in their opinion how important lameness is in root operations, I think that would be of high value.

Vint Cerf: Good way to phrase it, importance of lameness.

Comment in the back.

Sandy Murphy: Sandy Murphy, SPARTA, oh, golly. Sandy Murphy PARSONS. Name change, sorry. This is me being my usual pedantic self. I recall in the discussion of the previous policy proposal about how this isn’t based on an RFC, and I did a quick search. I’m not sure there’s an RFC that defines lame delegation. Does anybody know?

I didn’t think so. Can you go back to like the first slide of this.

Robert Seastrom: That’s not the one you’re talking about.

Sandy Murphy: No.

Robert Seastrom: Just checking.

Sandy Murphy: ARIN, not an operational technical body, should relegate activities ARIN is designed to participate in. But in the previous discussion, we had a comment that the IN-ADDR portion of ARIN’s services is the single most day-to-day, minute-to-minute, second-to-second operational impact of stuff ARIN does.

I’m not certain whether that comment is intended to imply that ARIN should not be providing reverse DNS. That was one thing.

Then there was something in here. We don’t put text about how to operate Whois or RWhois or IRR in the NRPM, but I quickly noted that Section 3 on Directory Services has a section, for example, on distributed information server use requirements about distributed information service must be operational 24 hours a day, seven days a week, and acceptable use policies for the routing registry.

I think I agree, I think this is just another sign that this policy manual has been where members have, the only opportunity to say something about ARIN services, and there needs to be some other mechanism. Because if this is supposed to be policy about address allocation, as John said, someplace else for the text to go. It was important to somebody at some point.

Vint Cerf: Thank you. This sounds to me like there’s room for considering alternatives to NRPM as a place where some of these ideas get expressed.

Other comments? I have bad peripheral vision, I think.

Scott Leibrand: Two comments, one from Marla Azinger that she supports this policy proposal, this Draft Policy.

Separately, an individual who said his name earlier, but I’ll have to get back to it in a minute, said to answer Sally’s question RFC 1912 makes references as well as RFC 4697, AKA BCP 123. His name is Anthony Junk.

Vint Cerf: Comment from the back microphone.

Matt Pounsett: Matt Pounsett, Afilias. Just a couple points of information. The only definition of lame delegation that I’m aware of in the RFCs is actually in 1912. But that talks about the lameness of a delegation to a specific nameserver as opposed to the lameness of the entire delegation.

I could not come up with a reference quickly enough. There is a requirement in the DNS RFCs that a parent is responsible for the cleanliness of the DNS below it in the tree. There are a lot of registries that don’t do that work. But I don’t think it’s a bad thing to put the effort in, if we can figure out a way to afford it.

John Curran: Put the effort in to do what?

Matt Pounsett: To try and keep the DNS underneath ARIN’s level of responsibility in the tree clean.

John Curran: Meaning test.

Matt Pounsett: That means testing and withdrawing delegations for things that are clearly broken and causing operational problems for other people.

John Curran: Okay. There’s test, there’s report on the results of tests, and then there’s withdraw delegations. And you’re indicating you believe we should do all three?

Matt Pounsett: If we can figure out a way to afford it, yes.

John Curran: Withdraw delegations has some interesting implications, but if this policy is withdrawn, we will come back with a report on what we intend to do.

Vint Cerf: Other comments?

Let us imagine, for the sake of argument, that it is decided to adopt this policy and remove the text, it doesn’t mean that there couldn’t be continued discussion about ways to deal with an operational problem. So I hope we can take into account other solutions besides leaving the text in, as one possible outcome. John.

John Curran: Just to be clear. If this policy proposal advances, then we won’t do anything in this area and the community knows that lame delegations might exist and that that’s kind of the situation and it’s up to the community to decide what to do with that. If this policy statement is withdrawn, then it means we’ve got a paragraph that says we should do lame delegation testing. We’ll come up with a plan to do that. And that will involve testing periodically and talking about what we report on that.

And there will be enormous discussion before we go to the step of actually withdrawing a delegation that one of you puts into your nameservers because we’ve detected it’s not there.

Because that might be your nameserver that’s temporarily unreachable and now we’re permanently withdrawing your delegation to it. And you just need to think about it from the side of the affected party. We’ll have lots of discussions if we decide to continue with lame delegation testing.

Robert Seastrom: Mr. Chairman, if I may, I wanted to avoid making a comment directly since I’m a shepherd on this, but since the original author asked for someone with root experience to step forward and nobody really has, and as an AS 112 op, I’m going to pretend to be.

I believe that the lameness problem is only going to, it’s not going to affect the roots at all. And someone, if I’m completely nuts, can step up and say I’m completely nuts. But the problems related to that should accrue to the lowest point in the tree where it’s actually valid, which suggests to me that it’s ARIN’s nameservers that are taking the heat and they’re taking it right now.

Is that a reasonable assessment, Mark?

Mark Kosters: That’s a reasonable assessment. I ran a root server for 16 years, and this was not ever an issue.

Vint Cerf: Thank you, Robert. I think the time has come to find out whether we will adopt this or not. Or at least what the sense of the room is on this point. So let me ask our tabulators to prepare themselves.

If you vote in favor,

Scott Leibrand: Vint? We should probably check for remotes before we do that because there’s a time lag on the webcast, and they’re coming in right at the end quite frequently.

Vint Cerf: I’m sorry, please go ahead.

Scott Leibrand: Kevin Otte asks: If the policy advances, there’s nothing stopping the community from re-raising lame delegation testing in another capacity such as in the ops document that Marla proposes, correct?

Vint Cerf: That is correct, yes.

John Curran: That is correct.

Scott Leibrand: Thank you.

Vint Cerf: Any more queued up?

Scott Leibrand: No.

Vint Cerf: Thank you. So if you vote in favor of the proposal, we will remove the text regarding lame delegation testing from the NRPM, leaving open still the possibility of re-examining this in another way. If you vote against, then you will trigger a response from the ARIN staff to propose ways of doing lame testing and the potential for removal of the delegation if a lame server is detected.

So let’s begin by asking how many people would like to end this practice at least in the text of the NRPM. If you vote in favor, please raise your hand high. Keep it up.

You’re voting in favor of removing the text and terminating this practice for now, which hasn’t been practiced I guess for some time.

Those that are against the proposal, meaning you’d like to continue, reinitiate lame testing, testing for lame delegations? I see one hand up. Two.

John Curran: Nice and high. Last policy of the day. Put everything into it.

Vint Cerf: I see another up here.

John Curran: It makes a difference.

Vint Cerf: Got it all? Thank you. Let’s wait for the results.

As a present observer, it does feel, John, as if having more than one place to distinguish policy from operations feels like it’s a direction that’s worth going in, just as an opinion. Mixing the two together is awkward.
Thank you. The results of this are, with 89 in the room and 12 remote, 25 are in favor of removing the text from the NRPM and three are against. So you have important feedback there for next actions. John.

John Curran: Okay. We are done with policy, someone at the microphone.

John Springer: If I may, John Springer, Inland Telephone, ARIN AC. Just as a point of information or order, because this is just a Draft Policy, we’re not actually instantiating this as a thing. It’s just advice to the AC and we’re going to take it and decide whether or not to move it to recommended Draft Policy, and there will be another chance to discuss it and it will go to last call. So this is not a final action.

John Curran: That is correct.

Vint Cerf: That is correct.

John Curran: Very good. Yeah, things have to arrive here as a recommended draft for them to be adopted after the meeting. And this was not a recommended draft at the time.

Okay. So we’re going to now, we’re finished with our policies for today. We have a whole bunch tomorrow. But we’re going to move into some of the reports. I’m going to ask Richard Jimmerson to come up and give the ARIN Consultation and Suggestion Process Report.

ARIN Consultation And Suggestion Process Report

Richard Jimmerson: Thank you, John. Many of you here have already participated or are already aware we do have an ARIN consultation process. We have suggestions for the ARIN organization where you can actually go and submit that suggestion and have it documented and have it considered by people who are paying attention to these things and that are reviewing these.

It’s another input into the ARIN organization, and this is our opportunity to report to you what’s happened since the last time we’ve met at one of these meetings with the ARIN consultation suggestion process and what we’ve seen come in.

So here we are. We have six new suggestions that were submitted between the time of our last meeting and when we started the open consultation period here in the last two weeks. We opened the consultation period in the weeks leading up to the ARIN meeting and actually continues through the ARIN meeting.

But in addition to those six, one was submitted just at the same time or just after we had opened the open consultation period for comments. And that one was a suggestion submitted for term limits for the Advisory Council. And that’s currently open, and it’s there for people to discuss.

There’s been some exchange on the list about that as well as the six that I’m getting ready to describe here. I just wanted to call that one out because it’s there.

The open consultation period currently, it opened on March 28th of 2014 and it closes on April 29th of 2014. With that, we have a prioritization survey of these suggestions. What we’re asking is people to go in and prioritize what they see as things that we should work on if we were to take these suggestions and for work inside the ARIN organization.

So these are the six that are a part of the current open consultation. We have one that calls for the idea or the suggestion of sunsetting of RWhois support, actually bringing us to the thought of actually deprecating support for RWhois. So that’s currently open and that’s there for you to comment on if you’re interested in commenting on that. I’ll describe how to participate in that process and make that comment.

We have one on point of contact validation messaging destination. Basically what that one is asking is when there’s a point of contact validation, right now you get a message in your messaging center in ARIN Online, and basically what’s being asked under the suggestion is it goes to your email address instead of sitting in your ARIN Online messaging center. And that’s being asked under this suggestion. We have another one that’s related to POC validation. It’s a POC validation message removal upon validation asking immediately after I validate my point of contact have that immediately removed from my messaging center so that I don’t see it there any longer.

We have one to improve ARIN Online form timeout behavior. There have been some comments that time outs are happening. Not optimal for some folks, and there’s a suggestion related to that here.

And support HTTPS for Whois-RWS. That’s not currently supported. There’s a suggestion that you’ll be able to access Whois-RWS over HTTPS. That’s an active suggestion.

And the final one we have here is the ability to have RPKI ROAs with an origin of AS0.

And, by the way, that last one is something that we had already been looking at, and we also received a suggestion on that one.

The last time I gave this report I had several people come to me and say, well, one of the things you’re not telling us is how many people are responding to these. What kind of feedback are you getting on them? I may or may not be on the list. So we went ahead pulled down all the statistics for last year on these.

So there’s two points where you can actually provide some feedback for these suggestions. It initially comes in and it gets posted to the list, and perhaps there’s some exchange there. But when we do the open consultation around the time of the ARIN meetings, what we’re tracking here, last year responses to those, there weren’t any responses to those for ARIN 31 and 32.

However, people did go to the prioritization survey and complete that. They seem more interested in going in actually completing the survey and showing the ones that they had more interest in than others, and there was some participation there.

I would like to note that we have seen more participation in this when it comes to open consultation responses. There are two people in attendance at this meeting right now that have done it in the current phase, this first phase in 2014. So we’re already doing better than we were last year when it comes to feedback to the open consultations there. So thank you very much for that feedback.

And we do have a few people that filled out the survey so far; although, that is still open through the latter part of this month, if you would like to participate in that.

So this is how you do participate in that. There was an open consultation announcement that went out. You can find it on the front page of our website under Announcements. You can go there and check out all the things that are being asked for your feedback on.

We have a mailing list where this goes to, where you can actually comment on it. There was a message that went to the mailing list in the previous couple of weeks, and one of the people that responded, and they asked: How many people are on this mailing list? I don’t know how many people are on this mailing list.

And there was an answer sent to the mailing list. On the ARIN consult mailing list, there are 227 list members as of our response a few weeks ago to that email, and of those 227, 39 of them are from a Regional Internet Registry staff or the Advisory Council. That’s how many people we’ve actually got subscribed to that list that are participating on it.

The survey is there. Please participate in the survey. We’re always interested in hearing your feedback.

One thing I want to note, though, is we’re just talking about the six right now that have just happened since the last meeting. These are accumulating over time.

We have completed many of these ACSPs over time, and we’ve been able to make changes to our services or do development work that actually provides answers to the things that were suggested, but they’re continuing to build up. And the list grows over time.

What we’ve done to pair with this ACSP report at this time is to actually look at where we are right now when it comes to development work related to ACSPs and where we’re going in the near future with those and. Immediately following this update, Nate Davis will be giving a presentation on that.

John Curran: Richard, could I have the remote for a moment? Nate is going to give an update on what we’ve gotten accomplished out of the list, but here are the open ones right now.

Now, I need to point out something. When we come up with an idea that we think you folks want, we actually send it out for consultation. When you folks submit suggestions, it comes in and goes into this list.

But ARIN staff don’t run ISPs. So asking me which of these I should prioritize when making our plans for development is only one view. And it’s crucial that you folks give us feedback, in particular, that survey, that prioritization survey, when I have to go and build budgets, I want to see feedback from the community about which of these are important. If you’re not discussing it on the mailing list, that’s fine. Maybe you’re not on ARIN discuss, or ARIN Consult. That’s okay. But at least take the time to fill out the survey so that when we do do development, we’re doing the development that you want us to do.

That’s really helpful to us, because I can’t rely necessarily on the staff at ARIN to have a perspective of someone in the field running an actual ISP or service provider. Thank you.

Discussion

Scott Leibrand: One remote question from Marla. She wanted to know if there’s something that could be done to let someone know if their response to the call for comments was received. Maybe an auto response or something like that.

Vint Cerf: That’s probably a useful idea. Is that achievable?

John Curran: Can you ask – to the extent it’s on ARIN Consult, it was received. If that’s where she sent it.

Scott Leibrand: There’s discussion back and forth with Einar and a few other folks on the exact mechanism of that. So some follow-up.

John Curran: I’d like to invite Nate Davis up to give the Software Development Update, which is talking about what we accomplished. Come on up, Nate.

Software Development Update

Nate Davis: Thank you, John. Good afternoon, everybody. I’m going to talk a little bit about the software development update, things that we’ve done in the past, things that we’re planning to do in the future.

We’ve talked about this from time to time in the past. Sometimes we’ve had a little bit of a dynamic interaction regarding these things. Part of the reason I’m up here to do this is actually to open up the transparency a little bit more with the community regarding our efforts here.

So specifically what I’m going to cover is I’ll talk about things we’ve done since the last ARIN meeting; initiatives that we plan to deploy through the rest of 2014, it’s not completely comprehensive, but, for the most part, some of those things that we have on the plan; influences to the prioritization process, and that’s something that has led to lively discussions, particularly in the past; and then talk about specifically it was driving some of our prioritization; in addition to some of the comments that John had made earlier regarding the feedback we get on the surveys.

So Andy covered a few of these items earlier. I’ll go through a couple of them. But some of the things we’ve completed is, most significantly, I guess I would say, in the past six months, since the last ARIN meeting, is we migrated from Oracle to Postgres. This was a huge hurdle for the ARIN organization, moving from our legacy database into something that we could actually effectively manage and maintain.

I would also add that as an example of something that we’ve done for the community, we had a meeting registration suggestion that information that’s entered into our registration system for meetings is actually carried over from one meeting to the next so they don’t have to, folks like you don’t have to reenter all that content between meetings.

We’ve got that in place now. We actually completed that in the fall. And going forward, now that we’re beginning to build that database, all of you will not have to reenter that information whether it’s for a general meeting like this or a PPC or any other ARIN event.

We’ve also completed a feedback button. If you’ve noticed lately, if you’ve gone to ARIN Online or even to our static website, we have a couple of buttons on there in the top right and also on the bottom right where we collect your feedback.

If you have any suggestions on navigation, content on the screen, clarifications you think that we need to provide regarding use of the application, we’re looking forward to getting that from all of you.

We made a POC enhancement validation. And I’ll note if you see some of these in with an asterisk, these are related to your user suggestions that you’ve made through ACSP or otherwise.

POC validation enhancements. We made some enhancements to make it easier to respond to the POC validation messages that go out to the community asking for you to validate your POC. We have historically provided folks a method to go back through ARIN Online and validate those POCs.

We’ve also extended that now to include the fact that you can simply say correct or update, I forget what the actual language is in the email. But you can just respond to that in the email, and we’ll recognize that change as well.

And then payment process improvements. Depending on your thread of entry into actually paying ARIN your invoice, it was either very pretty or, quite frankly, a little ugly. So we have, we’ve made some improvements to that portion that was a little ugly, and hopefully that will work better for the community here when you’re paying your invoices.

So what are some of the things that we’re going to deploy through the rest of the year? So we’re looking at shared ticketing. Our authorization model, I guess I should say, is based on Web users. So people come in, initiate tickets or requests; they therefore are able to view those. Presently, yes.

Those were not visible from anybody else within the organization. We’re changing that model so that anybody associated with that organization through their Web user account can also see those tickets. So that’s a big change for the entire application and the way we look at access to information within ARIN Online.

We’re also signing ARIN’s forward DNS zones. Displaying agreements. We had a suggestion from a community member that says it would be nice to know simply if I have an RSA or LRSA in place, what the version of that is.

So we’re planning on displaying that information and making that available through ARIN Online.

We have some DNSSEC improvements that are forthcoming this year. And then as a part of shared ticketing, we’re actually putting shared ticketing in because it solves the problem or issue, if you will, with being able to share tickets among users in the community. And that likewise was something that’s been community suggested, as you see with the asterisk here.

But it also leads us to better handled transfers. Transfers are going to be automated this year. Probably, we had scheduled them for later in the year; we may move them up because of our current state of inventory of v4 address.

Regardless of that, we’re actually seeing increased transfers anyways. These are the most complicated and labor intensive requests that we handle within the organization, to some extent.

And then, lastly, we’ll continue improving user interface improvements throughout the application as well.

So something that we haven’t talked about is what are the influences that go into how ARIN prioritizes. And maybe beforehand we should have been a little bit more clear on that. Let’s take the opportunity to do that. We have, of course, legal and regulatory compliance that we have to meet with regards to our application, whether it’s financial, taxation, and so forth. So that’s one of the important things we have to comply with.

From time to time that draws on software development resources. Not as frequently as recent, as we’ve had for a number of years, which is occasionally you get these things called subpoenas in order to provide information subject to a court order. And from time to time we actually have to respond to those, and that takes away a DBA or a developer in order to pull that information.

We also have ratified policies that all of you agree to that the Board ratifies eventually, and we have to implement those. For the most part they don’t require engineering resources, but occasionally they do.

Of course the consultation and suggestions that Richard just reviewed.

We also have Board of Trustees’ initiatives such as the fee schedule that we completed last year. We have operating plan objectives to support the strategic plan that’s now available out on the website. And since we do develop software, occasionally we actually have a defect or we have to do maintenance or upgrades. And so that requires time as well.

The mailing ad hoc requests. So occasionally you’ll see on PPML, for example, somebody asked John or staff for some statistics regarding certain data that they want as they consider policy. For the majority of those, it’s actually Leslie’s team that provides that through RSV. But from time to time we have to pull a developer to help with that or database administrator to dive through the database and pull that data.

Some of the other influences as well to priorities are some of those implementations we’ve just had recently. We haven’t seen huge uptake from the feedback button that we’ve implemented, which is allowing anybody to provide us feedback through the application, but we expect that’s going to take off and provide us some valuable feedback regarding some of those things that we need to change in the application.

And then as Richard had shared earlier, we’ve gotten some feedback as well from the customer survey we need to take a look at. So those in total, it sort of lays out the environment of what influences the priorities when we look at how we allocate engineering resources. Specifically, the software development team.

So as a result of some of the past meetings and the lively discussion, we chatted a little bit with the Board about this. And their guidance was this, and I wanted to share this with everybody: Focus on community suggestion, community suggested recommendations that have the broadest appeal to the entire membership and the overall community. That’s the general Board guidance on how we prioritize work for the software engineering team.

I would also add in, parallel to this, the Board has actually asked us to dial down the work that we’re doing with RPKI to simply just do some maintenance work. And we’re in the process of doing that. We’ll have some releases coming out for remaining RPKI deliverables that we need to complete.

But that sort of lays out the landscape for those things that we’re going to do in 2014 and how the priorities influence those deliverables.

And that’s all I have.

Vint Cerf: Thank you very much. Any other questions or comments? Then I will wait patiently, Scott, in case anything shows up in delay.

Seeing nothing from the floor, nothing coming online, I think we thank you very much for your efforts.
(applause)

Closing Announcements and Adjournment

John Curran: Okay. We’re actually nicely ahead of schedule. And we’re going to move to the closing announcements and for you, folks, so you’ll have a little bit of time before the social tonight.

First I’d like to thank our sponsors ServerCentral and RCN Business. Thank you.
(applause)

John Curran: You don’t have to clap for them. Just turn off your Internet interface and stay off the net. Either clap or use it.

What else? Webcast provided by Google. Thank you, Google.
(applause)

John Curran: Tonight’s social is at The Field Museum, so buses are going to depart the hotel at 6:30, 6:45, and 7:00. They’re leaving not from the main entrance, they’re leaving from the Oak Street entrance, which means the ground floor, down the hall, go down to the ground floor and you go down the hallway, past the shops, and past the Chanel store and go out that exit. Remember, not the main entrance, downstairs, ground entrance, follow these directions.

Okay. Return service starts at 8:00 p.m., and buses will depart on the half hour. Last bus leaves the museum at 11:00 p.m., so keep that in mind.

Bring your badges. Badges are important. Must bring your badges. Bring your social badge, which is this one hiding inside. You have a badge in your badge. You also have a schedule in your badge and a few other useful things. Okay. So bring your social badge.

I’d like to thank our social sponsor, Level4 Hardware.

(applause)

John Curran: Excellent. Should have a great evening tonight. Reminders tomorrow: Breakfast at 8:00 a.m., meeting 9:00 a.m. The meeting materials are online for everyone.

And that’s it. I look forward to seeing everyone tonight at the social. Have a good evening.

Vint Cerf: One other comment. The Field Museum, if you haven’t been there, it’s really worth going to. Quite apart from whatever goodies you find at the social itself, it’s an amazing museum. So please enjoy yourselves.

We are adjourned for now until tomorrow morning.

Network Sponsors

Webcast Sponsor