Table of Contents
- Public Policy Meeting - Call to Order and Opening Announcements
- IPv6 IAB/IETF Activities Report
- Policy Implementation and Experience Report
- AC On-Docket Proposals Report
- Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
- Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
- Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers
- IANA Stewardship Transition Planning Process
- ARIN Board & Advisory Council Election Procedures and Candidate Speeches
- Software Development Update
- Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers
- Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification
- Draft Policy ARIN-2014-1: Out of Region Use
- Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update
- Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate
- Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments
- Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization
- Open Microphone
- Public Policy Meeting - Closing and Announcements
Public Policy Meeting - Call to Order and Opening Announcements
John Curran: I'd like to welcome everyone to Baltimore. I'm John Curran, President and CEO of ARIN, and welcome to our ARIN 34 meeting here. I'd like to call the meeting to order with some brief announcements, and we'll get started.
We have a very full agenda, a lot of good policy discussions. So first I want to introduce the Board of Trustees here at the ARIN meeting. That includes our Treasurer, Paul Andersen; Vint Cerf, our Chairman; myself, the President and CEO; Timothy Denton, out in the audience; our Secretary, Aaron Hughes - I see Aaron; Bill Sandiford and Bill Woodcock, also over there.
We also have in attendance our Advisory Council, including Chairman John Sweeting, Vice Chair Dan Alexander, and the rest of you stand up. See how easy that is.
The Advisory Council is the one that shapes the Policy Development Process. They're the ones who actually work with the community to help get the policy proposals through the process, make edits as required, and we couldn't live without them. Your policy process is led by this team.
We also have the NRO Number Council. The NRO Number Council, three representatives from the region, and these three representatives work with their counterparts from the four other regions in order to work on global policy within the ICANN structure.
And so we have Ron da Silva; Louie Lee, who is the chair of the NRO Number Council - what you also know as the ASO AC; and Jason Schiller.
We have quite a few RIR colleagues here from AFRINIC. We have Ernest and Mukom. There you are. From LACNIC, Gianina and Diego. Very good. From RIPE we have Nigel - I didn't see you, Nigel - Kaveh, Ingrid, Andrew, Axel, and Paul Rendek. From APNIC, Mr. Geoff Huston, Siena, and Pablo. Very good.
The management team of ARIN is here. Myself, obviously; Nate Davis, our COO; Cathy Handley, our Executive Director of Government Affairs; Richard Jimmerson, our CIO; Erin Alligood, HR & Administration; Susan Hamlin who runs the meeting. Thank you, Susan, for putting this together. A little bit of applause for Susan. Without her we would not have these wonderful meetings. Mark Kosters, who runs engineering. Mark, hiding in the back. Leslie Nobile, who runs the Registration Services department. And Val Winkelman, who handles FSD, our financial people.
We also have here the ARIN 34 Fellowship recipients. And so the Fellowship provides them with sponsorship to the meeting and travels so they can come, get information about ARIN, bring it back to their region. From Canada we have Adam Thompson. Adam, are you here? Very nice. Thank you. And Bill Darte is the mentor for Adam. From the US, Terry Hoke from Sierra Tel Internet. And Tina is the mentor. And then also from the US, George Lyle. And Owen is George's mentor. We don't have a Caribbean person. Sometimes the logistics of getting to an ARIN meeting can be interesting, including permits, passports, et cetera. Such is.
Postel Network Operations Scholar, working with NANOG, we jointly do the Postel Network Operations Scholar. Mukom from AFRINIC is our Network Operations Scholar. Kevin Blumberg is his mentor.
NANOG has an Operator of Tomorrow program. Carlos Watson is the recipient this time. He should be here somewhere. And Operator of Tomorrow, Ayodeji, with Scott Leibrand as his mentor, also here.
I'd like to welcome all the first timers. We have first timers. They met the staff and some of the representatives at the breakfast this morning. And we now have a prize drawing for all the first timers.
Mr. Sweeting, if you could pass me the tray. If I could have Owen DeLong. Yes, Owen. It's always Owen. Owen, you sit on the aisle so it's easy to pick you. If you will draw from the First Timers' Breakfast survey. This person will get a USB external battery pack. Very nice. Thank you, Owen. And the winner is: Bayani Lara. Bayani, are you here? Yes, very good. Find me afterwards. We'll get you your battery pack. Thank you for filling out your survey.
John Curran: Okay. So we now will welcome the remote participants. People should remember it's not just this room; it's the people out in the audience who are attending remotely. They have a webcast, live transcript. They download the same meeting materials. They can participate in the show of hands and ask questions through the chat room.
Wi Fi info. There's a few Wi Fi networks out there. Choose the one you like, nanog arin psk, WPK2. We have a five gigahertz one. We have an enterprise one with an 8021 certificate. The passwords for most of these are nanognanog. The username, if you have one that has a username/password combination, is nanog62.
If you have any questions, you can send firstname.lastname@example.org. We share the infrastructure since we're all meeting together. It saves us a whole lot of time.
Attendance stats. We have 187 attendees from the U.S.; eight from Canada; 18 remote participants registered; and 30 from outside the ARIN region.
I'd like to thank our sponsors. Network sponsor, Comcast. Thank you.
John Curran: Webcast sponsor, Google.
John Curran: And ServerHub and Eonix for the break sponsor for today. At this point I think Tony is supposed to come up. Tony up now, thanking our sponsor. Tony, come on up.
I have to do an intro for Tony, which is pretty easy. Tony worked for BBN/GTE Internetworking actually under me long ago. Went on to Genuity and Level 3. And 2005 he went on to Comcast. He's a Distinguished Engineer there. And he's representing our sponsor, Comcast. So I'll turn it over to Tony. Tony, thank you.
Tony Tauber: Thanks a lot. Welcome, everyone, to Baltimore. And thinking about - reflecting on what it took to get the network in here today, about six and a half years ago we provided connectivity and sponsorship for an IETF meeting. V4 and v6, had to talk to a guy to talk to a guy to get fiber linked up across the city, get v6 into the metro network, get interconnection, v6 going.
A lot of work. Very complicated. And since then we've done a number of different conferences that have been part of - and this one's just super easy. BGP, v4, v6, I don't even have to get involved. I just tell them the hotel's here. Do you have fiber into it? We've got fiber all over the place.
It's getting easier, which is good news. And we're very happy to do it. So thanks a lot.
John Curran: Wonderful. We have a couple of things to remind you of. ARIN T-shirts. Turn in your ticket in the afternoon break and get your ARIN T-shirt. Rules and reminders. The chair will moderate the discussions of Draft Policy so everyone can speak and be heard. State your name and affiliation clearly each time you're at the mic. Comply with the courtesies that are in your program guide. You have a Discussion Guide. You can find the rules and courtesies in the guide.
Today's agenda is fairly full. We have IPv6, IAB/IETF Activities Report. We have a Policy Implementation and Experience Report. We have the AC On-Docket Proposals Report. We have an IANA Stewardship Transition Planning Process discussion. We have Board and AC election procedures and - election and candidate speeches. We have software development update.
In addition, we have a large number of policies to discuss, including Draft Policy ARIN 2014-9 - Recommended Draft Policy 2014-9 - and ARIN Draft Policies 2014-6, -15, -14, -20, -1, -16, 2014-17, 2014-18, and 2014-19. We have a very full day. Okay. So we're going to be moving most expeditiously. Tonight's social at the Baltimore Museum of Industry. Buffet dinner. Open bar. Walk the museum. Buses will leave at 8:30, 8:45, and 7:00. Shuttles will start coming back at 8 p.m. Bring your name badge. Very important. Okay. At the head table, same people as I said before: John Sweeting, our AC Chair; ARIN Chair Vint Cerf; Paul Alexander - sorry. I'm blurring people together - Paul Andersen; Daniel Alexander; Andrew Dul. It's amazing. I can have their names in front of me and I still can't remember it. Let's move right ahead. I'll ask Cathy Aronson to come up and give the IPv6 IAB/IETF Activities Report.
IPv6 IAB/IETF Activities Report
Cathy Aronson: I guess we're behind schedule. Super awesome. This guy was from my yard. I just feel the need to throw that in to make everybody jealous. If you can't see them - they're really hard to see. I was just sitting on my porch. Anyway, this is my little disclaimer. Not an official report. It's only really what I care to report. So there's a lot of stuff that goes on that you won't know about, but that's okay. I subscribe to the attendees list simply so I can make this slide. This is my all time favorite question on the IETF attendees list. Are you ready? There it is.
Cathy Aronson: I couldn't believe. It was super awesome. Yeah. Wow. Google is really good. Somebody should try it.
Cathy Aronson: Anyway, that's the only reason I'm on that list, hundreds of messages, just for that. Some highlights. This is pretty cool. I blogged about it, but ARIN wouldn't publish it because somebody else was blogging about it. Comcast is 100 percent IPv6. Super cool. If you want to know more about it, I put the link in the slides. I don't know if somebody else was going to talk about it. Tough. I was first. I went to the engineering planning group which is a bunch of operators talk about operational stuff, and most of the IETF doesn't know that they exist. So we talked about extension headers, and basically the conclusion of that was that they get filtered and maybe we shouldn't use them. Geoff gave a good presentation about DNSSEC. And some of the numbers are kind of disappointing. Like it takes a long time to authenticate. And there's some stats here. There's 11 percent that do it now. And 20 percent validating can't resolve in half a second. So some of these things need to get faster. Not really sure what the answer to that is. But his presentation is online if you're interested.
I don't know why it animates like this. This is really cool. So George Michaelson did this whole thing about Teredo, and he looked at Teredo traffic, which is a transition mechanism between v4 and v6, and he found that Microsoft did exactly what they said they were going to do. They turned it off. And there's like this graph where like it just completely went away, which I thought was pretty cool. There's some tunnels still around, but they don't actually complete. He has some recommendations. If you're serving tunnel, stop. If you're creating zombie tunnel, stop. That was pretty interesting that somebody did what they said they were going to do and then somebody saw it in their research. Was pretty cool.
Let's see. There's a new IPv6 toolkit. There's a lot of new little tools you can get to use on your network. So that's worth looking at.
Let's see. The IRTF open meeting. I'll talk about it in a minute. The technical plenary was really not super exciting, and this time at the upcoming one there isn't going to be a technical plenary - or there's not going to be anything technical at the technical plenary. I'm not exactly sure. There's an Internet mapping tool. Now I've heard boomerang routing, trombone routing. There's a lot of new terms for like your traffic goes through another country and comes back to get across the street. And they're starting to look at the Internet in terms of like all the traffic goes through these central locations and how easy is it for the NSA to actually look at all the traffic. It's pretty darned easy.
And they're building an - NSA is building a big datacenter in Utah that's supposed to be like gathering all your traffic, which makes everyone feel super warm and fuzzy. So you can take a look at that. The ixmaps.ca is pretty interesting. So there was some discussion about keeping traffic local. A lot of countries now are really keen on that if their traffic goes through the US, the NSA is going to look at it. So a lot of it is negotiating with people in different areas to have exchanges to keep traffic local. And the CAIDA folks are starting to do some traffic analysis, just like RIPE does, where you get a little gismo and they map the world and see where traffic's going. So if you're interested in that, you can look on their website. I went to the Internet Society Briefing Panel. And there's some slides up online about that. We're so behind schedule I'm not going to belabor it. But just what - it's been ten years, what are the problems that exist on the Internet and those sorts of things.
Let's see. Yeah. So there's a new research group for information centric networking. I've talked about it before. Lisa Jing and others have been working on it for a while, and now the Internet Research Task Force is starting to look at those problems. If you've never heard a talk by Van Jacobson, when I was doing some research for this presentation, I came across this talk that he gave about ICN. And it's really good. Like if you're really interested in what it's all about, his talks, he takes really complicated things and makes them so that pretty much anybody can understand them. I just love it. Softwire is the group where everything gets tunneled and everything else, lots and lots of tunnels, v6 and v4, v4 and v6, and there's endless number of drafts in there. I'm not sure if any of them are going to win. And they're working on MIBs for that so maybe you can manage the tunnels at some point.
In v6 Ops, we're arguing about - what are we arguing about? Oh, there's some conflicts with DHCPv6 and and state-less auto-configuration, what happens if you have them both running at the same time, who wins, what if you get two addresses. I'm not sure if these problems actually exist in the real world, but people are thinking about them. Also things with what happens when you roam in v6, seems like people are discovering some problems with that.
And the UAL situation. So - there's some folks in Japan that actually have v6 networks and they're v6 only networks. And they do a lot of really interesting presentations about what's actually happening in their network. So there's still a lot of things that don't do v6, like Skype. And one of the people said that your Android won't come up unless you have a v4 address, and then somebody else said his did.
So I don't know. But these are some of the problems that they've seen in Japan with their v6 only network and trying to get v4 and v6 to both work. Which is sort of the opposite of what we all expected; that everybody would have a v4 network and you're just trying to get v6 to work over your v4 network but they're just the opposite. They actually have v6 only networks.
Let's see. Also like how do you choose the right prefix. Same old multi-homing problem. If you have ULA you may or may not always be connected to the Internet so maybe you need to have a public address. Seems like there's enough address space; everyone should just use public addresses. But that's just me. IPv6 multicast uses a lot of battery because it's chatty.
Let's see. Autonomic networks. This is my favorite new pet peeve. Self configuring, self optimizing, self healing, self protecting, self managing networks. Awesome. They're starting to say that routing protocols are autonomic, like it just magically figures out its neighbors and stuff. But I still remember having to configure that stuff.
So I'm not sure how it automatically configures itself because it doesn't. It doesn't automatically enter the pages. That was the comment that was made up here. Somebody will have to manage it. I'm not sure how that's going to work. And then for the IP Flow Export stuff, they're looking at different ways to couple space and time and relate service quality and stuff with that in the research group. So there is a lot going on with autonomic networks. I'm not really sure the fascination, but now there was also a BoF to talk about autonomic networks. And this is the goal of the BoF. So if you're interested, I don't know, we'll see if it goes anywhere. I can't imagine a network that no one manages. But maybe I'm just one of those operators who doesn't understand, because that's what they told me.
Speaking of that, a bunch of us were talking - I'm just going to divert from the slides for a minute. A bunch of us were talking the other night about getting more operations folks involved in the IETF, and I was thinking that we would have a little impromptu table topic today at lunch. So if you sit at my table, that's probably what we're going to talk about, how we get more operations folks involved in the IETF. I don't know. Or we'll talk about something fun.
Anyway, these are some quotes from the UCAN BoF. Again I'm an operator. I just don't understand. Let's see. And there's some drafts that they're working on.
So I'm not going to go into this too much, but this is basically the IP over glossy latency stuff like machine floor stuff and automatic assembly line stuff.
Anyway, the thing that was interesting is that we had an all time IETF tradition of a whole bunch of people with their implementations coming together and plugging them all together and making them work, which was really cool.
And there's some information about what worked and what didn't work, and who had implementations that interoperated and stuff, which like we're running code, which is what the IETF used to be known for.
So it's kind of neat. So let's see. Yeah, so in the operations area, Chris Grundemann will be at our lunch topic table, I hope, because he's really involved in trying to get operations people involved in the IETF. And that's what they're working on, these guys. There's a link.
Let's see. So delay tolerant networks. I hadn't really thought about this until they were presenting it, but you know like something really far down at the bottom of the ocean, there's a lot of delay there. Like I've always thought about it and like the planets and stuff but I never thought about like a rover underneath like a couple of miles down or whatever.
So there was a BoF to talk about how this would be done, and there was protocols being written and all sorts of things.
Oh. So the Postel Award winner, whose name escapes me right now - but he gave a talk. The Postel Award winner doesn't usually give a talk, but he gave a talk, and he like single handedly brought the Internet to Nepal. There's pictures of him like on cell towers and he finagled equipment out of people in rooms like this. It's so cool. The work he did is just amazing.
And then during the plenary - actually something we should try here - maybe not, I don't know - but they took an Etherpad and they decided they wouldn't have queues at the microphone; they would just have an Etherpad. When your name came up on the Etherpad, you should make your way to the microphone.
Somebody took over the Etherpad and started projecting things that perhaps they didn't intend. So we went back to queues and someone calling on people. But it would be kind of cool to not have to stand in line, right? So in theory. Maybe they'll figure it out. But it was like "Did you not think we were going to take this over?" was like the first comment on the Etherpad. It was pretty good.
We're probably going to talk some more about the government transition of all these functions. But the IETF is working on their piece of it, the protocol numbers and the stuff that they need from the IANA. They're talking about how they want to put their input into the process. But the whole time that we're having this working group, somebody's computer - Skype contacts were like scrolling on the screen and no one could figure out why. It was cool. And people in the room's faces were there. It was really cool.
So in v4 Sunsetting, they're talking about how you tell a device - when it comes online, how do you tell it, oh, you know, this is a v6 network. You can just turn your v4 off. So there's some work being done to figure out, you know, do you do it with v6 DHCP, do you do it with v4 DHCP. How do you tell the device, oh, don't do v4 anymore. Because they default, a lot of them. If you have both addresses, it defaults to v4. So this is some of the work that's going on there. Let's see. And I don't know why this isn't actually an RFC at this point. Like we should be starting really to push v6. Like standards should be v6. They should favor v6. We should just do enough v4 to support v4 to keep it like so it doesn't all break and it still interoperates. But it got presented again. Someday it will be an RFC, I hope. And there's a couple more drafts that are interesting at the bottom.
So the DHC group is celebrating its 25th anniversary. Awesome. That's kind of scary, actually. That's like right when I started doing networking. So there's some stuff going on in the Dynamic Host Configuration group. Let it never be said that I'm against doing worthless work. There's some good quotes. Here's some other drafts that are being worked on in there. DNSOP. There's a lot of work being done with the distribution of the root to try to make it so if you don't have access to the root, maybe you could still function so that recursive resolvers can still function even if they've lost their connection to the root for a while. And I think that's probably more important as we have more and more top level stuff. Other drafts on how to scale the root.
Yes, so I blogged about Lee Howard's draft. I hadn't come across it, and then I read it and I thought it was really great. There's all these pathologies with v6 and like what happens if somebody port scans your /48 and brings your whole network down and all that kind of stuff. Well, when you - you have your forward DNS and you have your reverse DNS and they're supposed to match, a lot of things expect them to match, they at least expect the reverse DNS to be populated.
If you populate a reverse DNS zone file for a /48, it takes something like, I don't know, 38 trillion years or something because it's so huge.
And I don't know, I hadn't really thought about that. But it's something like if you do a thousand entries written a second, a /48 would take 38 trillion years. So we have to kind of figure out how to know like what addresses are being used and then how to make sure - or maybe we take away the requirement that the forward and reverse DNS match or that there is a reverse DNS. Not really sure how to solve the problem. But it's really an interesting read if you have a chance. Homenet. Still arguing about how many routing protocols in a home, what should the routing protocol be in the home. There's a lot of interesting - I just don't think I'm ever going to run IS IS or OSPF in my house. But I'm an operator, and I don't understand.
Rob Seastrom: Speak for yourself.
Cathy Aronson: I know RS will. Maybe like five of us - Owen - will totally have - and Jason - will all have routing protocols in their home. But, you know, ordinary folks, not so much. I mean, that just means you're extraordinary. That's all. That's good. Some more drafts that are going on in Homenet. Let's see. So I don't usually go to GRO, although I did present there a couple of years ago. So I'm trying to think of what I wanted to say about this. Network manners. Everybody is talking about routing security. There's a new routing manifesto about what you should do, what you shouldn't do. Maybe people should filter. That would be good. And then you can't black hole the Internet, that sort of stuff.
BGP route leaks is still a problem, and I guess the theory is that if everybody filtered them, we wouldn't need to do like routing security stuff, because the probability of everyone doing RPKI is lower than the probability of everyone doing route filtering. According to Geoff. It's true, I think.
Okay. So I'm going to end on this note. So how many geeks - these are complements of Paul Andersen. How many geeks does it take to configure a VT220 terminal to connect to the IETF network? Well, let's see. There's Joel and Warren. And there it is. Super awesome. And they had to - I don't know if you can see it. Is it here? It's here. There's where they spliced the cables. I have a picture somewhere of them with the little meter because it's the old cable and the new cable. It's pretty awesome.
It had an actual terminal in the terminal room for the first time in, what, I don't know, ten years or something. And then I had to go get it and schlep it down for Paul at the end of the day. Here's some of the links to get to the various things. I like the Daily Dose a lot. But anyway. And then if anybody has any questions. I love the camera in my cell phone. It just makes me so happy.
John Curran: Any questions for Cathy?
Vint Cerf: Comment, Cathy, I don't know how you do this, but in such a short amount of time to give us the sense of the entire scope of the IETF meeting is truly astonishing. You do this beautifully well.
The second thing about these self operating systems: I'm waiting for the self peeling potato.
Cathy Aronson: That would be cool. Owen.
Owen DeLong: So the DHCP SLAC stuff is a real world real problem, and the problem is that when the IETF designed these, they sort of specified some of the things abut how you choose one or the other, but they didn't really cover all of the cases of what happens when one thing answers one way and another thing answers a different way and how hosts are supposed to behave when they get conflicting information or how they should behave when the information they are getting changes. So all of the different implementations of hosts ended up implementing those things differently, not necessarily by design in all cases, versus just accidents of what the code happened to do and what order they happened to process things. So there's a lot of different behavior out there as a result under different circumstances, and I think the current effort is to document what currently happens and then think about what we should do for standards as to what should happen.
Cathy Aronson: I know that the - the folks in Japan, the WIDE group, they've done a lot of work with this because they actually have live networks that have these conflicts, but I didn't know whether they were seeing that particular problem. They've hacked the DNS to send back things to tell them. It's pretty interesting too -
Rob Seastrom: They've got a particularly interesting (indiscernible) -
Cathy Aronson: I don't know. We're not going to single out. Anyways, thanks, you guys.
John Curran: Next up on the schedule is Leslie Nobile coming up with the Policy Implementation and Experience Report. Come on up, Leslie.
Policy Implementation and Experience Report
Leslie Nobile: Good morning, everyone. I have a quick report on the policy experience that ARIN staff sees. This is the staff's chance to give feedback to the community on how the policies are currently working. So we review existing policies, and we look for things like ambiguous text or inconsistencies in the policy text, gaps, missing policy, and effectiveness - does it do what it's supposed to be doing.
We'll then identify areas where new or modified policy might be needed, and we bring this back to you all in these meetings. And we base it on operational experience. Obviously we work with these policies day in and day out. And we base it on customer feedback. Customers provide us a lot of feedback on how policies are working for them or not working for them. And we'll provide this feedback here in this forum, and we'll make recommendations when appropriate.
So we looked at three - actually we looked at two existing policies and one non existent policy that may be needed. So the first one is initial allocations to LIRs in IPv6. The second one is fulfilling unmet needs, and that is via the waiting list. And the policy that does not exist is temporary assignment policy. And we'll talk about each of these a little bit. NRPM 6.5.2, Initial Allocation of IPv6 to LIRs, the significant portion of the policy text is this: In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. Surprisingly enough, about 25 percent of all of the IPv6 allocations that ARIN issues are /36. So a full one quarter are going to these very, very small ISPs.
So we'll start with a question, and then I'll explain a little bit about what the situation is.
Should the IPv6 ISP policy move the minimum allocation size from a /36 to a /40 in order to accommodate very small ISPs who might fit into the extra extra small category for IPv6. Right now the minimum allocation size is a /36 for ISPs, but the extra extra small category for - fee category starts at a /40 and smaller. So there's no equivalent category with IPv4 and IPv6. So we see ISPs with /22s or less of IPv4 space coming to us and they are currently billed as XX small on the fee schedule. So there's no equivalent fee category. And then they come in and get a /36 and they jump up one fee category to extra small and they're paying $500 more per year in fees. And we get a lot of feedback on that.
People are not happy. They wonder why there's not an extra extra small ISP fee category. So this could be a policy fix or it could be perhaps a fee schedule fix. Another option would be the realignment of the IPv6 fee schedule to maybe move extra extra small category to a /36, which is what most of our smallest ISPs are getting right now. The second one is NRPM 184.108.40.206, Fulfilling Unmet Needs. This is the waiting list. Really the relevant section is at the very bottom. I think you all know when ARIN runs out of certain prefix sizes, organizations who qualify for address space can go on a waiting list. They have an option for waiting for the space to come back somehow, maybe it gets returned, or they can take a smaller allocation or assignment.
So the relevant section I will read is: Any requests met through a transfer will be considered fulfilled and removed from the waiting list.
This means if you are on the waiting list and you're waiting for a /20 and then you do either a merger and acquisition transfer or a specified transfer or an inter RIR transfer and you receive space from one of those transfers, you immediately get removed from the waiting list. So staff's question is should this policy actually apply to merger and acquisition transfers. Because what we see is the addresses that are transferred by 8.2 are typically already being utilized by the assets being transferred. They may not be 100 percent utilized, but they're certainly in use or else we wouldn't complete the transfer typically. So it's not quite the same. With 8.3 and 8.4, you're getting space for future use. With an 8.2 merger and acquisition transfer, the space is already in use. So you're not really gaining anything typically.
So the liberal reading of the text means that 8.2 transfers would also immediately get removed from the waiting list, if the transfer went through. So if this is not the desired outcome, we believe a policy proposal to make the text more explicit is needed.
And then the non policy. The question. Should there be a temporary assignment policy to accommodate conferences and meetings. So we have received requests for temporary address space over the years. Not many, but we have received them. Typically these requests would have been filled by upstream ISP space. That's almost always what they end up being. But with free pool depletion imminent, ISPs may not be able to fulfill these requests and instead will direct these customers to ARIN. We had a situation like this just a couple of months ago, where the org couldn't get upstream space, they came to ARIN, and we had no policy for him. So that's why this - why we put this into the experience report, because it certainly could be useful.
So we have a suggestion, a potential approach. Create a new policy that allows ORGs to obtain IPv4, IPv6, and ASNs for temporary use for events which require network connectivity for short periods of time.
And we would suggest something like reserve a small block, maybe a /20, for this purpose; review it as end user assignments for simplification; make the organization agree to return the space to ARIN within X amount of time - could be 14 days or 30 days or 45 days; and then require a documentation obviously that supports the request. And that's all I have.
John Curran: Okay. Questions. I see Owen reach the mic momentarily before Mr. Huberman. Go ahead, Owen.
Owen DeLong: Can we go back to the first one?
Leslie Nobile: Was it this?
Owen DeLong: Right. That one. So we put the /36 policy in place before the Board realigned the fee structure, hoping that the Board would create a small fee category that would allow people to get lower fees and do the right thing at /36.
And then the Board came out and said, well, not only are we going to create the smaller category at /36 and do that useful thing, but we're going to create this additional lower category that doesn't have policy behind it and - for purposes beyond understanding.
I don't think the right thing is for policy to keep chasing whatever random thing the Board does to the fee structure. I think the Board should recognize that we put the policy where we wanted it, and the community came to a pretty strong consensus around that particular policy and should do the right thing in adjusting the fee structure accordingly. Next one.
John Curran: I want to comment on that one thing. Tomorrow there's going to be a fee discussion. There's actually a document out on the ARIN Consult Mailing List. There was an announcement. It's also on the website. The Fee Structure Review Panel has done an assessment of six or seven different structures, one of which includes a realignment of the fee schedule. And so people should take an opportunity. I'll send a pointer to that again to PPML to read that document because tomorrow we're going to have a long discussion, and it is one of the items that they looked at.
Owen DeLong: Okay. So on this one I would like to suggest that your literal reading of the text is not actually correct. Any request met through a transfer. So if your 8.2 transfer doesn't include enough free pool to meet your request, then, no, it wasn't met by that transfer. Literal meaning. Policy not broken. Thank you very much. Next one. I think that's a great idea.
John Curran: In back, Mr. Huberman.
David Huberman: David Huberman of Microsoft. Good morning, everyone. It must be really early and I haven't had my coffee because I agreed with everything that Owen said.
David Huberman: Can you go to the first one, please. I'm going to be a little bit of a jerk for just a moment, but it's because I care. This is the fourth time I can remember this coming up with requests from the community through RSD to the Board to stop screwing up the fee schedule for small networks, for small organizations for IPv6. It is continuing to inhibit IPv6 registrations. So to the Board I would ask, please, get your stuff together. Stop screwing around with the fee model in such a way that you're disincentivizing very small organizations from getting IPv6. Please.
John Curran: Several ways to adjust that. So we're going to need to talk about that in the fee structure tomorrow so we know which way the community wants.
David Huberman: On the second one. So, Owen, I didn't understand it. I was going to ask Leslie to re explain it maybe in different terms or simpler terms. I don't understand the problem. So you're a small organization. You need a /19, which you qualify for. There's no /19s in the free pool. You put yourself on the waiting list for a 19. Can you explain what happens there that you're concerned about, please? I didn't understand.
Leslie Nobile: If you then come in and do a merger and acquisition transfer -
David Huberman: So just an example. What did you buy? You bought a company. And what did they have had? A /19? A /20?
Leslie Nobile: They had a /20. Although the need wasn't met. Any request met through a transfer will be considered fulfilled and removed. It could be interpreted in a number of ways. I mean, you could say, well, it's met. We're going to remove it. They did get a /20.
John Curran: So imagine a circumstance where your company is on the list for a 19. In the process, you find out, surprise, next weekend you're merging with another company and they have a 20. They also have assets, using that entire /20. An entire network. You merge. Now, because they're using the entire 20, do we say you didn't meet anything? Do we say even though it's already used, /20 of your /19 has been met, or do we say you're dropped from the list altogether?
David Huberman: That's complicated.
John Curran: That's the matter. And it's just a question of we don't have this in front of us right now but we could easily have one in the next few years. That's it.
David Huberman: Thank you for that explanation. Finally on the third. Jon Postel saw fit to give a whole /8 to a conference. And in my many years as hostmaster, there were many requests I had to turn down that were obviously legitimate.
I really like the staff idea of just a single /20 set aside. There are not that many conferences that come in at the same time. I think it's a really good idea. Good thinking. Thank you.
John Curran: FYI. I'm going to close the mics. If you're going to comment on this presentation, come up quickly. We also have an Open Mic session at the end of the day. Remote, go ahead.
Andrew Dul: Marla Azinger, Frontier Communications: I don't believe that whole removal policy should include 8.2 transfers be removed and on the temporary side use reservation. Isn't there another block like temporary assignment for research set aside? If there's some other kind of temporary pool, couldn't it just come from the same pool?
Leslie Nobile: I'll answer that. There was no block set aside for temporary research. There's an experimental allocation policy that allows you to get space, but there is no block set aside.
John Curran: Kevin. Thank you.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. If you could go to the last slide, the last idea. Great idea. Lousy in practice. We've said get rid of operational, and now ARIN's going to be the gatekeeper for operational decisions as to which conference, i.e., Spamming 101 conference, learn how to spam. Are you guys going to be making the operational decisions as to who gets IP space temporarily? I just think it sounds wonderful. But it's not going to fly. Maybe this is a great way for a company who provides management services for conferences to say I need space that will be used by a whole bunch of conferences over a given year. Let somebody else deal with it.
Brandon Ross: As a company that sometimes manages conferences, I'd be glad to do that. That's not what I stood up here to talk about. I did want to comment on the small, the extra small allocation policy issue. I will not be here tomorrow. So I wanted to make this point today. Sometimes there's question about whether this is a realistic situation for small holders, and it absolutely is. I have several customers that fit into this category. I just wanted to reinforce that for the community that, yes, there are organizations out there that the extra $500 or whatever it is for the larger allocation is a big problem and that is preventing them from deploying IPv6.
John Curran: Okay. Jason.
Jason Schiller: Jason Schiller, Google, ASO AC. Two comments. The first is with respect to the unmet need. The way I read it is the same way that Owen and David read it; that it's any requests that are met through a transfer will be considered fulfilled and removed. So the way I would interpret this to work is if I have a request in for a /19 and then I do an M&A acquisition of a company that has a /20, if the things that were in my request for the /19 to justify that request are still valid and still needing addresses, then I shouldn't be removed from the waiting list. And I think that's the way Owen read it and I think that's the way that David read it. I'm not sure what the complexity is here and what additional guidance ARIN staff needs to process it that way. Do you still think we'd need policy text here to help?
John Curran: Let me ask a question based on what you've said. So if an organization has - same hypothetical - /19, merging with another company that has 20, and the other company has lots of networks deployed and equipment but there's little bits of space unused, they're 70, 80 percent utilized on their 20, do we count all of those little pieces and revise your entry on the waiting list? Do we consider those blocks unrecoverable? How do you - does it remove some from the waiting list? Do we remove someone lower down based on the remnant that they now - you were qualified for a /19 but now you have some remnants from someone's 20? Are you now a 20 on the waiting list?
Jason Schiller: I think it's up to the individual on the waiting list to decide if they have a need for a /19 and they still want to wait for a /19, that's fine. If they think they can recover enough addresses from efficiencies due to the acquisition and they believe that they can meet half of their need from the acquisition space eventually after some renumbering and integration and they really would just wait for a 20 because they think that's going to come up sooner, I think it's fine for them to switch to a 20 and keep their place in line. It's fine for them to stay as a /19 if they still have need for a /19.
John Curran: My question would be: Should ARIN tell you you're no longer waiting for a /19 because we think you have unused space that you might be - and some aspect of your need has been fulfilled?
Jason Schiller: No, I don't think ARIN should.
John Curran: I think that would be helpful to be clearer in policy.
Jason Schiller: We need policy language for this.
John Curran: Or common understanding of how we implement this, yes.
Jason Schiller: The second point is with regard to the temporary space. I think it would be helpful to understand how much temporary space ARIN either has been asked for or has allocated or assigned over some window and how long that space has been in use. What is the largest temporary block you've assigned? How long was it used for? Is there a high level of concurrency? That would help for sizing.
John Curran: No way to obtain that, because when they say they want it, we say no. We don't go through the process of saying how much do you want us not to give you.
Jason Schiller: So they put in a request for an unknown amount of space for temporary use and you say no?
John Curran: They contact us and say can we get an address space for our conference. And we say no, that's temporary assignment, talk to your upstream. We don't have a form for the request for the policy that doesn't exist.
Jason Schiller: Do we have any record of who has asked for what conferences so we can go and ask them?
John Curran: Not in an algorithmically available manner.
Jason Schiller: What I'm trying to say is some data with some expectation of how much space we would need would be helpful.
Adam Thompson: Adam Thompson, Manitoba Internet Exchange. On the /36 size change, my experience is somewhat different than what Network Utility Force just reported. Working with a number of enterprises and small ISPs over the last while to get IPv6 allocation, the problem that I've been seeing isn't the fee structure; the problem I've been seeing is the way ARIN distinguishes between ISPs and end users. And we found that in the small ISP - in the small - emphasis on "small" - ISP end of things, the distinction between an ISP and an end user becomes irrelevant from ARIN's policy perspective. So the distinction between the two categories is the impediment to IPv6 deployment, not the fee.
John Curran: Good feedback. All right. Chris, you snuck in at the last one.
Chris Grundemann: Chris Grundemann, Internet Society. I think the temporary assignments to conferences seems like a really great idea, but we also have a ton of addresses they can use. They just need to use IPv6. Shouldn't be a problem.
John Curran: Okay. Thank you. Thank you, Leslie.
John Curran: At this point we'll have John Sweeting give the AC On Docket Proposals Report.
AC On-Docket Proposals Report
John Sweeting: Good morning, everyone. John Sweeting with the Advisory Council. Quick report here to try to help get us back a little bit more on track to give us more time for the policy discussions. So the ARIN Policy Development Process, it actually charges the member elected Advisory Council as the primary facilitators of the Policy Development Process. And so with that, the process is proposals are submitted, we work with the author to turn them into Draft Policies, and then we try to move them along through the process to get them to a good policy that will benefit the community. So we'll go more into that when we get into the policies themselves. On the docket today, we have one Recommended Draft Policy, which means that that Recommended Draft Policy can be sent to last call after this meeting, when the AC has our meeting tomorrow afternoon. We will discuss sending that policy to the last call based on the input we hear from you here today. So please share all your input with us.
We have nine draft policies that John ran through very quickly. We'll get more into them. Draft Policy means that we're looking for input on whether - how to make that into a really good Recommended Draft Policy that can then go to another meeting, go to last call and become policy, or whether it's really best just to stop working on them and abandon them. As far as the Policy Experience Report that Leslie just gave, there is a room set aside. Room 320 is available as a breakout room for policy discussion. So everybody that didn't get a chance to get to the mics or the people that did get a chance to get to the mics and want to discuss these policies, these issues in more depth, please come and find me or any AC member or Einar and we'll get that together and get into that room and have that discussion. Lunch topics. There's four of them, really the draft policies that we want to get a little more in depth discussion on, on post exhaustion policy simplification plus Cathy's ad hoc - I forgot what it was about, but she's going to have an ad hoc at her table. And that's it. And should be no questions, so I'm going to turn it back over to John.
Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
John Curran: We're going to move right ahead into the draft policy block. First one is Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements. I'm going to give the introduction, and then I'll have Heather Schiller come up and give the AC report.
Its origin was ARIN Policy Proposal 199 in January of this year. Heather Schiller and Scott Leibrand are the shepherds. It was presented at Public Policy Consultation at Nanog 60. It was accepted as a draft policy in March; presented at ARIN 33 and revised; presented again at the PPC at NANOG 61. AC advanced this to a Recommended Draft Policy in July. And its text is online and in your Discussion Guide. This proposal would revise NRPM 8.2 mergers and acquisitions by removing aggregation and reclamation of resources as methods to restore compliance with current policy. It makes sense given the retirement of the aggregation policy elsewhere. Removing the reclamation terminology from the policy may encourage more people to complete transfers because the reclamation aspect is no longer part of the policy.
The problem statement does not specify which version the reconciliation issue is between the most current versions of the RSA and LRSA. This does not pose any material legal issues. I'll now have Heather Schiller come up and do the AC presentation.
Heather Schiller: Good morning. I think they mentioned this. This is a Recommended Draft Policy. So potentially it will be the last meeting that you see this policy. And we're starting you out with an easy one for the morning. So I think we kind of ran through. The goal is to resolve a conflict between the RSA and the NRPM. The RSA states that ARIN can reclaim netblocks, and this is just to remove that. The statement from the NRPM - I'm sorry. The NRPM says that ARIN can reclaim netblocks. And this is to remove that statement so that it's in line with the existing RSA. The goal is to improve accuracy. Some folks think that the part giving ARIN permission to reclaim address space would prevent people from following through with the transfer. So this may or may not do that. And we're talking about two words, removing two words from the NRPM - "aggregate" and "reclaim." And it's really a very simple, straightforward change.
Questions? Comments? Partly what we're looking for is - I can understand like you're thinking it's two words; you might be inclined to not get up and say anything. But it would be very helpful for the AC to hear if you're in support of moving this policy forward as simple as it is. Questions or comments.
Leif Sawyer: Leif Sawyer, GCI Alaska, ARIN AC candidate. I'm in support of this proposal because it removes unnecessary and unenforceable language.
Dani Roisman: Dani Roisman with SoftLayer Technologies. I'm also in support of this policy. Thank you.
Marc Lindsey: Marc Lindsey with Avenue4. I do represent a series of clients that have been through this process, and this language has hung them up. So I appreciate it. In support of it. Many of the clients I represent would be supportive of it also.
Matt Petach: Matt Petach, Yahoo! I also support. Awesome.
Mike Burns: Mike Burns from IPTrading, also an Advisory Council candidate. I support this, but I call it the ARIN pestering proposal because I really don't know what it means to work with a resource holder to transfer resources. What does that mean? How long do they have, would you say, to transfer resources?
John Curran: At the point in time that they go through their request, we tell them when we satisfy their request they need to put a plan together to do that transfer and that we will check back with them. We recognize it can take months for them to do this, but we do check back.
Mike Burns: So it's an open ended timeframe.
John Curran: It's an open ended timeframe, but we require them to acknowledge they have a plan to address this. Now, their plan can be: I'll return you the extra resources. And we're quite happy with that and very efficient in how to handle that. But if they say "our plan is to transfer," then we agree that's their plan and then we say you need to go about doing that. But there's no requirement to check back at a certain time.
Mike Burns: And there's no pestering?
John Curran: So let's recognize that if you say during your request you're going to transfer, and then somehow later on you don't at all and it looks like you were fraudulent in your resource request, that would be bad. That could lead to something in full agreement with your RSA, nothing to do with lack of utilization, having to do with a fraudulent resource request.
Mike Burns: Granted. So the plan, then, would be subject to a claim of fraud if it was in fact fraudulent?
John Curran: You should probably look at the RSA very carefully about that, yes. If you were to actually make a resource request fraudulently, between NRPM 12 and the RSA, that does allow reclamation of a fraudulent request.
Mike Burns: I understand. My concern is that the plan for the transfer - is that part of the resource request?
John Curran: Absolutely.
Mike Burns: I do support this. Thanks.
David Huberman: David Huberman, Microsoft. I'm the policy author. I support it. I did want to note that ARIN staff I think does a really good job asking in this working with the resource holder to return transfer or reclaim. I think staff do a good job.
I just went through a ticket where they asked me: Hey, you have this block, this /20 that's unused. Can you return it? And I said: Yeah, sure. The problem with that, as well intended as it is, is that other people who are not as familiar with ARIN will read that as, oh, my gosh, they're trying to take away all my space and that's an inhibition to transfer. So fully support.
Heather Schiller: Comment from jabber.
Andrew Dul: Marla Azinger writes she's in support of this policy. Christoph Blecker from Disney Interactive also in support of this policy.
Heather Schiller: I'd like to ask if there is anyone who is not in support of - well, I guess we do that, but, I mean, if there's anyone who wants to speak against the policy, that would also be very helpful.
John Curran: Certainly if you want to speak against this policy proposal, you should find your way to the mics most expeditiously. Okay. I'm going to close the mics shortly for all comments. Closing in ten, five, three, two, one. The microphones are closed.
Thank you, Heather.
Vint Cerf: Now we have to determine what the opinion is of all this.
John Curran: We'll get our tabulation machine ready.
Vint Cerf: If you are voting in favor, you're voting in favor of the policy to make the changes that have been recommended. If you vote against it, of course, you leave the text as it was. So tabulators are ready. All those expressing support for this policy, please raise your hand and keep them up until we've completed the count. Hands high. Keep them up. Not allowed to put up two hands. Nobody did that. We've got to come up with a better way to do this. Can't we get an electronic RFID mobile Fu that does this?
John Curran: At one of the open microphones, I'll ask people to report on some of the work in other regions being done in that area.
Vint Cerf: Put your hands down. Those against this change, please raise your hand. Counting downward - four, three, two. That vote has ended. I see nobody against.
Will the vote counters complete their work and bring your results up, please. In the process of doing this, Mr. Seastrom will be next. Should be prepared to come to the podium.
John Curran: Busy doing it now.
Vint Cerf: I think I should put them in an envelope so I can dramatically open the envelope, and the winner is... This is for 2014-9. There are 161 people in the room plus seven remote, 168 total. In favor, 64. Total against, 0.
So that's the advice to the AC. Thank you very much for that.
John Curran: Okay. We don't actually do the introductions. Right. Very nice. Because this is a Draft Policy, the staff's not doing an introduction; we're just moving right into the AC presentation. I'll leave it to Rob Seastrom to do Draft Policy ARIN 2014 6: Remove NRPM Section 7.1.
Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
Rob Seastrom: So 2014 6 involves cleanup of the NRPM. It was submitted at the same time as 2014 5, which was also cleanup policy, which involved removing lame delegations. 2014 5 has moved along. 2014 6, however, has not. And the question is: Why hasn't it? The reason is that the feeling was that, yes, this is something that maybe shouldn't be in the NRPM, maybe ought to be covered by some other document, best practices document from ARIN, best practices document that was owned by the community and kept by ARIN, RFC, not sure. But the question was: What does the community think about moving this forward without having that document?
We have a commitment that, yes, it's okay to create that document or ARIN will create that document, and I'm sure it's being prioritized appropriately, but it's not been forthcoming to date. So the question is: Should we be getting rid of this now? Should we be waiting for such a document to exist? The text that exists in NRPM 7.1 involves maintaining IN ADDRs and reverse lookup, pretty much the same thing for IPv6.
John Curran: Just one point. For those who have the printed Discussion Guide, that only references the removal of 7.1. The actual policy proposal was updated and it involves removing both 7.1 and the next page, 6.5.6. Your Discussion Guide has only one paragraph being removed. It's both of these being removed.
Rob Seastrom: Thank you, John. I'd like to open the mics up for discussion. What do you think? Mr. Huberman.
David Huberman: David Huberman from Microsoft, also the policy author. I actually didn't include 6.5.6 in my policy. I did that on purpose. I was surprised yesterday and really wanted to think about why the AC included 6.5.6. If we could go back for a moment to 7.1 text. It makes actual operationally relevant statements. It talks about the distinction between blocks smaller than distinct /16s and distinct /16s. And it tells you what's going to actually happen in the DNS. 6.5.6, however, doesn't say that. It doesn't say that ARIN will only delegate on the nibble boundaries; that if you get a /45, ARIN will manage the individual - will delegate it at the /48 level so you have four /48s or whatever. It doesn't say anything like that.
6.5.6 - if you could switch to it, please - Owen made the point yesterday, which I really like, it talks more about hierarchy and it talks more about what you should do as an operator with your customers. It doesn't actually talk about how ARIN configures its zone files and what it delegates and what it doesn't. Long story short, I really don't want 6.5.6 to go away. It's not the end of the world, but I thought Owen made persuasive arguments to keep it in.
I want 7.1 gone, and I'll repeat what I've said in the past. This should have been RFC'd. This should have been RFC'd a long time ago. Right now we have different NIRs in other regions not following this practice. And when you have distinct /16s, they're actually delegating /24s to you, which is really messy if you don't know they're not going to do that.
Rob Seastrom: Front microphone.
Adam Thompson: Adam Thompson again. I agree that the policy as written is highly suboptimal. On the other hand, I would argue against its complete removal barring the insertion of some sort of better text to replace it, because right now this is just about the only stick I have to make my clients do IN ADDR mapping at all.
Rob Seastrom: Thank you. Remote participant.
Andrew Dul: Marla Azinger writes: Could staff clarify what this means, please? Are you saying that when I get a new allocation for a /16 or larger, I will no longer be able to go into my ARIN account and manage my new subnets DNS by adding my nameservers to that record?
John Curran: Actually, no practice in existing services are intended by this change. This is entirely removing text that specifies what - if you look at 7.1, it actually places an obligation on the organization, not ARIN. And we didn't know whether or not that was appropriate in Number Resource Management Policy. Could you go to 7.1 really quick. All ISPs receiving one or more distinct /16s will be responsible for maintaining domain records for their respective customers. It's an obligation to the ISPs.
The second part of it is a statement of what ARIN would do. So I just wanted to point out we're not changing any operational practice, but the question is whether or not you want obligations like this in NRPM or not.
Rob Seastrom: I might add there's extremely confusing text as far as exactly what ARIN would do, which Mark Kosters clarified for us what ARIN does, which is what we all thought it would do.
If we agreed that we wanted this sort of obligation in the NRPM, we could profitably clean it up a lot. Center microphone.
Matt Pounsett: Matt Pounsett, Rightside Group. Any DNS operator that delegates zones out to other operators has a responsibility to make sure that the child zones are answered. So I think it's totally appropriate that ARIN have some sort of policy text that requires that. So I can't support removing any of this, but - or all of it, rather, but I would support maybe a simplification or rewrite that makes it clear exactly what's required versus what other operational stuff should be done.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I have a question because we just had a policy related to the RSA/LRSA and removing out text that was inconsistent between what really is the authoritative document, which is the RSA. So if you can go to the 6.5.6. Is ARIN in the RSA requiring an organization to deal with an organization; i.e., this here is putting an onus on the ISP to then go out contractually, potentially, and have their customer deal with reverse? Does that fit into the RSA?
John Curran: Presently in the RSA there are no such obligations.
Kevin Blumberg: That text, as far as the RSA is concerned, would be a no op?
John Curran: ARIN's ability to enforce this duty to the ISP is quite questionable. Okay. I don't have an RSA mechanism, and I would - I do not believe this community wants us to go revoke resource blocks simply for lack of delegation records. But if that's what's the intent, I need much clearer policy.
Kevin Blumberg: I support this policy.
Rob Seastrom: Center rear microphone all the way in the back.
Mike Joseph: Mike Joseph, Google. I generally support this policy, yet I continue to lament the lack of an ARIN services document. I know previously John has stated said that he will either write one or we will write one. How is that going?
John Curran: So ARIN's going to - we're going to put all the services - make a statement on the Web page that says here's the ARIN services. When you see ARIN services, here's what's constituted in those.
And then the question will be whether or not that remains something that just sits on the website or whether or not at some point the community wants to take ownership of that document. That's a community Board discussion. We'll have a little bit more tomorrow.
Brian Johnson: Brian Johnson, DRN. The 6.5.6 policy is under IPv6, correct?
Rob Seastrom: Yes. Section 4 is IPv6; Section 6 is IPv6.
Brian Johnson: So the 6.5.6 policy here doesn't appear to me to obligate you to do anything; it just says it's your responsibility now. And operationally your responsibility is to the community to some extent. So this doesn't appear to tell me "You have to do this, otherwise." It just says "It's now your responsibility. You deal with it." So I would suggest that 6.5.6, if you took this and made it not IPv6 specific, took the specific address family references out, and replace 7.1 with this and removed this from the 6 policy, you'd be able to accomplish it for both address ranges.
Rob Seastrom: Thank you. Front center microphone.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. If we took 6.5.6 out of the proposal, I could tolerate it. But with 6.5.6 being removed as well, I think this is a very bad idea. To show what a mess the IPv4 part is, Section 4 of the manual deals with IPv4, and yet the IPv4 DNS thing we're talking about is in Section 7. So that's been a mess for a very long time. And I'm fine with removing section 7.1. I'm almost past the point of caring what happens to v4 for the most part. It's over. We should move on with v6. However, this is the one stick which end users have by which they can beat their ISPs about the head and shoulder as necessary to get their reverse zones delegated to them so they can manage them in v6.Take this away and you virtually guarantee that end users who know what they're doing end up becoming ARIN direct end users and stop getting space from ISPs altogether just because that's what they have to do to get IN ADDRs.
Rob Seastrom: That might still happen regardless of policy.
John Curran: I'll close the microphones shortly. Please approach the mics if you wish to speak on this policy.
Jason Schiller: Jason Schiller, Google. Can I suggest we make the implementation of this dependent upon a services document being published which covers the delegation of reverse DNS?
John Curran: So let's be very clear. There's actually no implementation to this policy. Meaning, to my knowledge, the community is not asking us to offer any different services or change any different services or change administration of how we currently administer Number Resources.
Jason Schiller: So it would be removing the text.
John Curran: The removal of it would not occur prior to a services catalog appearing online. Happy to do so.
Rob Seastrom. Thank you. Rear.
Michael Joseph: Mike Joseph, Google, again. To Owen's comment and concerning the specific text that's up here, which is the existing text in the NRPM, it's actually fairly problematic. If one reads this text strictly, one might interpret, say, a residential access ISP as having to delegate every assignment they might make to their customers. Does one believe that every access ISP shall be compelled to offer DNS delegation to every home they serve?
Rob Seastrom: I'm going to defer that question to Owen at the front microphone, and I'll also note that the chair has indicated his desire to close the microphones. So anybody who is interested, please get in line now.
John Curran: Ten, five, four, three, two, one. Lines are closed. No one enter the queue.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. One word answer to Mike Joseph: Yes.
John Curran: There's a requirement presently in the NRPM that covers directory services. It is its own section. That's why it's - sorry. Same place that residential privacy occurs. There's an expectation that you'll populate Whois and put in the appropriate reverse maps.
Rob Seastrom: Thank you.
Vint Cerf: Do you want to get a sense of the room?
John Curran: Up to the chair. Enough feedback?
Rob Seastrom: We're fine at this point. It clearly needs massive overhaul before we can make any kind of meaningful request of the community.
John Curran: Excellent discussion. So we're coming into the break period, and we have this Allow Inter RIR ASN Transfers, which is potentially a large, long discussion. I don't know.
Let me ask this: People want to cut into their break a little bit - or delay the break a little bit and keep going on policy? Is that generally yes? Let's try to get it done, then.
Scott Leibrand, please come up we'll handle ARIN Draft Policy 2014 15: Allow Inter RIR ASN Transfers.
Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers
Scott Leibrand: I got permission to talk really fast and nobody's going to object.
John Curran: There's a transcript person in the back. I don't see them, but I have sympathy wherever they are.
Scott Leibrand: So the question here is the problem statement is should we allow - this is a question I'm going to ask. Should we allow ASN transfers between regions, between the ARIN region and other regions, to be compatible with recently implemented APNIC policy. The original proposal to do this was in 2013. That was presented before the community, didn't get any objections. A few people thought it was useful. But there were some sentiments that why are we bothering with this because there's no other RIR that could do it.
So what we ended up doing was abandoning that until APNIC adopted a policy that would allow them to receive ASNs or send them ARIN's way, and at which point this was reintroduced and reconsidered. But at the PPC in Bellevue, there were some RPKI concerns raised, and the staff addressed them in staff assessment. So that's the primary area that I want to get feedback from the community on. The Draft Policy text itself is pretty simple. Simply add ASNs to be transferred as one of the things that can be transferred under 8.4 and add some text at the bottom to make sure that getting an ASN transfer doesn't preclude you from getting v4 and vice versa.
But in order to do this, we would require some additional work on the RPKI system in order to make the trust work when the delegation from IANA to an RIR needs to be replaced with the delegation from IANA to another RIR. That work has been done in IPv4. It has not been done for ASNs. So it would require some work on behalf of ARIN and also some coordination between RIRs along the lines of what they did, what was called ERX for IPv4. We discussed this at the PPC a couple days ago, and the ARIN staff said this could be done. It wasn't a tremendous amount of work. But it's work that is probably unnecessary unless this policy is desired by the community. So my question to the community is: Are ASN transfers worth it? I have not yet heard anyone argue - either on the List, at the PPC this week, or otherwise - that ASN transfers are valuable enough for ARIN to do this work. So before we go into a lot of details about what the work is and rehashing the stuff we talked about on Tuesday, I would like anyone who thinks that ASN transfers are necessary between regions - they're already allowed within the ARIN region; they're allowed within the APNIC region. If that's good enough, we can be done with this and abandon this policy and move on. If you think we need ASN transfers between regions and it's worth the effort to have ARIN go do the RPKI thing, I'd like to hear from you now. Otherwise, my intent is to propose that AC abandon this policy tomorrow at our meeting.
John Curran: You keep saying ARIN do the work. Since this is inter RIR, you're actually saying ARIN engage with the other four RIRs to get all of us to do the work. Just clarity.
Scott Leibrand: Thank you. So that's the discussion point I'd like to start with. Hopefully, if there's consensus that this is not worthwhile, we can skip the whole hashing, rehashing of what work is required and go to break. So, first off, does anybody think this is actually worth doing and want to speak in favor of this proposal?
John Curran: If you think this is a good proposal, please get to a microphone now.
Scott Leibrand: Front mic.
Adam Thompson: Adam Thompson again, Manitoba Internet Exchange. In view of the fact that the gradual globalization and interchangeability of Number Resources between RIRs seems to be somewhat inevitable, putting the policy language into the NRPM now seems fairly sound. Whether we actually need to support it in RPKI at all at this time I doubt, particularly if we believe Geoff Huston's analysis of where RPKI is headed.
I don't see a problem with saying, yeah, you can transfer your AS numbers between RIRs but, sorry, you're SOL when it comes to RPKI for now.
Rudiger Volk: Rudiger Volk, Deutsch Telecom. If any transfers can be done, all types of resources can be transferred. There may be minor technical differences, but there is - I cannot see any reason why any particular - and in particular the AS numbers would be more difficult. It's just - it's just settling that, and allocate for the RPKI side. Actually the RIRs have been asked by the CIDR working group for quite a long time to come up and explain how the transfers should be done. And that request, as far as I can see, hasn't been resolved. And, well, okay, it actually needs to be resolved.
Matt Petach: Matt Petach, Yahoo! I'll admit I'm a little confused and would like some clarification. When you talk about transfers from RIR to RIR, does this mean from organization A in RIR One to different organization, or does this mean as Yahoo! I can take an ARIN AS number, transfer it under APNIC to be under their rules but keep it within my company?
Scott Leibrand: I believe those two are the same thing because you would transfer it to Yahoo! Japan or some other -
Matt Pounsett: No, it would still be Yahoo! ORG as the parent company. We work in many countries.
John Curran: Literally it's the transfer from the - from an organization - it's not the transfer necessarily between organizations. It's the transfer from the administration of one RIR to an administration of another RIR.
Matt Pounsett: Thank you. That was the clarification I needed.
Jason Schiller: Jason Schiller, Google. I forget who said the comment now. Rudiger. Rudiger was at the mic and asked a very good question, which is why is dealing with transfers of ASNs more difficult and different than dealing with the transfers of IP addresses? I'd like to hear an answer to that question.
Geoff Huston, can you come to the mic? Because I think you can answer it a lot better than I can.
Geoff Huston: Geoff Huston, APNIC. I can give you a very quick description of why particularly the 2 byte AS numbers are treated differently within the entire registry system than 4 byte ASN numbers, these larger ones, v4 and v6.
In all of the other IANA run registries, the IANA content, the content they put there, are actually a listing of delegations to RIRs as they happened. So if transfers move between registries, it's a registry to registry issue and that we track that within the corresponding RIRs. That's why the v4 registry only has basically 256 /8 entries. It's what IANA did.
At some point in the indeterminate past, I suspect about eight years ago, the registry services managers and folk from IANA sat down, looked at the AS number registry and decided they would inflate the 2 byte AS number registry and include the particular listings of every individual AS number and where it went. So now when we do inter RIR transfers in that 2 byte AS number registry, to tell you the truth, we're really confused as to what should happen. Did we unwittingly create a precedent so now every single 2 byte AS number now needs to go up to IANA, change the registry, break things apart, drop it down?
And then the meta question: What's so special about that registry that we have to do this but we're not doing it in any of the others? And is this pain really worth the effort? Do we really want to open up that box? This is going to be a lot of work to try and resolve. There's no reason to keep that 2 byte AS number registry different. But normalizing it is as much pain as not.
So this policy proposal opens that box up, which is why it's kind of - if you're really serious about this, the pain will be incurred no doubt. If you're just doing it for uniformity, you're opening up something that is of large cost but little benefit. Owen DeLong: Renumbering IP addresses is hard. Renumbering AS numbers really not so much. So I've done it. I've done it at fairly large providers. It's painful, but it's not nearly as bad as renumbering a few hundred customers for their IPv4 addresses.
So I personally don't see a lot of need for AS transfers in general and even less need for moving ASNs from one region to another whether within the same organization or across organizations. I don't see those as being particularly different from an RIR perspective.
Because it may be Yahoo!, the same company in North America and in Japan, but it's not Yahoo!, the ARIN organization ID in Japan. It's Yahoo!, the APNIC organization ID in Japan and the ARIN organization ID in ARIN. And they're two different organizations from an RIR perspective. I personally don't support the policy. I think it's way too much work for way too little benefit.
Heather Schiller: Heather Schiller, Google Fiber. Someone yelled "squirrel" and we all looked. The real question is: Do you want to be able to transfer ASNs between RIRs? If we do, the RIR staff will figure out how to make it happen. RPKI or not. It can be figured out. It's not a technical impossibility. It might be work. They might say: You can transfer your ASN, but you're not going to get this RPKI thing on it until we finish some work. The really important question: Do you want to be able to transfer ASNs between RIRs? And I'm not hearing enough from the community about whether they want it. I personally agree with Owen not - to me there's plenty of ASNs. There's not a lot of benefit for it. But I'm not stuck around the RPKI piece.
Scott Leibrand: Yeah. It's a "Is this worth it?" question to me.
David Huberman: David Huberman from Microsoft.
John Curran: I'm closing the microphones shortly. Approach the microphones if you wish to speak to this.
David Huberman: Matt, I want to answer your question from a reality side. Microsoft received a block of AS numbers from the InterNIC. Our Chinese equipment, Beijing -
John Curran: Hypothesize.
David Huberman: No. This is real. It's innocent. It is. It's innocent. We use those AS numbers in our network, and Beijing is on AS 8072, which is here. There are now regulations by the Chinese government. China Telecom and China Unicom, the main transit providers, are no longer allowing us to originate routes from AS 8072. They're about to pull that from us, unless AS 8072 is registered in CNNIC.
ARIN policy forbids us from moving this. Now, two days ago when we talked about this at the PPC, I got up at the mic and said: Look, it may be painful, but Microsoft is willing to just eat the operational cost of renumbering the AS to a CNNIC AS if it's really that difficult. After talking, however, to the engineers, they're really not happy with that answer. So there's a real operational reality for multi continent networks.
John Curran: I have to ask. In light of the operational reality, are you saying this is the type of thing that should be advanced?
David Huberman: Heather's argument kind of resonates with me. I don't like hearing from the RIR staffs, these very intelligent folks: This is really hard and we don't know if we want to do this. It's a creation that happened when somebody got to the IANA and wanted stuff fixed. And now there is a cost to that. And this is something that's solvable and probably should be solved. You'll fix the meta problem if you solve it too.
John Curran: I just want to be clear. Have no view of whether we want or don't want to do this. Just want to identify large chunk of work -
David Huberman: Well, your staff has made it pretty clear they don't want to do it. And by staff -
John Curran: We love doing work.
John Curran: So, I mean, I just want to be clear. You folks need to know you want us to do it. That's it.
Scott Leibrand: I think Mike was next.
Mike Joseph: Mike Joseph, Google. I want to respond to two points. To Owen's point, I've done AS renumbering for large ISPs, and it is actually quite onerous. You're not talking about renumbering or exchanging your ASs on peer and transit. That part is the easy part. It's getting all your customers to change their remote BGP sessions. When you're a large ISP, that's quite a large obligation. That said, I'm not sure I see why transferring ASs would preclude an AS renumber. In fact, one would argue one would cause one. So although I disagree with Owen, I'm not sure that that has much implication on this policy.
I would ask, however, Geoff - Geoff stood up a few minutes ago and hopefully clarified the implications for the IANA. And then he admonished us to consider why bother implementing this policy. Yet, I point out that one of the justifications for this policy is that APNIC did it. So I'd like to understand. Perhaps Geoff could comment on why APNIC thinks this is a good idea.
Scott Leibrand: I think I can say Geoff doesn't speak for APNIC, but if he - if he wants to give himself another defense, he's welcome to.
Scott Leibrand: I've heard that from Geoff a number of times; that he can't speak for the APNIC community.
John Curran: Geoff, do you want to approach the microphone or not? Totally your choice.
Geoff Huston: I don't think I admonished anyone saying we didn't want to do it. As John says, we're here to do the stuff, and that's fine. I simply pointed out that in that particular registry it's different to all the others and it's going to require a fairly concentrated effort to understand how to do it. That's okay. My second comment was if you want to go there, that's fine. If you want to do this for completeness, understand that associated with that is this larger effort of trying to understand what's going on in the IANA part of that registry and what are we going to do about it. Because at the moment it's managed subtly differently from all the others. I don't know how we got there, but that's where we are. Is that clear?
Mike Joseph: I think on those points, yes. Thank you.
John Curran: I'm closing the mics. Approach the mics. Last chance. Ten, five, three, two, one. Microphone queues are closed. Those at the mics, continue. Those in the queues, continue.
Martin Hannigan: Martin Hannigan, Akamai Technologies. I do support this proposal, yada, yada, yada. I'd like to echo David's commentary operationally. I have similar problems with CNNIC. I also have problems with German privacy law and other things that require registries to actually be registries. So if I'm going to originate routes in Europe, using ASNs that I may have or may not have from ARIN exclusively, I do have some requirements that somehow I need to indicate that that ASN is being utilized in the region and regional contact information for law enforcement and government.
Scott Leibrand: Thank you.
Mike Burns: Mike Burns, IPTrading. I'm the policy author - or the proposal author. I'd like to thank the shepherd for immediately moving for abandonment, but -
Scott Leibrand: It's the only way I've ever gotten a response so far. It worked.
Mike Burns: I have to confess that I did issue the proposal as a feeling of comity - comity with a "t" - with the APNIC registry. We had gone and discussed this proposal, as you mentioned earlier, and then we found that we had no other suitors. And then here comes APNIC and they do a reciprocal policy, and now they don't have a suitor. I thought it would be nice for us to do that.
Now having heard some of the technical issues and also for the first time some of the operational demands or requirements for transferring inter regionally AS numbers, I have to say I still support it. I think the artifact of the IANA registry of the 2 byte ASNs is something that should be fixed. So I support the policy.
Scott Leibrand: Last speaker. He knows who he is.
Jason Schiller: Jason Schiller, Google and the ARIN ASO AC. Regardless of this policy, whether it passes or not, whether it's good or bad, if we decided for some reason that we wanted to change how the IANA operates with respect to 2 byte ASNs and how they're recorded and how that delegation works, how would we go about fixing that? Because it feels to me like a global policy proposal to change that is sort of like me putting in an ARIN policy proposal to change fees. We don't make policy about operational practices of ARIN. So how do we tell IANA, if they have an operational practice that is bad, that it should be changed?
John Curran: If this is adopted, we will engage with the IANA and do so.
Jason Schiller: So we don't need global policy to do that?
John Curran: Not at all. This is an implementation feature that will get worked if necessary, but otherwise it will get ignored. It doesn't pose any issue otherwise to my knowledge.
Jason Schiller: Thank you.
Scott Leibrand: So I have a question for John and Vint. Would it be appropriate to get a feel for the room as to whether we should move this forward or not, or do you think we've got enough feedback? I've heard a lot of comments; I don't have a sense of what all the people sitting down think. So I would like a show of hands whether we should move this forward or abandon. So I'm going to ask Vint to ask the room after I sit down whether we should abandon this proposal or not.
Vint Cerf: So just for the record, you want that precise question answered, do we abandon or not. So you've heard the proposition. All those who think we should abandon and not continue working on this particular proposal should raise your hands now and keep them up. Raise your hands. I see people resting your elbows. I'm sorry, you're not allowed to do that. Thank you. I'm seeing hands popping up in the front here. You're voting in favor of abandoning further work on this proposal. We have the count. Thank you.
All those who are against abandoning, wish to continue working on the proposal, please put your hands up and keep them up. Again voting in favor of continuing to work on this proposal. I see two hands up. I'm sorry, put that hand down. Very funny. Good thing we're not under some laws that cause you to lose limbs. We have the count?
John Curran: We have that, and they're coming back now.
Vint Cerf: Thank you. I have a stupid question, while we're at it, waiting for this to come back. Is this transfer notion exclusive, or do you end up having the same ASN registered in two places? Because the CNNIC demand sounded almost as if you were going to originate routing information in two different regions.
John Curran: Registry entries -
Vint Cerf: registered in both places.
John Curran: Registry entries are administered by a single RIR unless we change major aspects of our architecture.
Vint Cerf: So that's quite a demand being made by CNNIC.
John Curran: It is requiring that a given resource be administered by a particular RIR is a fairly onerous demand.
Vint Cerf: Especially considering the architecture permits pieces of the network to be anywhere in the world. Thank you very much. Okay. So with 165 in the room, eight remote, 173 total. Do we abandon? 13 are in favor and 23 are against abandoning. So we will continue this discussion. Thank you all very much.
John Curran: Thank you very much. Okay. It is now 11:00 and the next item is the IANA Stewardship Transition Planning Process. Welcome back from your break. Very good. You can have a 20 minute break. 20 minute break outside. There are refreshments. Be brisk. See everyone back here at 11:20 promptly.
IANA Stewardship Transition Planning Process
John Curran: Next session is on the IANA Transition Process. I have slides. And I should have changed the title. So I'd like to get started talking about what's happening with the IANA changes. The first part of this talk I actually gave earlier, and it was during NANOG. I gave them a quick introduction to what's happening with the IANA. I'm now going to continue that and add some more slides regarding the ARIN specific process. So first to note IANA, Internet Assigned Numbers Authority. Throughout the entire history, the Internet system has employed a central Internet - IANA - Assigned Numbers Authority.
IANA handles three central registries: the names - i.e., the DNS root zone - the numbers - IPv4, IPv6, and ASN free pools - and the protocol parameters. Actually, it's sort of interesting. The DNS root zone is only one registry, if you think about it. IPv4, IPv6, 32 and 34 bit ASNs are four registries. Protocol parameters, there's nearly a thousand protocol parameter registries. Your BGB option numbers are in a protocol registry, your port numbers in a protocol registry. Nearly every Internet RFC that has a protocol has an IANA consideration section that creates an Internet protocol parameters registry. So numerically the majority of registries managed by the IANA are from the IETF, and they're the result of Internet drafts.
So this is an important function particularly for the IETF to have an accurate registry of option numbers and port numbers, protocol fields. It is very important to us because the IANA manages the unallocated pools for Number Resources and ASN numbers. And of course the IANA also updates the DNS root zone which some people are interested in. And, so while the number of registries are actually weighted towards the IETF, the political visibility might be in the opposite order. A lot of people pay more attention to the DNS root zone than all the other things that IANA does. US government announced the plan to transition oversight of the IANA functions contract from NTIA to the global multi stakeholder community.
Currently the IANA operates under two arrangements. One is the IANA functions contract issued by the Department of Commerce, its NTIA agency to ICANN, and under that contract ICANN performs the IANA functions. There's also an MOU with the IETF, and under that MOU between the IETF and ICANN, ICANN performs the IANA functions.
The NTIA conditions for this transition of its authority, its stewardship to the Internet community, is that they want a proposal from the community. And that proposal should support and enhance the multi stakeholder model, maintain security, stability, and resiliency of the Internet DNS. You know that phrase "Internet DNS." When NTIA uses the phrase "Internet DNS," they actually mean the entire system - names, numbers and protocols and parameters. I actually had to ask this directly to get it clarified. So maintain the security, stability, and resiliency of all the IANA functions.
Meets the needs and expectations of the global customers and partners of IANA services. So IANA has a customer in the IETF who sends it RFCs and with IANA consideration sections. As a customer in the RIRs, we develop global policy, have it ratified by ICANN, send it to IANA for them to implement in managing those. And then of course ICANN itself is a customer in terms of the administration of the root zone. And maintain the openness of the Internet.
So those are the NTIA conditions. We, the global community, have to put together a proposal that meets that set of requirements. One little detail. US government NTIA will not accept any government-based proposal. It cannot be purely government based. It's identified in the questions and answers as an unacceptable answer. Now, it's challenging to put together a proposal, particularly when it has to come from, quote, "the entire Internet community". And so to do this, ICANN was asked to facilitate the process and act as a secretariat to the community. The proposal that was floated and adopted was that there would be an IANA Stewardship Transition Coordination group. It will have 30 people, several from the ASO, our address supporting organization, and IETF and the IAB and SSAC and RSSAC and ALAC. For those of you familiar with ICANN, some of those terms are familiar. The GAC, the GNSO, the GTFE registries, the CSC NSO, pretty much everyone has a couple of seats at the table.
This 30-person group has to develop a proposal for NTIA's consumption. The proposal has to meet these criteria and it has to handle how stewardship is provided for, for these IANA functions, absent US government doing its contracting. Now, "stewardship" is an interesting word. It doesn't mean this group has to come up with a proposal to do those tasks. It has to come up with a proposal so that those tasks are being done with appropriate oversight and accountability. The RIRs, the DNS community, the folks at the IETF have generally indicated support that ICANN is doing an adequate job as the IANA. In fact, the specific leaders of those organizations, we actually issued a statement several months back where we said we believe ICANN is doing a good job, as the IANA, we like it to continue. That helps support the stability aspects.
But we still need to put together a proposal as to how the oversight and accountability of that is being done, how the stewardship is being transitioned from the US government to the community. So we have this coordination group, and it has to put together a plan. And the plan has to come from the community, which means we need lots of pieces to come from different areas. Obviously how numbers are handled, how names are handled, how Internet protocol parameters are handled are all going to come from their respective communities, and this team is going to have the enviable job of assembling that together. Its mission, to coordinate the development of a proposal among the communities affected by the IANA functions. There's a charter online. You can go look at it. It has several meetings. Its meetings are open. You can participate in the teleconference and listen to them discuss things. They're trying to make sure they do a thorough framework on how they're going to get this job done. But it's a very difficult job.
Now, there's a graphic here, and this is an exciting graphic because it points out a couple of things. One of the things it points out is that the IANA contract expires on 30 September 2015. If we're going to have a proposal in front of NTIA so that NTIA doesn't have to continue the contract in any way, it has to be there months before that. Recognize that once NTIA gets this proposal, it's not as if one guy's going to take out a pen and sign it and say "Good job." There may be other parts of the US government that want to comment or consider the implications of this. So while it says September, realistically the sooner we put this proposal together, the more realistic it is that it can actually be considered. And these are a rough idea of the steps involved. And this includes putting together a proposed framework, which we've done, the community working on a proposal. Its going from the team, going back out to the community for more input and iterating. We expect it's going to take a few iterations.
And think about you have a central team assembling a central proposal out of component proposals which are going to come from the RIRs and IETF and ICANN's communities, plus additional inputs. They've said specifically they're open to additional inputs. So we have to try to get all of this together into one document and actually have it represent the community's view. I will tell you this is going to be a challenge. In the RIRs, each of the RIRs has kicked off a process for how it's going to get its input that will be used with the other RIR's input to build the RIR submission to the coordination group.
So you can go look at these websites - AFRINIC, APNIC, ARIN, LACNIC, and RIPE. The ARIN one doesn't say much. A lot of people said, yeah, pretty good processes in all the regions except for ARIN. Well, yeah, we didn't want to set the process on how we're going to do it without talking to you first. But we will quickly update once we've had this discussion with the community and set the process for this region. But it wouldn't be appropriate for staff to do that on your behalf. There are going to be some upcoming meetings. Our meeting is kind of right here. We'll have this discussion. But this topic will be at each one of these RIR meetings as they try to develop their input.
We're probably not going to have another meeting between now and the next ARIN meeting. We're probably not going to have enough time to get another face - the face of everyone here. So we're going to work predominantly by a Mailing List basis, because we probably have to have our input to the other RIRs by November or December so that it can be harmonized into one input by January or February. And so we have to do a lot of our work by email. Some of these other RIRs may have a chance to do a face to face ratification of what they submit. We unfortunately won't have that luxury.
So on the ICG process, not the RIR process, not ARIN's process, but on the overall ICG process, are there any questions? I have a lot more slides. I'm taking a pause now just with the framework that's been set up to develop a policy proposal.
So on the ICG coordination group, its charter, any questions?
Kevin Blumberg: Kevin Blumberg. Very quick question. There was all of the organizations that were mentioned that were a part of this process. Is there anybody outside of that process? I.e., if you are an individual, would you then have to go through one of those organizations, or are they looking at the direct involvement?
John Curran: Great question there. All of us are trying to keep our processes open so you could participate through any one of the communities. But, in theory, this process is supposed to be open to everyone. ICG, to my knowledge, hasn't made a clear way of you submitting input. There is a Mailing List. In theory your input would get considered. But I will tell you your input would have more weight if you worked through the cross community working group in ICANN or RIR community and get your thoughts on that, because it's going to be hard enough taking the directly affected communities and combining their output with one individual contribution on the side, if you were to make it. If you can actually get momentum in ARIN or momentum in the RIRs, your input would have a lot more chance of surviving the process when everything is slashed together into one. ICG, in theory, is open to input. There's no process I know of other than to send it to the Mailing List.
Milton, I'm going to put you on the spot since you're at the mic. Do you know if ICG is open to any other input other than through the Mailing List?
Milton Mueller: That's why I'm here at the mic, because you're asking questions about the ICG, and you're not on the ICG and I am. So I thought maybe I should be answering some of these questions.
John Curran: That would be great, actually.
Milton Mueller: You didn't quite emphasize strongly enough the extent to which the ICG does not develop the proposal. The proposal process development has been divided into three parts - numbers, names, and protocols.
There is a well established process underway through the IETF for protocols. There is one for names that has just launched. And as far as we can tell from the ICG, there is not an integrated RIR process.
To directly answer Kevin's question, we have actually addressed this in an FAQ that I think will be released in Los Angeles. But the point is we're putting all of our emphasis on these operational communities to convene a broad and open process. Not just for people who are part of the RIRs. It should be open to anybody.
Now, of course, when it comes to the numbers root or whatever that is, not a lot of random people will be interested in that. But the process from our point of view does need to be open. And if Kevin goes and sends us an email that says "I think you should do this" in the numbers space, all we're going to do is send it to whatever process the RIRs eventually put together and say to Kevin: We have submitted your ideas to the relevant people, but don't complain to us because we're not like the decider who says, oh, I like this proposal, I don't like that one, let's mix these two together. We are simply there to assemble the completed proposals, check them for consensus, consistency, accountability, and then package them together and send them to ICANN for transmission to the NTIA. That has to be very well understood that we are not sitting there to receive proposals and decide among them. It has to take place at these three communities.
John Curran: That's very helpful. So, Kevin, to re answer your question. I'm glad we have Milton who is actually on this coordination group, and I look forward to the FAQ which would help as well. They're taking the input based on the matter, subject matter areas from those respective processes, and there's an obligation on those individual areas to be most open to input, not just from their own communities but to the public at large. So that's why - the other point is that to date there's not been a stated process for how the RIRs are going to assemble their input, and obviously if someone completely outside the RIR community wants to submit something, they need to know that process pretty quickly. So that's something that my talk continues on. So the answer is if you were not part of this community, you should put your input to the respective process based on what it's about. If you're talking about numbers, make sure it gets into the process in this community. If you also have input about the names or the protocol parameters, make sure it gets into the IETF process, because it's going to be handled on a topical basis, if I understand you correctly, Milton. And you folks aren't doing - I think it's very clear. The ICG is assembling and helping clarify how these proposals knit together. They're not creating anything. You're the coordination team. Now, you have a question, Milton?
Milton Mueller: No. I'll stay here in case you need me.
John Curran: Front mic.
Matt Petach: Matt Petach, Yahoo!. To be clear, from the NTIA's perspective the ICG is not the sole arbiter of proposals. The ICG is bringing one proposal to the table, but a collection of commercial entities could band together and put a competing or collection of competing proposals in front of the NTIA as well?
John Curran: I don't speak for NTIA any more than I speak for the ICG. Obviously NTIA is an agency open to input from a lot of different sources. I can't imagine them saying no, we won't listen, if a group of commercial organizations were to do that. So I expect that's the case. I haven't seen an FAQ that answers that from them, but there's no reason while this process is going on people can't talk to them.
Matt Pounsett: From the point of view if people are concerned about the ICG not being open to inputs in the way they desire, do recognize that this is not the only path. This is what we would like to see as everybody coming together. But if we don't do a good job of bringing everyone together, everyone has choices of other ways of bringing it to the NTIA.
John Curran: Milton, do you want to respond?
Milton Mueller: I wouldn't encourage you to hold that view. I think the NTIA made it clear: We want ICANN to convene a process. ICANN created this, and they are expecting a proposal from the ICG. If you don't like what the ICG puts together, then there will be a public comment period at the end of our process in which you can band together. And if like 16 major Internet corporations all say "We hate this," I think the NTIA might give us the proposal back and say keep working. But I'm pretty sure they do not want a bunch of people coming through back channels. I don't think anybody wants that, in saying here's what you really want to do, you just had this big public process, global process, to fool everybody and now really what we're doing is a bunch of American companies are approaching the Commerce Department behind the scenes and coming up with their own proposal. I think that would be a bad, losing situation for everybody.
Matt Pounsett: Thank you for clarifying that.
John Curran: Good clarification. Back microphone.
Ashley Heineman: Hi. My name is Ashley Heineman. I'm with NTIA. And I just wanted to concur with what Milton said. We have tasked ICANN to shepherd this process, and the vehicle that they're now working through is the ICG, and we are expecting one proposal. So please make our lives easy. Thank you.
John Curran: Thank you. That's very clear, then. Let me continue, then. So obviously the process we use in the RIRs is pretty important and the process we use in the ARIN region. I'm going to talk a little bit about the ARIN region. Let's talk about the RIRs first. The RIR's executives are getting together and we're trying to figure out how we're going to collate five regions' individual inputs into one. We will come up with a process. It's likely to be a process that involves - it's going to have to be on very short order because by the time you guys develop something for this region, the ICG will be anxiously awaiting, but we'll also have community involvement in that.
So we'll probably have some sort of process to pick some people and have an editorial group that assembles the proposal and gets back to each RIR and says when we assembled them, here's what fit and here's what didn't.
So you're going to actually see no matter how we try to do the same thing the ICG is doing at the RIR level, we're not going to create anything new, it's going to come back to each RIR as here's what didn't work, we need to increment this.
In the ARIN region, we're going to be doing this on a Mailing List. And you're going to have to be involved in that Mailing List, open Mailing List. You'll have to be involved in that mailing list so that when the RIRs try to stitch this all together and we get the feedback on what works and what doesn't, that you can be responsive.
I'm going to talk about the ARIN process. We still do not have a defined inter RIR process. We're working very aggressively on getting a strawman out on how we're going to do that. But I want to talk about how we get the input from this region to put into the five RIR process. So in the ARIN region, we sent out a consultation - sent an announcement out earlier, about a week ago. We indicated that we're going to open up a consultation on a Mailing List from October 13th to October 27th. We want to conduct a survey of the community on how they feel on certain topics to help with drafting the position from this region. Because right now we can get a bunch of people on the Mailing List, but in some ways you want to know where are all of you sitting, not who can send the most email in any 24-hour period.
One of the questions is what do we ask you, what do we poll the community. And so we're going to hear a little bit about that. We want to conduct a survey next week to get your positions that would be used to draft this document. And I'll talk about the questions. After we get that, we'll very quickly turn around and we'll post the survey results to the same consultation Mailing List. People will have time to discuss them. We'll start working on individual sections of text based on the survey response and the dialogue on the list. We'll try to put a draft of summary, an initial submission document, back out to the list by November 3rd. Moving on very short time frames because we have to get this integrated with the other RIRs.
And then we would have ongoing discussion to make sure everyone's happy with the submission before we sent it to the other RIRs.
So it is a process that involves a survey next week on a particular list of questions and two weeks of online writing and editing trying to get particular paragraphs done, with the final document the first week of November for everyone to say that's a good submission from this region. Now, again, I want to set the right expectations. This is probably an 80/20 rule or a 90/10 rule. Because what we send out to the other RIRs will not match what they do. So we don't need to worry about sentence fragments, necessarily, because we have to get conceptual alignment before we get a final document.
We have to get something that's understandable in terms of bullet points and positions. And that will be - you'll get to see how that gets merged with the other RIRs. And then we'll come back to the same Mailing List. Now, this is the proposed process. It's the only thing we can come up with that gets something that really is from the region, the people who are interested in this region, whether you're ARIN members, not ARIN members, interested third parties, whatever, but still does it in a timely manner. I have questions. And my questions are: Does the process work? Is that a process that you think is reasonable? Are any changes needed? Recognizing the requirements to get this done in an open fashion from the ARIN region and get it done promptly. My question is the Mailing List. What Mailing List do we use? Some of the Mailing Lists are closed, like ARIN Discuss. Okay. Some of the Mailing Lists are open but unpopulated or lightly populated, like the ARIN Consult Mailing List, though available to anyone who is interested. And then there's Mailing Lists that are fully populated and already have other topics on them, like PPML. That's one of the good questions we need to talk about.
And then another one is we intend to conduct a survey. And there's some survey questions. I'm going to hold off on the survey questions. I want to know about the process I've outlined, this process, with bullets one, one, one, and one - thank you - and is that process sufficient and do we need a dedicated Mailing List and how should that mailing list be populated. And microphones are open. Topic of the Mailing List and the process.
Matt Petach: Matt Petach, Yahoo! I would propose we actually open a new Mailing List just to not pollute the existing ones, and that way we can make it as open to as many people as possible.
John Curran: New Mailing List, not pre-populated but open to everyone.
Matt Petach: No, announce the new Mailing List on existing ones as broadly as possible but do not pre-populate.
John Curran: Okay. Thank you. Middle microphone. Milton.
Milton Mueller: My problem is I'm going to change your whole paradigm here. As you know, I don't think there should be regional processes, separate regional processes. I think that, first of all, is a limitation on the openness of the process; that it will stifle the discussion; that people will not get exposed to views. The IANA is a single thing, and the relationship that the RIRs have to the IANA is a uniform thing. It's not like in the end APNIC is going to have a different IANA than ARIN. Right? So you're all talking about the same topic. You should have a global Mailing List, and it should be open to anybody interested in the topic. It should be open to anybody from any region. The process of developing regional positions and then filtering them into a negotiated global position I view as being a little bit too easily to manipulate in a top down way. I think it should be worked out openly and transparently by everybody involved at the same time. And I just don't think that you can do this, have separate regional processes and then integrating them into a global process, in the timeframe that we have. I just don't see the need for a regional process here.
John Curran: Can I ask a couple of questions of clarification? So what we're proposing to do is extremely similar to what ICG is proposing to do. And I'm trying to figure out why it is that it's possible for the ICG to do it but -
Milton Mueller: No, it's not. It's like if the ICG had said let's ask every one of ICANN's five regions to develop a proposal and then have names and numbers community develop a proposal and then have us sort them out, we - furthermore, you guys are developing the proposal at the top level. We are not developing proposals. We are receiving proposals. So we want - I mean, there's only one IANA for the address structure, right? There's not five different IANAs. Why don't you get together and all decide what you want the IANA to be, how you want it to be structured.
John Curran: Okay. I'm going to - no - no more question; just to understand. So it's very difficult for the ARIN meeting here, even if this room were to jump up and cheer "Let's have a global process," there's four other RIRs that have to agree to have a global process rather than regional processes. So I'm just logistically - I'm going to note the challenge. That's not to say I'm not up to it, if that's - but we lose time if we do it and we don't converge on a global process.
Milton Mueller: If you think it's harder to agree on whether to have a global process, how hard do you think it will be to get them, all five, to agree on what the IANA proposal should be?
John Curran: Not time. I'm saying it could be easily just the time it requires to agree or not agree. I think it's a straightforward process to ask all the RIRs. My fear is that in the time it takes to get a straightforward "no, thank you" we will have lost time. Let me ask one more question just to understand. Do you want a global process at the end? Because once the RIRs have individual submissions, a global Mailing List - and using those as input to the list but allowing any other inputs would give you the global discussion and it would just give you five strawmans to start. Is that sufficient for the openness and the getting back to one process that you're looking for?
Milton Mueller: No, I don't see the point of that. You don't want to bring strawmans that your staff and your people are committed to into the process. You want everybody to negotiate with everybody else as to what the proposal should be.
John Curran: Okay. Got it. Very clear position. For a moment I'd like the people at the queues to step to the side if they're not responding to Milton's question. Milton's raised a very clear query about having a global single process rather than five regional processes. I'm looking for responses on that.
Andrew Dul: Andrew Dul, on the ARIN AC. I support Milton's idea that we need a global process here. I'm trying to understand how we got to having five processes to start with, because obviously there was some conversation that had to have happened to say we're going to go separate ways rather than try to do this together, because there is one submission to the ICG at the end. If anyone can illuminate how we started with five, that might be helpful. But if there's no real answer to that, I still believe we need one process. I would - given the time constraints, I think I would be okay with the "five strawman into the process" idea and then having a global discussion about the actual submission. I definitely don't want to have the submission go back to five regions and be discussed separately. That just sounds ridiculous to me.
John Curran: Let me fill in a data point, because you asked the specific question. In the case of the IETF, you have a single organization, and so it's pretty easy to have a single organizational process. In the case of the RIRs, you have five RIRs which have clear communities, meetings, and have a validity. The NRO is the union of the five executives as a coordination, but you don't want the NRO running a single process. It's not a community based organization. It's a association of five RIRs. And so it was felt it wouldn't be valid to run a single process, which was just whoever spoke loudest on the Mailing List, when we all have meetings that allow face to face dialogues. So very quickly the NRO said: We should have each of our communities consider this and submit and we'll try to figure out what is in common. That's to answer your data question -
Andrew Dul: So when you say the NRO quickly considered that, is that the NRO executive committee?
John Curran: That's the five executives. So next response on Milton's question.
Vint Cerf: I would just make an observation that the RIRs and the NRO will have a process for deciding global policy with regard to IP address allocation. Why don't we just exercise that same mechanism. It seems to me that's what you've chosen to do. And so I don't agree with Milton in this case. I think we should use the mechanisms we already have for global development of policy and then use that same process to come out with whatever the agreement is. John Curran: Anyone else who wants to respond on that point. We're on the point of global versus regional processes.
Jason Schiller: Jason Schiller, Google and ASO AC. I echo a lot of the concerns that Milton brought up, that Andrew echoed, and that Vint echoed. I think we do have precedent for this. We do have a global policy process, and the way that process works is slightly different than what we see here in Bullet One. The difference is primarily that we have individual processes that run in each of the five regions where we discuss and try to get to unified text. If we don't get unified text, the NRO EC can do some rewriting, but then that gets kicked back to the NRO NC to look if there was a substantive change to the policy and if the rewritten policy is essentially what the communities discussed or not. And if it's not, it gets kicked back down to the communities. I think that's what's really missing here in this ARIN region process in Bullet One where after all the five proposals come in are combined, it sounds like the intention is for this to be an 80/20 thing; that 80 percent of the five proposals will survive, two percent maybe will get lost, and that's what's moved forward.
And that can't happen in our global policy process. We had a very, very significant one word change, "must" to "may," which substantially changed the meaning of a global policy proposal, and that one did not move forward.
John Curran: To respond, Jason, for clarity - I might have misrepresented this - this is only to develop ARIN's initial document. Truly, once we're done, they need to be combined in some manner. And they need to be compared, much like the NRO Number Council does, and responses need to come back to the community about what doesn't compare. We were going to actually try to put together a brief body to do it. We could use the Number Council if that's what people want. But very much the process envisioned, as Vint said, is we do an initial submission, the other five do - the other four do, and it's exactly the process that's used for global policy. So if that's inappropriate, I need to know.
Jason Schiller: It's not clear from on the slide in Bullet One at the bottom there that once these things are combined and stuff falls out, that the combined document and the stuff that falls out will be re presented to the communities and discussed to try and get further harmonization or approval. And I think we need that step.
John Curran: This truly is only the ARIN region process. And the RIR wide one needs to be written, and it's not decided, and I'm looking for input to bring to the other RIRs on how to do that. I got it. Other people, on the overall global process, should we use a single global process or five RIRs merging into one?
John Springer: John Springer, Inland Telephone, ARIN AC. The RIR system of the five regional registries is in place. The attempt - if we were to all stand up here and go, "Yay, global process," and Milton didn't have the time or the ability to get to the other RIRs and they all continued on their merry way, would have the effect of disenfranchising this community's input to the process. So the RIR system is what we have. The other four RIRs have already produced their preliminary documents. We need to proceed as a Regional Internet Registry and produce our preliminary document.
John Curran: On the global versus regional process. Middle microphone.
Seun Ojedeji: I'm Seun from Africa. I'm from Africa. I represent - I'm from the AFRINIC community. I'm also one of the chairs of the AFRINIC Policy Development Working Group. I'm sure John would know that. I've sent him some personal emails, also to other RIR's CEOs. Maybe we should actually be discussing with the NRO because it looks like perhaps we'll talk about this globalization. Maybe John is not the right person to be responding. I think you're trying to introduce what the community is not used to. We're used to the Global Policy Development Process. And if there's something that needs to change, then you need to present it to the community. If you're going to change the process, let us know about it. NRO does not decide the process for the community.
So I think when you were saying that we don't know how to get it, we have not yet decided how to get the contents together (indiscernible) starting from the middle. That's the first thing we should resolve, how do we get the contributions from all the regions. And there's actually a process existing, which is the GPDP. It's very, very functional. I don't know why it's difficult to - yeah, the GPDP goes to ICANN. It doesn't need to go to ICANN. This is something that involves all the community. So we should go through the GPDP. You said there's going to be a survey. If that survey is going to be used, let us all respond to the survey. The same format, let's get - let's get different views and that's how you can collect the effectiveness on this.
I don't understand the fact that we have at this point trying to disconnect ourselves. Please, John, I will really appreciate if the NRO chair could respond to this. And my question is: Why are they not using the GPDP process?
John Curran: I'm not the NRO chair. Paul is.
Seun Ojedeji: Excuse me. Milton just said it's not a policy. Yes. It's not a policy. But this is something that involves all the regions. It's global. So it should be (indiscernible) we are used to. We're used to - within the different communities, we're used to discussing things at global level using the GPDP process. So let's just, if you want to introduce a new process, send it to all the communities and let's agree.
John Curran: I can address what I know. I can't speak as the chair of the NRO. But I can say so the Global Policy Development Process, for the fastest global policy that went through it, took - I'll look for Jason. Jason, what do you think the fastest Policy Development Process was? A year and three months? I'm thinking. A year and three months on a pretty express path to get something through the Regional and Global Policy Development Processes. It was felt that if we give our submission to the ICG at the end of 2015, that might be too late for them to do anything with it. So what we wanted to do was hold effectively very abbreviated development processes in each region. Convene a number of people - for example, we could take the ASO AC representatives from this region just as the others do. But to call it the Policy Development Process, it would be wrong because we're going to do it on a much accelerated timeframe. But something very similar, only on a much shorter timeframe, is what the NRO was thinking.
Seun Ojedeji: What you're presenting right now is not something similar. What you're presenting right now is something totally different. Because we're doing things in our own silos now, and I fear this may even take more time. We should have - if we're going to get our views from different communities, let's come up with similar, the same, questions, several questions, distribute it to us. Or let's get different views on those specific questions. Now we have different processes. It doesn't help.
Jason Schiller: I'd like to respond to your question. So the long pole intent here for global policy is we have to get text in front of each of the five regions and run through their local Policy Development Process. And that text has to get supported by each of the communities. In all of the regions that requires a face to face meeting. So you have to hit at least one face to face meeting in every region, which is theoretically possible to do in less than a year. I think we've passed a policy proposal in just under a year and a half. It's not uncommon for it to take two years. It's not uncommon for this community to discuss a local policy and for it to be two goes at two face to face meetings. So that's really a year before this community could have a final product for which the other communities could work with and merge into.
It's important to note that this process is a very long process. It's important to note that our time constraints don't support that. I think what would be helpful to some of the people in the room is to show how the process you have here parallels the Global Policy Development Process and how it is different and why - and I think the major difference here is we can't wait for a face to face meeting. So we have to find another way for the community to participate and to find consensus. And I think that's what you've done. My personal complaint is that based on my read of the bullets it doesn't sound like the final product comes back to the community for final ratification. And I think with that modification we have something that is fairly similar to what global policy today looks like.
John Curran: Thank you. Back microphone. I'm going to be closing the mics. We have a lot of topics. I'm going to be closing the mics on the topic of global versus regional processes. Unless you're speaking about global versus regional processes, step back from the mic. Okay. Back microphone.
Bill Darte: Bill Darte, ARIN Advisory Council. Seems to me that the global process is the one that can accommodate the timeframe constraints best. However, I think that if there's a way to concentrate across regions on core principles first and then iterate through greater detail, that would perhaps be a task.
John Curran: Other remarks on global versus regional? If you have a remark on global process versus regional. Yes, Milton.
Milton Mueller: If I'm the only one in the queue, I will go ahead and -
John Curran: On that topic, global versus regional.
Milton Mueller: I think the practical constraints on going through a regional bottom up, the point has been made particularly by Jason. This is just not viable within the time constraints. The other point I want to address is that it's not a policy we're talking about here. I understand when you're dealing with address allocation policies there are different regions with different practices and operations that need to be coordinated on a bottom up basis. We're talking about a global entity, the fate of the IANA, and I think that's a global topic and we should get together as soon as possible. However, I'm not against the regions having their own consultations and lists. I'm not against that at all.
I simply think that we need to have a global process in place immediately, and there's nothing stopping us from starting a global list and getting the other ones to buy into it. Or let's just say everybody joins the APNIC list. That seems to have some traffic. I don't care about that. There's one final point that I think is crucial here that you're kind of understandably forgetting, which is that this is not just about the RIRs. This is supposed to be an open process. The RIRs are obviously going to be leading players in anything having to do with address allocation, but you have to be open to other stakeholders; otherwise, you will not qualify for our process, the ICG process. We will look at your proposal, and we'll say: Did you shut people out? Did you really have consensus? If you just have a committee of five people at the NRO putting together this proposal at the top, I'm not sure that will qualify.
John Curran: To be clear, the committee at the top isn't supposed to put together the proposal any more than the ICG is. The regions are supposed to iterate their proposals till they line up. I want to be clear on that. Not supposed to be a creative effort in the integration any more than it's supposed to be at the ICG, Milton. Anybody else on global versus regional?
Kevin Blumberg: Kevin Blumberg, The Wire. Can I get a clarification on who Milton is speaking on behalf of? Is he speaking on behalf of the ICG as the body? Is he speaking on behalf of himself? I'm sorry, Milton, it's actually -
Milton Mueller: Speaking on behalf of myself as a member of the ICG.
Kevin Blumberg: Thank you. That clarification is important for me. As far as global versus regional is concerned, if we go global, which I don't agree with in this particular case, we'll have a situation where decorum will get thrown out of the window because of regional differences. The list will grow to a size that nobody actually wants to be on it because of the volume of chatter. So we will actually have the reverse problem by having a complete inclusion globally. The people that you actually want to hear from, the community you want to hear from that you want open will be completely disinterested in participating in that situation. So I do support doing this at the regional level. The last -
John Curran: Let me ask one question. Are you against using a global list to integrate the regional proposal?
Kevin Blumberg: I'm not against having a global list once the -
John Curran: Once there are five strawmans.
Kevin Blumberg: Exactly. But the very last part to this was sort of part of all of this. We have to keep in mind that each country, not just region, but each country has some peculiarities. ARIN deciding as a community to pre fill a Mailing List could very well run offside of Canadian law. So, yes, submitting it out to all the lists, but starting with a fresh list is probably the appropriate way to go.
John Curran: One last question on that. There's an ARIN consult list open to anyone which we use to hold consultations on. Could we start with that list? Do you really want a fresh list for the region?
Kevin Blumberg: I think we should just go with a fresh list.
John Curran: Global versus regional. Middle mic.
Tim McGinnis: Hi. Tim McGinnis with NABP, but I'm speaking in my own personal capacity. I think that Vint's point was very valid. We already were used to doing this regionally. I think it will be far simpler to harmonize five positions rather than 500. So I would vote for the regional, and I'm agnostic about a new list or an existing list.
John Curran: Tim, can I ask a question? Milton in his wisdom as an individual but informed as an ICG member indicated we have a concern about openness. So would you believe that both the regional processes need to be open to anyone to participate, and the global list that's considering those five positions also needs to listen to new positions as they come in?
Tim McGinnis: I think having experience in at least three different regions over the last 15 years I understand that openness is part of the design of the RIR process, and I would assume that the consultation and discussions would be open as well. So I would have no problem with the openness about that. And the second part of your question?
John Curran: Specifically you said it would be easier to harmonize five proposals than 500. But if you get five but two people also submit them, so you have seven, you really - are you really saying we only consider five or consider the seven that we receive, the five that come from the RIR and anything else that's a substantial proposal that comes in?
Tim McGinnis: I think that they should not discount any proposal.
John Curran: That's what I want to know. Just want to be clear. On global versus regional, back microphone. Global versus regional. Front microphone. Sorry. Front microphone. Owen.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. It seems to me that the bottom up process works and has worked well throughout the years and is the best way to do this. I think the regional up to global process has worked well for the global policies we have so far, and I think it's what we should all have. Having said that, it seems to me the one thing it doesn't do well is act with a great deal of speed. Trying to achieve any sort of useful global stakeholder representation in the time between now and some number of months before September 2015 strikes me as patently absurd. And no matter what process you use. It's just not enough time to engage a community that large in a meaningful way, distill all that input into some single useful output and present it in a way that actually is representative of anything other than the most determined, most vocal people with the most time on their hands.
John Curran: To respond, to be clear, I do know that there was a direct response from NTIA in response to questions at one point that said what happens if we're not ready. And the response was, well, we could - if you folks are not giving up but you're still working, we can say, okay, let's continue for a year and keep working. My question to you is, in light of that, are you advocating that it may take a while to get a good answer? Are you saying we intentionally slow down and presume we're going to take more time and not try to hit the deadline of trying to have something ready for next summer?
Owen DeLong: I think this is important. I think it should be done deliberately. And I think we should ask NTA to move the deadline out to 2016 at a minimum as being a much more reasonable way to do this deliberately.
John Curran: Good to have. I want to have other questions on the process. By the way, we have to save ten minutes to talk about some of the survey questions. But on process, all topics, microphones are open. Middle mic. Go ahead. That's you.
Seun Ojedeji: Seun again speaking in my own capacity. I just want to make two points. We've discussed this - I have no problem with - certainly not the global Mailing List. I don't even think that will be useful because that's not what we've been doing. It's okay to have the discussions within the regions. But my concern is that we don't have a process to actually collect - effectively collect these discussions. We're saying that - when we present a proposal, we want to say that this proposal received community support. It received consensus from the community. But the process we have right now would not actually justify that, because all we have right now is I could ask you to - right now on the AFRINIC Mailing List, the one that was set up for this discussion, during the discussion you see that there is announcement of what is happening. And I've been on the other Mailing Lists, APNIC Mailing List. Discussions are not happening because there's nothing to discuss.
John Curran: What process do you propose to solve that problem?
Seun Ojedeji: What I propose is that we - NRO come up with a track of questions, similar questions that all the committee will work on and we present the response. Because that's what we do in GPDP. It's in concert with the Draft Policy and everybody discuss it from their own community and everything goes on fine.
John Curran: We actually have that - that's why we're doing a survey. The questions we're asking are very similar to questions asked in the other regions based on the same basis. Literally the questions that we're going to talk about in a moment, the survey questions, I have come and have been coordinating with the other RIRs. They're part of the presentation at APNIC. They were asked in the RIPE. So we are working on a common basis of questions.
Seun Ojedeji: But we haven't seen the process with which you use in actually bringing these questions together and presenting it to the community. The NRO needs to come up with the complete process. Don't put the community in suspense. You're putting us in suspense by not presenting all the process from the beginning. Present all the process for us. Let us commence on it. Let us agree on it, then we'll continue. You've just told me now that the questions are going to be the same. I didn't know this before. It was not written anywhere on the NRO website that these will be the same questions that would be sent.
John Curran: And that process that the NRO has to give you for how this is going to come together, we actually didn't want to come up with and just say: This is it. Congratulations. We actually wanted to have a few of these meetings and get input on that process. And we've gotten good input, and now we'll come back with how to integrate these together.
Seun Ojedeji: Where is the process? This is not a process -
John Curran: This is only the ARIN region. This is only the ARIN region. Back microphone.
Seun Ojedeji: John, I think - I think what I want to say - I'm going to repeat myself again - I think we're missing - we're not starting this thing from the top.
John Curran: I'm sorry, repeat.
Seun Ojedeji: We are not - we actually - we are missing the global part of this, which is we need to present a global process first, because this is not going to - this is not the manner with which we normally use. Let us understand what NRO is going to use, what process you're going to use to collect this, to bring together these survey responses. Are you going to get a team of people from each community to look at this, come up with the final draft? These are the things I need to know from the beginning. Is there going to be - there was a timeline to when the draft would be presented back to the community and when the community would make comments, et cetera, et cetera.
John Curran: Are you proposing we put the ARIN regional process on hold until that's available?
Seun Ojedeji: Yes, please. Thank you.
John Curran: Back microphone.
Marc Lindsey: Marc Lindsey, Avenue4. I'm going to hit you from the other side. The question I have here is the ARIN community is a consistent group, but what are you going to do to reach out to those who aren't regular participants in the ARIN community? Because, as Milton points out, there are stakeholders who aren't regularly involved in this process who may have some comment on what the stake - a switch in the transition might look like. So what is ARIN going to try to do to get more participants than those who are typically on the consult list or PPML list or whatever it is?
John Curran: I gave this presentation to talk about the IANA changes going on. I've given this presentation at NANOG earlier this week, many of whom are ARIN members but many of whom are not ARIN members. We've given several representations. I've been on the road four, five times this year in various forms. Like, for example, at PTC, Pacific Telecom Council, we presented and informed them there's an IANA stewardship activity. Many of the RIRs are doing outreach outside of their RIRs saying there's an IANA transition stewardship planning process going on and that people need to get involved. But other than announcing it so people know it's open and they can get involved, I don't know what else you're asking for.
Marc Lindsey: I think, first of all, to have a commitment as a part of the process to include those who aren't typically a part of the ARIN community, that ought to be a part of the obligation to think creatively about how do you contact those individuals to get them to participate on the Mailing List and having that as a formal part of the process internally to gather that from within the region and not necessarily within the ARIN community alone.
John Curran: This is for the region, not for the ARIN community alone.
Marc Lindsey: I know, but I'm just saying can you have (indiscernible) as part of our obligation will be to proactively get - and continue to do what you're doing. You say you're doing it, and I appreciate that - but proactively say that's a part of our process to gather more -
John Curran: Acknowledged. Last couple of questions on the ARIN region process.
I've got Bill at the middle mic.
Bill Sandiford: As sympathetic as I am to our AFRINIC colleague's assertion that we should look before we leap and have some sort of plan for how we're going to globally coordinate, I have to be a little pessimistic on this one and say I think the chances of us coming to any convergence on a global coordination mechanism before it's overtaken by events are zero. So if we want to have something to say and we want to be heard, we have to just go ahead and do it. But if we wait until we all agree on how we're going to come to agreement, it will be too late.
John Curran: Center front.
John Springer: John Springer, Inland Telephone, ARIN AC, speaking on behalf of myself. So one component of what the NTIA said this must be is bottom up. The bottom is here. The bottom is not in a new global Mailing List somewhere else. Second of all, the ARIN staff is going to be the secretariat of this process here, correct?
John Curran: Correct.
John Springer: That's a little top-downish itself right there. But it's what we got.
John Curran: If someone wishes to volunteer to be the Secretariat for this process, come to me now, because, frankly, I would be relieved.
John Springer: My only point is that decisions have been taken, and we need to get a wiggle on them. The NTIA statement came out in March for all of the RIRs, and we have four RIRs in the statements and we have none. Going forward, how do we run this along. We could have asked the survey at Bellevue. We could have had it at NANOG on the Road. Let's get a move on, please.
John Curran: We're getting a move on. Okay. Got it. I want to move on to the ARIN region question. So in the Mailing List, next week, we're going to call all the ARIN members and say - we're going to send an email out saying you need to survey. I'll tell NANOG you need to answer this survey about how the IANA stewardship should be done.
And we're going to ask some questions and get responses, and those responses are what you people are going to be looking at two weeks from now, trying to craft text based on the answers and how the survey felt. So it is crucial that questions that you want to see answered I hear about. Now, I'm taking questions that match some of the materials that the other RIRs have done, and I now need feedback as to what we're actually going to survey people on next week. Do you want to not ask questions? Are there questions that you don't see?
Let me talk about the ARIN survey questions. There are three of them. And we would normally poll these, and it would be yes, no, or any comments for each of these. So the first question we send to the community is: Do you agree that the following points are the primary priorities for the ARIN community with respect to the IANA stewardship transition planning? There should be minimal operational change. The current processes for the IANA operation and related policy making are effective and allow for the participation of all interested parties. Any new oversight mechanism should incorporate and build on the existing RIR community, policy making processes.
And the RIR communities are ultimately accountable for the management of those IANA functions relating to management of the global Internet number resource pools, and this should be reflected in any new oversight mechanisms. That's question one.
Also - what I want to know: Is that a good question to ask? Does that question need to be broken up in any way because you have "yes" for part of it and "no" for other parts? I heard that on the list, and I'm going to ask people to come to the mic and talk about it. Question two: Do you agree that a model for IANA oversight endorsed by the ARIN community should include the following elements? ICANN has historically managed the operation of the IANA functions well and should continue to do so at this time.
The IANA functions operator must be answerable and accountable to the community it serves. The number resource community is represented in such accountability processes by the membership based Regional Registry organizations. Funding arrangements to cover the staff, equipment, and other operational costs associated with the operation of the IANA functions should be transparent and stable. Same question: Is this a good question to ask to feel if you guys think yes or no? Should it be broken up into pieces - one piece, two pieces, many pieces?
Last question: Does the community feel it has no position, per se, on ICANN accountability mechanisms - aside from the IANA. So we're not talking about IANA accountability; we're talking about ICANN and all of its other joy dealing with DNS - i.e., other than the principle that the DNS community must be satisfied with any process before an ICANN transition? Whatever ICANN comes up with, accountability has to meet the DNS communities' requirements. We don't have requirements. Is this a good question to ask or not? We have three questions. We have - we're 26 minutes over for time. I'm going to take five or ten minutes to get feedback on these questions, and then we're going to break for lunch. Microphones are open on the ARIN survey questions. Back microphone. You missed it, Matt.
Kevin Blumberg: Kevin Blumberg, The Wire. I think the ARIN community has a hard time with omnibus proposals let alone omnibus questions.
John Curran: Do you not think we should do a survey?
Kevin Blumberg: I'm happy with the survey. All I was going to suggest was for all of these bullet points it should be, A, yes to all of the question, yes to each bullet point, or you can selectively remove out your support, or you could have no support. But each bullet point should be separated out; otherwise you're in omnibus scenario, and I don't think you'll get the results that is good for the community.
John Curran: Break them all out. Got it. Yes. Front.
Matt Petach: I was going to say you do wonderful job of, when doing votes, being clear and specific. Please apply the same logic to survey questions here. I would ask in terms of survey questions: Is there any thought towards the forward moving how do we change the governance model going forward? We seem to be looking at kind of how do we cast something in concrete and we're not asking about what methodology might be used for iterating or evolving this in the future. Is that out of scope for this?
John Curran: You want an open ended question to the effect of are there any structural changes in the model for stewardship of the IANA that should take place free form box and we'll aggregate all of those in the survey response.
Matt Petach: Awesome. Thank you.
John Curran: Middle microphone.
Jason Schiller: Jason Schiller, Google, ASO AC. I think it's covered in the questions when I read between the lines carefully, but I would like it more explicitly stated. I think Questions One and Two do cover that this community should specify the SLAs that are measured for IANA services and specify how they're measured and that the results of such measurements should be reported back to this community, and if those SLA measurements need to be moved at some point in the future, that this community be the ones to do it. I think that's covered in Questions One and Two but not explicit.
John Curran: I could create an omnibus Question Four that said with respect to SLAs, do you believe the following - A, B, C, D? I'll save time before Matt jumps to the mic or Kevin. Can that be an omnibus question, or I need to break out those points individually?
Jason Schiller: I think in general just make these all separate questions that are grouped together under like topic and let people tick off, yes, no, I don't know, whatever.
John Curran: I'm closing the microphones. If you have comments, approach quickly.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. I think that these are good starting questions. I think Question Three needs a free form box of "If you said no, what opinion do you feel we have" or some other way of saying - a no answer needs explanation.
John Curran: Correct.
Owen DeLong: Or it's kind of useless. And I do support breaking all of them out into individual answers because there are many cases in the questions where I would answer yes to some and no to others.
John Curran: Thank you. Last queues closing. Approach the queues. Ten, five, four, three, two, one. Last speaker. Mr. Milton Mueller.
Milton Mueller: I get the last word, John. Tremble.
Milton Mueller: This survey is, in my opinion, a complete farce. I really think it's a textbook case of how to manipulate public opinion. And you people have the temerity to talk about a bottom up process. What you've done is you've worked out your principles, you've worked out what you want, and then you put a bunch of questions in front of the community that say: Do you agree with this?
John Curran: So we have difference of opinion. We have people saying that we should get a list of questions and then use those to help get alignment between the RIRs and -
Milton Mueller: I don't understand why you need to do a survey at all. If you want to have a process, just let people put forward the questions that they think are important in an unconstrained manner, and then - see, what you're going to do is you're going to get the - naturally you're going to get responses, and most of the people who respond will be people in the community who agree with you, and then you'll say: Look at this. 40 percent of the ARIN people agree with our position on this. And, I mean, that's just a totally top down manipulated process -
John Curran: Let me ask two questions. Because the first question I asked is should we do a survey at all, and most people have said yes to a survey.
Milton Mueller: Did they?
John Curran: Well, that's the question. I asked people: Do you want to do a survey? Two speakers both said yes.
Milton Mueller: Two speakers. Here is one that's saying no.
John Curran: If the questions have a slant, the answer to that would be to add other questions that don't have a position or to alter these questions. Can you propose changes to them to make them more neutral?
Milton Mueller: I could propose changes to the end, until the cows come home.
John Curran: Would you do so now?
Milton Mueller: Now? I thought we were out of time.
John Curran: I have another question, Milton, which is one of the things that helps get a proposal from the region is to actually be able to gauge how the community feels about some of these issues or maybe other issues, maybe you have
other questions you'd like to know how the community feels. It's impossible on a Mailing List to gauge overall community support. All you can see is messages per minute from people. That doesn't give you a poll or a measure or a show of support. So my question would be, short of a survey -
Milton Mueller: I yield my time to Mr. Farmer.
John Curran: Milton, short of a survey, how do we give the community faith that its starting point is backed by this community?
Milton Mueller: You could start out with the criteria submitted by the NTIA as to what the IANA transition has to do, and you could say how should we accomplish this.
John Curran: And take free form input from everyone?
Milton Mueller: Yeah.
John Curran: Shall we just make that Question Five? Is that what you want?
Milton Mueller: No, I want to get rid of the other questions.
John Curran: I'm sorry, repeat.
John Curran: I'm trying to accommodate your requirement. This isn't a proposal. This is a set of questions. And they can be rephrased to be more neutral if that's what you want. Or whatever you think the objection is to them. Bill Woodcock: I'm sure Milton would be willing to summarize all the responses into one nice concise one.
John Curran: Back microphone.
Kevin Blumberg: Just very quickly, just to maybe help Milton out. Can we have a show of hands, John, on the survey questions?
John Curran: So are you asking on the survey questions or whether we should have a survey or not?
Kevin Blumberg: Yes, the first, whether we're going to have a survey or not.
John Curran: Survey based on this set of questions.
Kevin Blumberg: Correct.
John Curran: Could we have a - presuming we break up the questions and we add the free form box as requested, we add a set of questions for SLA, as noted by Jason, does this community believe that a survey sent out to the community that's open to everyone, not just ARIN members, but NANOG, anyone who answers the survey, will be helpful in forming a response? If so, raise your hand. Nice and high. I don't know whether we need to tabulate this. Take it down.
How many believe it would be a farce? Okay. We're going to proceed with the survey, folks, because most of you think it's a good idea. You can take the output, and, if you think it's a farce, not use it in your responses to the regional list that we set up for this purpose. If you think it's useful value in submitting your suggestions, then consider the survey responses. Okay?
Jason Schiller: Jason Schiller, Google. Rather than characterizing it as a farce, could we just ask how many people think a survey would not be helpful?
John Curran: Jason, it was overwhelming. Okay? Don't worry. Sit down. Thank you. Middle microphone.
David Farmer: David Farmer, University of Minnesota, ARIN AC. With all respect to Milton, and I do understand his issue, we earlier talked about we want to try to model this on the Policy Development Process, et cetera. Our Policy Development Process is a very important thing. It's the problem statement. So when we're considering policy, we try to have a clear problem statement that - for what we're considering. That's what this survey is trying - is trying to consolidate something into something that people can react to, because otherwise we're going to end up - otherwise I fear we're going to end up with a blank piece of paper.
John Curran: We're now five minutes late for the 30 minute late lunch.
Scott Leibrand: Scott Leibrand. I have to support what Jason said. I think the characterization of the no response to that question of it's useful as being a farce was inappropriate, and I believe that if the community does believe we need a survey, which probably is true, I believe there is definitely some work to be done on making sure that the survey questions are not leading, which I believe is the primary concern that Milton has addressed, and I would advise you to do that before the survey goes out.
John Curran: Milton's concern was a survey taking place at all more than the phrasing of the questions. But noting two objections now, can I get the polling engine set up, please? Polsters, get ready. On the matter of whether or not ARIN will conduct a survey based on the questions presented, broken out into individual items, and adding the SLA requirements, I'd like to have a formal poll. This includes the remote participants and a free form question as required for any other changes to the system. I would like a show of hands. I'm going to ask everyone in favor and everyone opposed. This includes everyone in the room and remote participants.
All those in favor, raise your hand. Nice and high. All those in favor of conducting a survey based on those questions broken out to individual questions, with questions added for SLA, and a free form question as requested by Matt, raise your hand. Please keep your hands high. We need to allow time for remote participants. Keep your hands high. Are we good? Thank you. Okay. Everyone opposed raise your hand. Nice and high. Remote participants as well.
Got it? Thank you. We'll get the survey results. Okay. Sean, go ahead while we're waiting for results.
Sean Kennedy: Sean Kennedy, XO. The one thing I did want to say is I think that some of this debate is valuable, but it's also valuable to get the process moving forward. So I think we can move forward with whether we go with the survey or not and with getting a Mailing List going, get community input, debate the process, debate the processes with RIRs, bring back any edited responses and stuff together and debate it. If we keep discussing the process forever, I think we'll just end up delaying the whole point of this, which is to get the community input. That's what we should focus on.
John Curran: Thank you, Sean. I'd like to now close this, and we have the survey results coming. Okay. So on the matter of whether or not we proceed with a survey, number in the room, 165, plus 7 remote; 172. Those in favor, 56; those against, eight. We shall proceed with the survey. Okay. We're now going to have lunch. We're running a little late. If we were to stay on our normal schedule, you would have a wonderful 52 minutes for lunch. We need to do a little better than that. So we're going to resume at 1:45. That's 15 minutes later than scheduled. 1:45. That means, everyone, you have just over an hour. I will see you back here at 1:45.
ARIN Board & Advisory Council Election Procedures and Candidate Speeches
John Curran: Welcome back. I'd like to congratulate Ron da Silva. He's been appointed. ARIN Number Council slot is elected two years and appointed to the third. ARIN Board reappointed Ron. Ron can't be here. He's out running an errand. He's very enthusiastic. He'll be back tonight. But round of applause for Ron da Silva. Remember, turn in your ticket to get your T shirt. Beautiful orange T shirts out there.
Today's agenda. We'll pick up with the AC and election procedures and candidate speeches and software update. We have policies 2014 14 and 2014 20 regarding removing needs verification; ARIN Draft Policy 2014 1: Out of Region Use; 2014 16: Austerity Policy Update; we also have 2014 17 on utilization requirements to total aggregate; 2014 18 on simplifying minimum allocations and assignments; and 2014 19 on allocation based on past utilization. At the head table - it's empty. It's myself and Heather. She's our remote volunteer. Welcome back, remote people. Because we're actually going to be doing the candidate speeches. So it's just myself up here. So I'm going to move right in. I believe I have Jud Lewis coming up to talk about the ARIN Board and Advisory Council election procedures. Come on up, Jud.
Jud Lewis: I figured I would fancy it up a notch this time around. Today I am here to talk to you about the ARIN election procedures, how to vote, and just a quick, brief overview before we get to a very exciting slate of candidates who will deliver short speeches for you. First off I'll give you a quick rundown of the election process. This year there's a Board and Advisory Council election. And who can vote in it is designated member representatives for each ARIN member organization. How do you do it? If you're the DMR, we will email you instructions at 3:00 p.m. Eastern Time today. And follow those instructions, and you'll be able to log in and access your ballot.
What makes a DMR eligible? The voter cutoff date for the 2014 ARIN elections was the 11th of August. So any changes that have been made after that point to designated member representatives will go into effect for the 2015 ARIN elections. So you had to be on the DMR at that point. Your email, DMR email, has to have name and initials and match the organization's domain. And you have to be in good standing with ARIN as of that time. Here's a calendar. And here we are. Voting is going to open, as I mentioned earlier, at 3:00 p.m. Eastern Time today. Tomorrow the exciting speeches you're about to watch will be posted and available online. Then ten days later, on October 19th, voting closes at 3:00 p.m. Eastern Time.
And then later that week, no later than Friday, we will send an announcement to all the voters and to ARIN Announce of who the winning candidates are. All right. So now I'm going to talk about, walk you through, there are two ways to vote, to access your ballot, both detailed in email that you're going to receive if you're the voter at 3:00 p.m. One, if you have an ARIN Online account, you go here to www.arin.net. Then you log in with your ARIN Online info. Then you go to Election Headquarters and click the Vote Now button and, voila, you will access your ballot. Method two, if you do not have an ARIN Online account. Here's an example of the email DMRs are going to get at 3:00 p.m. today.
Open your email, Step One. Step Two, click on that URL, and you'll automatically access the ballot.
Here is what the ballot's going to look like. In lieu of our candidates, we have the Beatles here to help demonstrate. First off, you're going to see the Board ballot, and you select up to two candidates for the Board. And you click Submit Vote, and then you'll advance to the Advisory Council ballot. You can select up to seven candidates for the Advisory Council. Then you click Submit Vote, and then you're done. If you're so inclined you can click there and you can see a voting receipt. Also it will be automatically e mailed to you as well and it will look like that. Okay. Now, there are - that's easy. But there are also - some DMRs can vote on behalf of more than one member organization. And if you fall into this category, I will briefly detail that process as well.
You can see here in this instance it says you have a total vote weight of six. That means you can vote on behalf of six member organizations. The default in the field is six. If you don't touch anything, if you don't change that number, then you will select your candidates, click Submit Vote, and you will vote on behalf of all six of your member organizations for whichever candidates you select. But let's say I have my six votes here, three of my ORGs want me to vote one way; the other three of my ORGs want me to vote the other way. So here's how that process would work. I would select the candidates. I would reduce the vote weight field there, change it from six to three. I'll select - let's go with Ringo Starr and John Lennon here. And then the ballot screen will reappear, and you'll see that you have an unused vote weight of three. So you can now select your other two candidates, click Submit Vote. You have now voted on behalf of your multiple member ORGs.
Everything I've talked about is also going to be covered in detail in the email that the DMRs are going to receive. Do you have any questions for me, before we get to the candidates, about how to vote? All right. I'll bring up John, then, who will introduce our candidates.
John Curran: First we'll have the Advisory Council candidates come up, talk to you about why you should vote for them. First AC candidate, Daniel Alexander.
Daniel Alexander: I'm up here once again asking to serve on the Advisory Council. A number of pretty qualified AC members have recently left. They're moving on to other things. And we're also I think kind of in a unique situation where almost half of the AC is actually being selected this month during this election. So I just wanted to offer up my experience and ask for your support to serve on the AC again. Thanks.
John Curran: Advisory Council candidates. Kevin Blumberg.
Kevin Blumberg: You might have seen me at the mic a couple times. I'm not a shy person in any way, shape, or form. But I want to give you background on myself. I'm an operator and I'm a businessman. I own my own company in Toronto, Canada, a little north of here, and I've been running the network for the company for many years. So I bring a very diverse background. I enjoy this stuff. "This stuff" being regulatory related governance. I thrive on it. You can only do operational things for so many years before you realize that there's a bigger picture and there's a bigger group of people that need your consistent help with. You need to have a community that's even in how it gives out its resources. No one group of people should benefit over another group.
That's what I've enjoyed about ARIN, is to be able to take my experience from the operator point of view and the business point of view and try to see things as I know I'm a small guy, I know I'm a small company, but if I was a big company, what would be fair? If I was a small company, what would be fair? If I was a company that was a nonprofit or a profit or this or that, what would be fair for everybody? And for me that's been sort of my guiding philosophy with my first term on the Advisory Council. So I look forward to your support. I appreciate the support that's been written already. If anybody has any questions about what I have said in my bios, as an example, or my questions, I urge you to come up. And look forward to another three years. Thank you.
John Curran: Advisory Council, Mike Burns.
Mike Burns: Hi. My name is Mike Burns, and as you can see from the slide, I'm an address broker, the new kind of stakeholder in this community. Unlike network operators who make their money by running networks using IP addresses, I'm looking to make money by actually transferring addresses. And it's a different thing. I understand that. But I'm also a network operator with deep roots in the Internet. I had an ARPANET account, believe it or not, back in 1978, and I continued working with computers and networks. I founded my own business in 1986, which I still run. We're a network operator. We've got an ARIN allocation. I've done acquisitions in the past, and as part of those acquisitions, I've actually returned addresses to ARIN. So I think that I've had several interactions with ARIN.
I'm a policy author. I got involved on the PPML about three years ago and successfully authored a proposal which was eventually implemented. During the discussion of that proposal, I did modify it based on community input, and I think that indicates that I do have an open mind. Currently I have two policy proposals that are being discussed today, one of them earlier and one after this, I'm sure. And I ask for your support for election to the Advisory Council where I hope to continue to offer my input and my insight as a distinctly different stakeholder from the rest. Thank you.
John Curran: Next up, Andrew Dul.
Andrew Dul: Good afternoon to those of you in Baltimore and to those of you watching on the webcast. I'm Andrew Dul, and I've been serving on the AC for just this past year. First, I want to thank you for giving me the opportunity just this past year. While I've been involved with this community for many years and served on the AC ten years ago, it's been interesting for me to look at what has changed and what hasn't over the past ten years. Today I'd like to spend just a few minutes commenting on things that have changed and what hasn't. Mostly what I've noticed is we're kind of not following and focusing on our long term goals. It's very easy in the policy process for us to get caught up in the details. Not that the details aren't important, but being caught up in the details, we sometimes lose fact of where the Internet is going. Today there's no denying that the Internet is fundamentally changed so many things about our lives and our economies and also affects the stability of our society. Because the Internet is so important, we all bear responsibility for ensuring that the public resources that we help manage are managed in a way that encourages stability, and we also bear responsibility to listen to those stakeholders and attempt to balance the sometimes conflicting needs of different organizations.
We need to build those into a policy which fosters growth and stability for the Internet as a communications platform. And since I believe that is so important, I've been talking with the members of the AC and the community about what ARIN should look like five to ten years from now when IPv6 is the dominant protocol but IPv4 is still hanging around for interoperability. I've been asking questions about what's the fundamental role of ARIN and the RIRs. My goal in these discussions is to help us foster thought amongst the community and the AC to possibly create a future policy framework that would help us focus more on long term strategy rather than on another tweak of the policy manual in a minor issue.
I think by taking some time to think about where we're going, we'll be able to actually craft better policy over the long term. If you have any questions, I encourage you to take a look at my blog, which is noted on the slide here, or I'm also available for questions or email for those of you who are remote. Thank you for your time today, and I encourage you to vote in the upcoming election and thank you for your vote.
John Curran: Next up for the ARIN Advisory Council, Robert Duncan.
Robert Duncan: Good afternoon. I'm Robert Duncan running for the Advisory Council today. And I approve this message. I've been around the IT industry for - that says 35 years; that should really be closer to 45. I started Fortran programming part time for six dollars an hour in 1967. About that time a fellow from GM I ran into said: Hey, kid, go into networking. And I followed that advice and pretty much have been there ever since. I worked at a hardware vendor for a number of years. Currently I'm working at Merit Network. One of the things that I - I've been involved with ARIN for about six years now as a delegate from Merit. I didn't have much time to contribute a lot to ARIN in those times, but I'm retiring next year. I'll be moving into - phasing into part time retirement, and I should have a lot of time to be able to volunteer for ARIN. So thank you for this opportunity, and that's all.
John Curran: Next up, candidate for Advisory Council, David Farmer.
David Farmer: Hello. My name is David Farmer. My day job is with the University of Minnesota. Please take your time to look at all of the candidates and vote. And that's all I'm going to say for now. Thank you.
John Curran: Okay, next up for the Advisory Council, Nick Guy.
Nick Guy: Good afternoon, everybody. I appreciate the opportunity to introduce myself to you to those I've not met. I've been in the network industry for about 20 years, both in the private and public sector. Before that I worked in social services, and from that place I really learned to develop a sense of the importance of policy and the fact that you can build things, you can build systems, you can build networks without good solid policy, it's really difficult to scale them. For about the last ten years I've been involved with pushing broadband to rural parts of Washington State, and I've been heavily involved in that. I'm interested in more volunteering, which I think is absolutely critical for the good of every community.
And if you vote for me, I will check my ego at the door. Thank you.
John Curran: Next up for the ARIN Advisory Council, David Huberman.
David Huberman: Good afternoon. As Mike was indicating, he's a new kind of stakeholder as an address broker. I was getting up here saying I'm a new constituent too. I was an ARIN hostmaster for ten years. But then I remembered Dawn Martin. Dawn Martin was an ARIN staffer in the early days, and then she became part of the AC when she was at UUNET, did a great job. I think I bring a unique set of experience. I've been doing this for 15 years. I've worked in IP addressing and IP addressing policy solid for 15 years.
I now work for Microsoft. Microsoft is a very large consumer of IP addresses. But Randy Bush taught me a very important lesson a long time ago, which is, first and foremost, we all work for the Internet. And I'd like to think my actions over the last 15 years reinforce that, and I promise you that when I serve on the AC, even though I work for Microsoft, I'm fully empowered by my organization and by my own standards that I will work first and foremost to make the Internet a better functioning place, even - no matter what the policy does to the company I may work for. Thank you.
John Curran: Next up, Timothy Kaufman.
Tim Kaufman: My name is Tim Kaufman. When R.S. encouraged me to accept the nomination for the Advisory Council, I thought it would be a good opportunity to step up and do something more for the community. I thought it was time to grow and do some more. So I've been a network engineer at Net Access for about ten years, and I feel my expertise would be useful. So that's all I have. Thank you.
John Curran: Next up, ARIN Advisory Council candidate Sean Kennedy.
Sean Kennedy: So good afternoon. I think there's far too much on that slide for you to read it. But just in real summary, I am an IP engineer, have been for a long time, also an active IP administrator. And I've been active in the Public Policy discussions for a while. I follow PPML closely. And I've been interested for a while to be on the AC. I got the green light from my employer to do that. So I'm a candidate this year. What I think you might gain in voting for me is I do have operational experience and through that I think I can also see the big picture of policies and step a little bit away from some of the details. I've been doing a fair amount of reachout. I've been active with NANOG, with NANOGs on the Road and I moderated a couple of joint meetings, including ARIN and NANOG on the Road in Madison. The last thing I'd say is I do know a fair bit about technology. But I don't know everything. So I'm somebody that's open to learning more. That's why I'm a candidate. And I really want to bring community input to policies. Thank you.
John Curran: Next up, AC candidate Leif Sawyer.
Leif Sawyer: Good afternoon. I didn't really prepare a speech here because I like to fly off the top of my tongue. I've been involved in the Internet for about 25 years. I've been with my company for the last 20. Five years before that I was at the University of Alaska. When I'm not doing this technology, I'm actually in the theater, which is kind of a lot the same. It's all about communication. And that's what we're here for, is to help communicate and help the world communicate.
But at work, besides just doing everything you see there, I've also been writing policy. I wrote our company's Acceptable Use Policy, the original version, and many other policies that we used back when we originally started our Internet line of business in 1997. So I think I can bring some of that additional communication skills to the ARIN Council, and I appreciate your vote.
John Curran: Next up for the ARIN Advisory Council, candidate Chris Tacit.
Chris Tacit: Thank you very much. It's great to be here. I'm running for two reasons - one is heart related and one is head related. From the heart, when I first came here a few years ago and started participating in this community, I was an outsider, and, frankly, I didn't know what to expect. And you all embraced me very quickly, and I quickly came to feel like I'm part of this community and that my contributions were valuable. And for that I'm very grateful.
So now that we've dealt with the heart, I'll tell you a little bit about the head part. I've been in the communications industry since 1981. I started out as an electrical engineer. Along the way I got law degrees and MBA degrees. And so I think I have a unique perspective on governance, on regulation, and on policy formulation, all of which I've been involved in in various aspects over time. I can blend the technical knowledge with precision in language and good communication skills, which I think is very important.
I'm very interested in making sure that, as we go forward, there are a few things we look after. One is just the fact that we're going to have some bumps along the way as we make our transition to IPv6, and we need to move forward in a deliberate way that is both strategic and tactical and that takes people's needs into account and treats people well at all levels of the organization in our community. And that's a key objective of mine. Second is to make sure, as we go forward, that we look at the manual and we are able to step back from the individual changes that we make to it to always make sure that the cohesiveness and clarity of it is maximized to the greatest degree possible.
And, thirdly, I come from Canada. So I think it's important that the Canadian perspective continue to be represented on the Advisory Council. So I hope I have your support, and those are the reasons I'm running. Thank you very much.
John Curran: Okay. Now we move on to the ARIN Board of Trustees. First candidate, Timothy Denton.
Timothy Denton: You have no idea how rare and refreshing it is to be in a group like this. It actually works. Everybody moans and bitches about the lack of participation and declining involvement in social institutions, and here we have a place which has a surplus of candidates and everybody is working in a civilized discourse to get stuff done. It's really great to be among you, and I have appreciated it in the last two terms on the Board of trustees. It's an organization that works and it has brilliant contributors, and I'm privileged to be among you. I would say if there's one thing I would like to accomplish, if you give me the privilege of another term, is to extend the outreach to the membership so that there's more and better rules about - or that there be rules about approaching the membership and that these be subject to some form of regulation as to how we can campaign, because as you realize right now the campaign is basically to a great degree limited to the participants in this room.
I have enjoyed being among you. With your permission, I hope to continue and I hope to make a contribution. And I must confess with certain humility to finally being agreeing with Randy Bush on something that we're all working for the Internet, and that's brilliant. That's what I want to continue to do. Thank you.
John Curran: Next up is Bernadette Lewis. Do we have her recorded? Wonderful. Go ahead. Audio.
Bernadette Lewis: I'm Bernadette Lewis, the Secretary General of the Caribbean Telecommunications Union. Living in an environment of unprecedented and rapid technological change, the challenge for any individual or organization in the 21st century is to remain relevant and effective in fulfilling their mandate. As an ICT practitioner and proponent of Internet enabled development, my strength is in fully understanding the changing environment, taking into account the complexity of these changes and devising and implementing appropriate plans to advance the work of my organization.
And my work entails activities that foster the growth and effective use of the Internet and its resources for the social and economic development of the peoples of the Caribbean and beyond.
Recognizing the value of engaging diverse stakeholders in our work, in 2004, under my direction, the membership of the Caribbean Telecommunications Union was expanded to include the private sector and civil society, thereby creating a multi stakeholder organization. I also conceived and established the first Regional Governance Forum in 2005, which was in fact a global first. The Caribbean Internet Governance Forum celebrated its tenth anniversary in August. And under my stewardship, the Caribbean Internet Governance Forum created the first harmonized policy for Caribbean Internet governance. And I'm pleased to note that many of these policies have been implemented across the region.
I believe my significant experience working with diverse stakeholders, the perspectives I would bring from a region of small island, developing states and my passion for encouraging the effective use of the Internet and its resources for development would add value to the Board of ARIN. It's my fervent hope that I would be given the opportunity to serve. I thank you.
John Curran: Okay, next up is John Sweeting, candidate for the ARIN Board of Trustees.
John Sweeting: Good afternoon, everyone. I'm John Sweeting. I basically have three things I'd like to share with you. First and foremost is I would like to thank each and every one of you for all of your support over the last six years that I've served as your chair of your Advisory Council. I would like to ask that each of you that are involved stay involved and find somebody that's not involved and get them involved with you, especially in - with the IANA governance changes and all the other things, transfers and IPv6 and everything else going on, the more voices and opinions we can hear, the better solution we'll have. And I would just like to ask you to allow me to continue serving you not as the chair of the Advisory Council but as a member of the Board of Trustees. And as I usually do, I'm going to leave you with a quote from General Colin Powell which seems to fit this community: My own experiences use the tools that are out there, use the digital world, but never lose sight of the need to reach out and talk to other people who don't share your views. Listen to them and see if you can find a way to compromise. Thank you.
John Curran: Final candidate for the ARIN Board of Trustees, Bill Woodcock.
Bill Woodcock: For those who don't know me, I operated an eyeball network from the mid '80s until 2000. I, along with a bunch of other Internet service providers in California, started Packet Clearing House, the organization that I now run, in 1994. One of the things that I think has made me able to do the job on the ARIN Board well is that there's a synergy between my day job and ARIN responsibilities. What I do in my day job and what I do for the ARIN Board is I tell our story. I tell the story of the Internet industry to people who are not in the industry who need to understand it better.
So let me give an example. I was trying to think how to get this across, and last Friday I was on boarding a new employee who - this was easy because his desk's actually right next to mine. And so he kind of was shadowing me through the morning. And started the morning with a call from the Colombian regulator who wanted to understand why it was that there's no content in Colombia. Why is it that they have ten different eyeball networks and nobody will host content there.
So I explained about datacenters and I explained about peering and I explained about competition and I explained about new market entry.
And then we got a call from the New York Times about some work that we were doing for them where they wanted analysis of the economic impact of the iOS 8 downloads. We've done a bunch of calculations, showed that it's $110 million worth of Internet bandwidth that had been used by people downloading iOS 8 updates onto their phones. And then we had a State Department plenipot prep call, which was talking about the IANA oversight and about the - one of the issues I'm most concerned with there is the question of whether the ITU is going to become a distributor of IP addresses. Another issue that's of great concern to me coming up in the upcoming ITU meeting is whether governments should be the sole operators of Internet exchange points or whether the current model in which the Internet operators can operate exchange points should continue to prevail.
And then we got a call from The Economist, a guy there writing an article wanting to know why it was that interconnection between networks shouldn't be government mandated, why ISPs should be able to decide who to peer with.
That was the morning. And then we went out for lunch. Then Tuesday, when I should have been running around at the NANOG meeting pressing the flesh and asking for your votes, I was back down in DC and did a two hour workshop at the Brookings Institution on Internet economics, helping a whole lot of people who showed up there understand how it is the Internet gets paid for, what it is that ISPs do, what's the product we're selling and how does balance of trade work in transit being sold back and forth across borders.
And then I went back over to the State Department and led an exercise for 50 people on what it was that the US now is going to be talking about at the plenipot. So I realized that the ARIN Board is not always the most transparent to you guys, and so I'll give you a little bit of an idea what I do on the Board as opposed to what I do facing out in the rest of the world. Obviously the most important thing is the Internet governance activities that John leads and Steve and I and Cathy Handley all do. This is helping represent ARIN and the RIRs out in the rest of the Internet governance community.
On the Finance Committee, I try to push for budget constraint, not having a bigger budget each year than the last year but having a budget that is governed by fulfilling the needs that you guys have expressed.
I try to - it's no secret that I'm not a big friend of RPKI. Big reason for that is because RPKI was sucking a huge amount of resources internally within ARIN. So big thing that I've tried to push for is not having that monopolize ARIN's R&D efforts but instead getting some of that development work to address the backlog of software development issues on the portal and automation and services. Last, I lead the Fellowship program, the committee that twice a year selects people to come to the meeting who wouldn't otherwise have been able to afford to. So I bring more than a decade of experience, but what's really important is what I'm doing for you right now and what I'm going to do for you tomorrow. I'm very active. I continue to go to a lot of meetings. My day job continues to pay for most of that, and so I'd like to ask for your vote and for your continued confidence. Thank you very much.
John Curran: Okay, that concludes the election speeches for the Advisory Council and the Board of Trustees.
We're now going to roll right into an update, our Software Development Update, by Nate Davis.
Software Development Update
Nate Davis: Can everyone hear me? We started out in Chicago doing a software engineering update. This is not meant to replace the update that Mark Kosters does on the Member Meeting Friday, but really just to focus predominantly on the high level software projects that are underway, because the last few meetings there's been incredible interest with regards to what ARIN's engineering team has been working on. I'm going to go through that for this meeting. All right. Some of the things I'm going to cover. I'll cover the projects that have been completed since the last meeting, again, since Chicago.
Initiatives to be deployed. So as we look forward to the next meeting, what we're anticipating actually getting done, what influences the prioritization process within engineering. Because I know folks are always curious how things get done and what are the determining factors in work getting completed within engineering. And then lastly talk a little bit about project prioritization.
So projects that we've completed since ARIN 33. We've completed shared ticketing; signing of ARIN's four DNS zones; agreements associated with organizations; DNSSEC improvements; transfer processing and improvements, specifically 8.3 transfers, transfers from one organization to another, within region; and then lastly some user interface improvements, specifically in the payment processing area. If you will note that each of the items that are marked with an asterisk are those items that have actually been suggested by the community that ARIN work on. So you can see that there's been a significant amount of work since Chicago that we've been able to implement since that time.
So what are we looking forward to doing in, say, the first quarter of 2015? So we've got to continue working on transfer requests. We had anticipated that we'd have transfer requests done by the end of this year. Transfer requests are very complicated. So it's taken us a little bit more time to get those done. But we're still planning to get those done early in 2015.
We're also going to add links to Whois query responses. If you recall years ago, ARIN used to, if you conducted a Whois query and the address, the address block was actually outside of the ARIN region, we would take you to that RIR's Whois. We lost that functionality when we did some upgrades with implementing ARIN Online. We're going to restore that functionality in early 2015. We're also going to change the Whois output for certain /8 records. What this is in the case of certain /8s where there's a DS or DA record available we'll actually provide those results. Lastly, not lastly, but we are also going to work on deploying two factor authentication for access to all of our systems. Kind of uplift the security around them. We haven't had any real issues, but it is something that's been requested by the community. And given the environment that's happening around the world with some of the security problems, it's probably a good thing that we go ahead and move forward on that.
And then lastly begin development for SWIP Easy. SWIP Easy is an interesting concept. We have, for organizations that are small and have a few number of SWIP records to actually manage, they go into ARIN Online and actually manage those records because they don't have a huge number of records. And then at the other end, if you have a huge number of SWIP records to manage, you can actually programmatically do those through our RESTful services. The problem is we have nothing in between that that fits a majority or significant number of the community. So we're going to look at ways to automate that and make that easier for folks in the community to actually use ARIN Online to manage their SWIP records.
So what are the things that influence what engineering works on? Well, here's a list of them. I'm not going to go through all of them. But as you can see, there's a number of factors that sort of feed into the pool of considerations that we make when we're trying to evaluate the projects that we work on. It's not an exact science. We have to weight a number of items at any given time and have discussions not only amongst staff but with senior management, sometimes the Board, to gain guidance and clarity on what we should be working on. So the Board met in August and went through and created, and it is now available, the 2015 16 strategic plan. And it's available online on ARIN's website, if you're interested.
In that, there's some specific items that pertain to the software development work that ARIN pursues. And you can see from here there's three specific guiding factors that the Board has indicated to ARIN staff as we look at project objectives for 2015 16, please consider these factors as guidance in our prioritization process. And I am done unless folks have any questions.
John Curran: Microphones open for questions. We do have policy right after this. Okay. Thank you, Nate.
Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers
John Curran: Okay. We'll start on to the policy discussions. We're just a little behind but doing very well. The policy discussions will resume with Draft Policy 2014-14, Removing Needs Test from Small IPv4 Transfers. And we're going to have John Springer come up and do the presentation. I need my head table. I see Dan, our chair and our Vice Chair Paul Andersen. Paul, if you're out there, come join us.
John Springer: Good afternoon, everybody. This Policy Proposal 2014-14 came out of a policy experience report that was given in Chicago this spring. ARIN staff stated that there were some issues with the ability to roll out transfers in a timely manner. There has been some community comment on this as well. And a bright eyed member of the community hopped on that and said, well, if we did less needs assessment on transfers, that might help. So the problem statement is that ARIN staff faced with a surge in near exhaustion allocations and subsequent transfer requests and a requirement for team review, spending a lot of time on small transfers. Get rid of the needs test. That will take some of the burden off. We've got two changes proposed that are nearly identical. A change to NRPM 8.3 and one for 8.4. We've tried to make the wording as nearly identical as possible to eliminate as much confusion as we can.
So this text is in your books and - I'm not going to read it. Essentially what it means and states is that for incoming address transfers, /16 and smaller, the author proposes that we not conduct a needs test based on the idea that they may only do this once per year and based on that taking place. After that they justify based on a /24 month supply. There's been a lot of talk in the community about this over the years. It's difficult to summarize all of the various positions and arguments for and against. There has been quite a bit of concern about the idea of hoarding and speculation based on the trafficking in IPv4 numbers. There are people making a living doing this that have become regular citizens of the ARIN community. Some of these folks over the years have made some pretty dramatic efforts to reduce or remove needs testing. Most of those have been rebuffed.
So what we see here is an attempt to work for incremental change, to seek a middle ground somewhere between the elimination of needs test and the continuance of needs test for every transfer. Normally we do not do staff and legal review for draft policies. We typically will wait until we advance something to the Recommended Draft Policy state before doing this. However, we have a couple of draft policies here today. This one, 2014-14, and coming up next, 2014-20 that are looking at this subject from different telescopes. So both Kevin and I thought it was prudent to obtain some additional information for the community's review so that we could evaluate some other things. This is also included in your program. The reason I put it in is that, according to ARIN staff, an exception at the /16 boundary and below would affect a reduction in the number of transfers of 85 percent approximately.
So there's two numbers that - and I'll be talking about this in a minute - but two numbers associated with this phenomenon. So of all of the transfer requests that come in, the number of them, 85 percent are smaller than a /16. As we'll see in a minute, that turns out to be a very much of a disparity when you look at the actual numbers that are transferred. My good friend Owen DeLong did some very kind analysis of this subject. What we have here are the various CIDR notations. The center column represents the number of addresses contained in that category and the ones above. And the one on the right - no, I'm reversing. Yeah, that's right. The one on the right is the number of the actual transactions.
John Curran: That's transfers to date.
John Springer: To date, of which there are 216. It should be pointed out that past behavior is no guarantee of future performance. If we were to run the free pool dry as we are certain to do, then these numbers could be expected to change. So what do we make of this? Well, 89 percent of the actual number of transfers are /16 and smaller. That represents only 17 percent of the address space transferred. That means that 83 percent of the numbers, the total amount of numbers transferred would not be affected by this policy.
Now, one of the most prominent objections to this policy up until now is that /16 is too big. Too big for what? The assumption is that too big in some way refers to a hazard to the Internet routing table. I'll examine it somewhat coming up. So maybe /16 is the wrong number. Maybe 17 percent of the actual numbers of addresses affected by this policy is too much of a hazard. Well, 17 doesn't look all that good. Nobody likes odd numbered boundaries. And Owen has proposed 20, which is a very, very, very safe level of potential hazard. But somewhere between /16 and 20 perhaps we can have a discussion about what level of risk the community has a stomach for. Maybe it's /18.
So where we are in the process. So to get here, to being a Draft Policy, the Advisory Council had to ask itself two things: Is the problem statement clear and is it in scope? There are a number of criticisms that could be made of this problem statement. But unclear it is not. And the first thing that occurred to me was since we're talking about directly influencing the activity of ARIN staff, whether that was out of scope for the AC, and that question was asked and answered, and it is. So the next level that we would take this to would be to take it to Recommended Draft Policy. And we have three hurdles here. The Draft Policy needs to enable fair and impartial Number Resource administration, be technically sound and be supported by the community.
I could go on at some length about all of these, and we'll be discussing some of the parameters of that when we talk about people's comments. But the argument can be made, and I might make in our meeting later this week, that these criteria have been met. This slide was made up earlier in this week where I was very much focused on fostering input from the community, which I still am. At this point I've received enough feedback from the community that I don't think, unless I get an overwhelming groundswell, that I'm going to be recommending to move this to Draft Policy. We've had a number of suggestions that make sense, not only adjusting the boundary location, but also things like suggesting an attestation of a company officer for a substitute for need. In any case, I still want to hear any reasons you might have not to do this. Starting now.
John Curran: Microphones are open.
Dani Roisman: Dani Roisman from SoftLayer. Few comments. If this does move to Draft Policy, I think there's a technical change that has to be made. Can you go back to the actual change language slide, please? So the very last part of that says that - okay. So the new draft language ends with "the recipient must demonstrate the need" - "for transfers larger than /16," et cetera, et cetera, "they must demonstrate need and sign an RSA." The problem is if you just do that rename, it also means that transfers /16 and smaller no longer need to sign a RSA. One technical note. I recommend we move the "must sign RSA" to its own separate bullet because we all agree an RSA needs to be signed, regardless of transfer.
John Springer: Noted.
Dani Roisman: The new language will both say sign an RSA. But that will only apply to /16, or larger than a/16. /16 or smaller will no longer have any language and you must sign an RSA. I'm saying sign a RSA should be its own bullet.
John Curran: Noted.
Dani Roisman: With regard to attestation, I definitely agree attestation has to happen. I believe it's already covered because in 8.3 it does state - excuse me one second. There's a blanket statement. I just want to quote it precisely.
"The policies transferred will be subject to current" - sorry. "The resources transferred will be subject to current ARIN policies." I believe an attestation can arguably be considered within current ARIN policies. Anytime you get additional IP address space, you need an assessment, attestation, and Section 4 is part of that.
John Springer: I'll bring it up to AC when we discuss this.
Dani Roisman: Sorry. I generally support this proposal. I believe definitely we should be moving towards reducing the needs based, the needs based work in 8.2 and 8.3. The problem statement, while I appreciate this problem statement, and I definitely feel for ARIN staff that have been clearly burdened by all of these transfers, I think there are additional reasons as well, which has to do with just the complexity of growing companies and needs based for transfers. I think in general I would support removing all needs based, although I definitely appreciate that a /16 is very, up to a /16 is a very good first step. In general, I would propose this moving forward with the minor modifications that I recommended earlier.
John Springer: Thank you. As a practical matter, making a problem statement with a lot of different problems being solved leads to difficulties.
Dani Roisman: I appreciate that.
John Curran: One comment regarding the problem statement. I note that the condition of having team review for IPv4 assignments and allocations is a transient condition that will, with free pool runout, likely drop. We may not see quite the same level of activity and we will not have a free pool we're worried about serialization. We will be worried about adding people to the waiting list in appropriate order. But it is true that the current problem statement is a problem statement addressing a transient condition. So the only thing the AC may want to consider is, if it's not going to be adopted promptly, you may have to touch the problem statement to make it timely to future conditions, because this won't last as a current issue forever.
John Curran: Remote comment.
Heather Schiller: Marla Azinger, Frontier Communications. No support. Fair and impartial has not been met. Everyone should be showing there is a need. Something else needs to be made clear that has been ignored for years. The size of a company does not remove the scale of complexity, monetary constraints, or scale of possible hoarding. I don't find it any less abusive for a small entity that really only needs 30 IP addresses to hoard a whole /24 than I do a large entity that only needs 8,192 IP addresses that hoards a /16. I hear this community repeatedly say they want to see ARIN function on a level of equality. So let's do that and stop trying to say one size of a company should be treated better than another. This policy would blatantly give smaller companies a golden pass and continue to require extensive details for larger companies. And as a person who actually spends their days reviewing IP requests, I can validate for you that there are a lot of ISPs that claim they need a /24 or more when in fact they don't. I don't support no need, but if ARIN is going to do this, then ARIN needs to open the barn door equally for all members.
John Springer: Thank you. Owen.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. I'm opposed to the policy as written. I would be opposed to it at the /20 level but not so vehemently. I think removing needs test is a bad idea. I think if we are going to do it, we should treat it as a very, very cautious experiment and do it very slowly, walking what's left as we see things working out or not. So I think the analysis shows that if this really is a workload concern as expressed in the problem statement, we can address 62 percent of the workload while only risking roughly one percent of the address space that's been transferred so far. Yeah, that's not a tremendously accurate predictor of future performance, but it's the best we've got for the time being. So I think that that's a reasonable trade off of bang for the buck, or even /21 or /22.
John Springer: Thanks, Owen. Rob.
Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC. Is this mic actually on? So I would like to echo Owen's comments, with some observations. I originally thought that this was a horrible idea. And my thinking on this has evolved after listening to the community talk and after reading staff legal assessment. Many years ago we had people talking about a transfer market and there was a lot of discussion about, well, why do we need this before there's actually, this is the only way to do it. So why do we want to implement it now instead of later.
The answer, of course, was to get experience with it and be able to modify our rules and operations as relates to that experience. So it is with this that I think that trying to go for one and done sort of proposal and get the prefix length correct on the first try and make it huge is probably a bad idea. That said, if we think that we want to, if we want to get rid of needs base some degree, we should do it on small prefixes so that the amount of risk that we are taking is commensurately less. And as soon as that policy is implemented, there should immediately be a new policy to modify the length, to shorten the length of the prefix, and we should have that dialogue based on what we see with the experience with the longer prefixes. And we might have to repeat that more than once.
Because we can't get the genie back in the bottle if we stick with /16. But if we go to, say, /22 or /24. /24 is probably too small. If we go to a /22. The smaller it is, the generally the more I support it. But I think /16 is too big. So conceptually I've come around to supporting this. But at a /16 I do not. Thank you.
John Springer: Thank you. Kevin.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I have a question, part A, for staff. Extra extra small, extra small, small. What is the total number of companies that, percentage wise, is it 85? 90 percent of all companies in the ARIN region fit into that category, give or take?
John Curran: You're talking about counting both v4 and v6 resources?
Kevin Blumberg: v4 in this case would be most appropriate. Just ballpark. Are we talking about a significant, significant portion of the ARIN community? While John is looking at that, I'm bringing this up because I hate statistics. And what I hate more than anything is statistics based on an unbelievably small artificial pool that exists. So, Owen, I appreciate what you did in terms of the numbers, but it is an unbelievably small sampling of a scenario where we are not in runout.
John Springer: It's a 100 percent sample.
Kevin Blumberg: Yes - no, it is a small sample of the total number of resources out there. It's a very small sample and a very small time window. I believe if we're trying to make this easier for the small entities, and in ARIN's at least billing view a small entity is a /18 - yes, John?
John Curran: Just for the numbers, I'm using the statistics from 2013 full year. Extra extra small 455. Extra small, 1120. Small, 1923. Recognize the total pool you're talking about is 4,600. So respectively of the 4600, extra extra small 455. 1100, extra small. And small is nearly 2,000.
Kevin Blumberg: Thank you.
John Springer: 75 percentish.
Kevin Blumberg: In aggregate, these are aggregate numbers for all of these ISPs and end users. 75 percent of all the ARIN community today would be double, triple, quadruple to a factor of 60 times what they currently have utilized over the entire existence of the ARIN registry.
John Springer: But then they'd all be medium. They'd all jump up a category.
Kevin Blumberg: I'm saying in terms of this policy, just something to think about, that from a statistics - if you're going to use statistics, look at the history, the real history of what people are holding today. That was the first part to it. The second part to it was I've heard a lot from the community in terms of this is being preferential to the small, and I'm a small ISP, would love to see something like this personally, but this is being preferential. So my question is: Should we be really thinking how we can do this not only for the small guys but for the big guys. It might be different numbers. Might be a different ratio, might be a different something. But I do not believe that having this only for the small players is appropriate. We need to lighten the load for everybody categorically in this area. Thank you.
John Springer: Well taken. Jason.
Jason Schiller: Jason Schiller, Google, ASO AC. I wanted to echo what Kevin and what Marla said about opening the barn doors equally for everyone. When I first looked at this policy and I looked at a /16, I said you know what is the time horizon for a small ISP who is, say, maybe getting a /24 every quarter or a /23 a year or /22 every two years.
A /16 is like a 64 year supply of addresses. I'm not opposed to making the paperwork simpler for the small guys, because that's difficult. I'm not opposed to lowering their overhead or getting an IP advocate that can help them and guide them through the process. But it is concerning to me that the time horizon of the amount of address that you could get is significantly different. If we look at a /21, for example, that small ISP would be getting a two year supply of addresses. A larger ISP that needs more than a /21 can do the paperwork, get a two year supply of addresses. That doesn't seem to be as inequitable as the current policy proposal. So my concern is how much space are you giving them in the time horizon, independent of my issues that I have with not having need in general, but putting that aside, there's still an inequity with the time horizon.
John Curran: Jason, you mean how much space you're allowing them to obtain from the market?
Jason Schiller: Yes, how much space they're allowed to obtain from the market.
John Curran: Folks who want to speak on this topic, please approach the queues. I'm going to close the queues shortly so that we have some chance of having five minutes for coffee and cookies. So line up if you wish to speak on this policy proposal.
John Springer: Mike.
Mike Joseph: Mike Joseph, Google. A couple of points I want to touch on. First off, I think we've covered the fact that passing policy to ease staff's burden is a foolhardy endeavor. I'll move past that one. But I do want to point out that continuing the theme of fairness which, as you pointed out, John, that's a criteria for advancing any policy. This community has defined what it envisions as efficient address utilization. That vision is codified in the NRPM, in various parts of Section 4, which discussion how a resource, Internet resource is to be used. Whether or not I have a resource because I obtained it from ARIN or from ARIN's predecessor, I hold a resource that's a finite resource that fundamentally came from the community. And my use of that resource is currently governed by ARIN NRPM which specifies how I should use it efficiently.
If we start passing policy like this that allows entities to maximize their own individual gain over that of the overall community we're going to encourage significantly inefficient use of address space. It won't be necessary to hit 80 percent targets on your use. It won't be necessary to hit 40 percent targets on their use. In fact, it won't be necessary to hit any targets on your use. You can simply purchase as much address space as you can afford regardless of how efficiently you use it. That means that the companies with the biggest pockets will be able to corner the market. I don't think that someone will go out there and buy up all the address space. They won't have to. You'll have enough actors out there that are going to try to buy up as much address space they want for what their purposes regardless of how efficiently they're going to use it. And that flies in the face of the efficiency guidelines this community has established over the entire course of ARIN's history. And I think we need to think long and hard before we decide to abandon that in favor of a free for all based solely on how much one can afford to buy on the market.
The argument that a /16 is too big or too small, we can have. But the fact is large companies can benefit from this simply by picking up shell companies or using existing shell companies. And small operators, who may not need any address space whatsoever are going to now be able to obtain /24s by simply clicking a button and buying it now. No offense to my eBay friends. So this absolutely opens the floodgates. Other people pointed out how it does so unfairly to different sized operators, but the fact is this is a slippery slope. And this isn't about making things easier for paperwork. There's a mechanism to make paperwork easier. And that's to communicate that desire to the ARIN staff. There's a mechanism to easing the burden on the ARIN staff. That's to hire more of them. But changing policy because we have an acute problem that I'm not even sure exists that much in order to get transfers through I think is foolhardy. So I oppose this policy.
John Curran: Is there any change to this policy that would enable you to support it?
Mike Joseph: No. I think a policy - for me to support, it would have to have a component of needs basis. And that would mean eviscerating the current policy.
John Springer: I will note a component of irony with the observation that big guys have the advantage to go out and get all the addresses that they need whereas the proposal is unfair to big guys.
Mike Joseph: Could you clarify? You made a comment about irony of my comments. I'm curious to understand exactly what you meant.
John Springer: I was comparing your comment to Jason's comments. We have an assertion that on your part that the larger players can go and get their whatever addresses they need because of their size and their war chest. And yet Jason and Marla would assert that the major flaw in this policy is that it's unfair to big guys because it's setting them aside as a disprivileged class.
Mike Joseph: I think it creates unfortunate circumstances for both classes and how each size of operator in the community might choose to use this policy to bypass the intent of ARIN.
John Springer: Thank you.
John Curran: Folks, I'm closing the queues. Approach the queues if you're going to be here.
Heather Schiller: Marla Azinger just replied that not all big companies have deep pockets.
John Curran: The queues are closed. You're the last speakers on this. Go ahead.
Martin Hannigan: Martin Hannigan from Akamai Technologies. I think we're going in the right direction. I do believe you have a problem, and I have no doubt - I've been through this, through the request process multiple times this year, and it's taken much longer than it probably should have, and I understand I'm in a much different class. But still from zero to three months to four months is a long time to wait for anything. I guess I'm not really going to voice support one way or another. I want to make a few comments. The /16 boundary does seem to solve your problem. Although it creates inequities between the smaller and the larger.
I think that people are talking about ISPs, but I'm going to talk about CDNs, without naming any. Some of my competitors will love this policy and will use them to their heart's content while I'll have to sit on the sidelines and my competition will be limited as a result. I think that you should remove needs test altogether and let the market sort itself out. Otherwise don't do this. Thank you.
John Springer: Mr. Petach.
Matt Petach: Matt Petach, Yahoo!. I do not support the proposal. I think if the concern here is staff issues and the amount of work on the current staff at ARIN - as I recall from past ARIN meetings, there's a significant amount of money in the ARIN bank accounts at the moment. Help out the US unemployment situation and hire more staff people. Thank you.
John Springer: Thank you. Brandon.
Brandon Ross: A few comments. First of all, there's some indication that smaller organizations are not at some sort of disadvantage, that it's just as easy for them to request IP space. I will tell you from personal experience, I have a number of small organizations that pay me to deal with ARIN for them. I suspect very strongly that if they didn't need to justify their address space, they could probably fill out the forms themselves. While it's not in my best interests for this to pass, my personal best interests, it certainly is in my customers' best interests to eliminate needs testing on small blocks. As far as what size, I don't have a strong opinion on that, but I do believe that at least somewhere in this range makes a lot of sense to determine if it makes sense to start raising that later after this is raised. So in other words, I believe this is a good compromise to determine if needs testing all together is needed or not needed going forward especially as the free pool is exhausted.
John Springer: Thank you. R.S. did comment about the possibility of a certain experimental nature to all this, after all at least some of us are scientists. David.
David Huberman: David Huberman from Microsoft. Do you know what happens when you need IP addresses to run your business because you're growing? You go to the RIR. And you know what happens when the RIR says no because they don't have any? You go to the market and you buy it. So this community is faced with a different question that's being talked about right now. We're going to go out and you're going to buy your space and the only question is can you update Whois. And under the current policy a lot of time that answer is no. And under this policy, this makes the answer yes for a lot more people. Nothing this community does allows someone to buy or not buy address space. I heard a lot of previous comments about we're opening up floodgates, we're taking risks. People are going to - this is going to make it the wild wild west. Well, guess what? It already is.
Many of the organizations in this room already go out and buy address space, because they have to, because they operate in a region that's exhausted or their needs are beyond that which ARIN can provide right now and certainly beyond which ARIN can provide in a few months, when it gets exhausted. It's not a question of can you buy space. You can and you will because you're running a business. For profit or not. You have to grow your network. It's whether the ARIN community wants ARIN to be relevant or not, and by ARIN I mean ARIN's Whois. One last comment, Mr. Springer, when we do vote I would ask you to please consider taking a poll of the room of whether or not there's support to removes needs basis in general, without talking about the barrier, without worrying about /20, /24, /16. My sense over this week, talking to people, is there's a larger percentage of people in favor of removing needs basis all together than removing needs basis on an experimental level.
John Springer: Thanks, David. I'm not sure I'm going to take a vote. There's quite a conversation going on here. And I think there's - I think there's going to be a lot of vigorous discussion on PPML. Middle mic.
Tom Fantacone: Tom Fantacone, IPTrading. I wanted to address the objection that this would reduce efficient usage of the addresses because the recipients don't have to justify them, they don't have to come up with an 80 percent justification or as it was quoted even a 40 percent justification. We're talking about transfers here. And the sellers in these transactions, because they are sellers, right now for the most part have a zero percent utilization of these blocks. So any way to get these into the hands of people who can use them, even at a lower level than ARIN would normally approve, is a positive. It's getting these addresses into the hands of network operators who need them. I'm an ARIN facilitator, i.e., broker, and people come to me, I'm on the front lines when it comes to people looking for address space who don't understand the process, are afraid of the process, want to talk to me in hushed tones about why they need the space.
I can tell you the biggest reason people don't do transfers right now is the price. It's too expensive. That's a deterrent right there. That's why people are not going to be abusing this, hoarding and speculating. They get the addresses when they need them, sometimes even when they need them they can't afford them. So I support the policy.
John Springer: Thank you.
John Curran: Just a question for clarity. So you indicate that utilization has improved. Is getting these blocks in the hands of network operators therefore put them to use and that's an improvement. And I guess I'd have to ask the question: If indeed everyone who makes use of this policy is a network operator, then that would definitely be the case. But it's not clear without any needs basis whatsoever that we know the people who make use of this policy actually have a network at all. So I hear your point but sounds like you're advocating for a policy that says allow transfers to any network operator, not this particular policy.
Tom Fantacone: Allow transfers to anybody who wants to buy the addresses. And in practical terms, it could be a network operator, end user organization. In my experience, because I deal with these organizations all the time, I haven't had a single speculator come to me and say: Hey, I want to buy some IPs I think they're going to go through the roof in ten years. It doesn't happen.I guess to be fair, I had my first speculator today actually. I got an email from my Web forum. It was an individual who wanted to invest in an IP address.
John Curran: I have a few of those actually.
Tom Fantacone: I think he wants to get out of the monthly fees paying Comcast for static. He looked at the present value of an IP address and thought that was worthy. But I don't think in general it's a major concern.
John Curran: Got it. Very helpful to understand. Thank you.
John Springer: Tim.
Tim McGinnis: Tim McGinnis, NABP. But speaking for myself. I guess I said on the Mailing List I could probably go to a /24. But Michael Joseph's words really spoke to me. I've changed my mind. I'm completely opposed to this policy as I was previously before I said I would maybe think about a /24. I'm not the sharpest guy in the room, far from it, but for me it all boils down to: Why would you apply for addresses if you didn't need them? And as a former RIR host master myself, I understand that it's really not that difficult to show need. So those are the arguments that really speak to me the most. If you need something, put your hand up for it, and you'll get it, whether it's a transfer or from the free pool. Thank you.
John Springer: Thank you. Heather's in queue. It's her turn, actually. Okay, Mike, you're it.
Mike Joseph: Mike Joseph, Google. I just want to respond to a couple of the points that were made. First off, the argument that people are - that my colleague David from Microsoft made, that people are going to buy addresses now regardless of this policy and we're simply determining whether Whois will get updated, that's an argument I hear a lot in terms of eliminating needs basis. And I think that the problem with that argument is that, sure, speculators can buy interest in IPs and eventually sell them. And that will happen. Companies might buy interest in IPs that they'll transfer. But the key is the eventual transfer part.
You see, there's a difference between something that's going to happen because it will comply with policy and somebody buying IPs who will never comply with policy. Companies are not going to buy a /8 if they will never be able to transfer it. They simply cannot justify it. There's no reason for them to because the prevailing policy framework won't allow them to take possession of it and use it. Now, people will talk about the shadow market of LLAs and use of address space without being properly titled for that, and that will happen. And you know what, we have ways as a community we can talk about how we want to tackle that problem. But I don't think the way to tackle that problem is to throw out the policy.
But the fact is, people are going to buy addresses who think that they can transfer them. And so what we said here in terms of the transfer bar actually does matter. Because it controls what addresses a company will end up being able to take possession of at least eventually. And that really will be determining overall efficiency. And to the point that was just made about efficiency, after all isn't it ten percent efficiency better than zero. Perhaps. But if that was the argument we would make, then we should have given away the free pool a long time ago because currently addresses held in the ARIN free pool have a 0 percent efficiency. Yet we concluded as a community that we want to strive for higher efficiency and more fair and equitable distribution of the common resource. The IP address pool of 32 bits to this community.
So we have an obligation to continuing to drive for efficient utilization of this finite resource, and that means, yes, maybe the person who is only going to use it at ten percent doesn't get that block, because the next guy who comes along can use it at 80 percent, he probably needs it. Thank you.
John Springer: Allow me to object to the use of throwing out the policy as a statement. I believe the objective here is incremental change.
Mike Joseph: You have the right to object to any statement I make, of course. But I think many of us in the room view this as throwing out needs basis.
John Springer: Heather.
Heather Schiller: I've been waiting patiently. I have a couple of problems with this. I think that - by the way, Heather Schiller, Google Fiber. The problem statement needs work. We need to clearly identify whether we are enacting policy because of staff workload or to make acquisition of addresses easier for customers. It's not at all clear. If it's a staff workload issue, I don't know that changing policy is the best way to handle that. I think if staff needs additional staff, that's an internal HR issue for ARIN and they should work through that. The other thing, in terms of getting address space, having moved to the first in/first out policy, so transfers aren't affected by first in/first out, but the transfers themselves shouldn't be overall delayed by ARIN staff's review of, review of requests. I think the team review policy on the request for the remainder of the free pool are high because folks are trying to get address space before ARIN runs out. I think once they get through that period, ARIN's - the amount of time that it takes ARIN to review a request will go down. I think there should be a discussion about the SLA, the expectation of not just staff but in the community of how long it should take ARIN to turn around our request. I think that ARIN staff has been doing a fantastic job. I don't feel that five days is unreasonable.
And the other thing I wanted to mention was that for - so in theory you're transferring two years worth of address space to your organization.So once you go through your initial transfer, in theory you're not coming back to ARIN for another transfer for two years, and I think that in two years their workload will have died down enough that modifying this policy or eliminating need solely to reduce their workload will no longer be an issue. So I think that taking a longer term view of why you're doing this is worthwhile. And the last thing I want to say is that maybe consider doing something where organizations that have recently made a request, have recently been audited by ARIN, kind of an every other time thing, where you've recently gone through an audit, ARIN is familiar with what your utilization is, they've gone through everything, and the next time you come back, you can, if it's not more than what you've recently requested you skip the needs justification and you - and the time after that you go through an audit again. That would reduce the overall amount of auditing.
John Springer: Microphones are closed. Mr. Lee, if it's quick.
Charles Lee: You seem to have confused some issues here. There's some statements made which were grossly inaccurate that the only reason that somebody buys a block is so they can transfer it later. That's not proven to be the case. There are examples, for those of you that are fearful, about what happens to Number Resources when needs assessment are eliminated, I'd refer you to RIPE. If you wanted to get a more long term historical view of what happens with number resources and their utilization, I'd refer you to APNIC. They went a long time without needs assessment and numbers were allocated. The other thing is that there is this misunderstanding about the back pressure of price. Markets behave as markets behave. As supply increases for a given level of demand, prices move accordingly.
What is happening today is that transfers are occurring and no one is updating their registry. And that's a bad thing for everybody. So anything you can do to lower the barrier to get your registry accurate is good. It's good for everyone. And to say that you're going to impose a policy constraint or a contract constraint or whatever constraint which provides incentives for your database, your registry database, to become more inaccurate, I would suggest is against your own interests. So thank you.
John Springer: Thank you very much. And thank everyone for their input.
John Curran: That concludes the discussion of 2014-14. We're going to have a break. You have about 320 seconds, I think, yep. We're going to give you a 20 minute break. We'll see you back here at quarter of 4:00. We'll resume with Policy 2014-20, the next policy on the list at quarter of 4:00.
John Curran: We have about an hour per proposal and we'll have a good time. But if you folks want to leave here before 10:00 at night, we're probably going to need to do ten, 15 minutes per proposal, which means I need people to get up and say their name, affiliation, I support the proposal, thank you, and sit down. Or my name, my affiliation, I don't support it, and here's why and I need you to get terse and succinct, because we don't need people describing their life story, how it interfaces with the policy proposal. We really need people to express what's wrong with it and whether it can be fixed or whether there's no fixing it. It's you - you folks have control of this. We'll probably go a little past 5:00. I hope not to go too long. But let's get started. It's 2014 20, Transfer Policy Slow Start and Simplified Needs Verification. And take it away Kevin.
Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification
Kevin Blumberg: Hello everybody. So this policy is a fairly large policy. The actual policy is four slide decks. What I'm going to try to do is not go through it verbatim word by word. It's a Draft Policy. What I'd like to get from you is your input. This policy works on 8.3 and 8.4, Section 8.3 and 8.4. I'd really like to get your input. Based on discussion we've already had on the PPML, discussion at the PPC, there's a lot of simplification that we'd like to see.
If there are areas you think should go, I'd love to hear it. If you think there's things that should stay, I'd love to hear it. If you think this policy overall is in the right direction, by all means let us know. But this is another way of dealing with transfers and looking at the situation of transfers, how we can better deal and make it more efficient and easier for people coming to the market, for people coming to the transfer policy once runout really occurs. So part of this is in relation to new organizations that are having difficulty qualifying for initial slow start. This is related to now customers having problems getting space from their upstreams where that was not a problem before. It's in relation to organizations that grow very rapidly under slow start, continually having to deal with that. Existing organizations, with regular growth. Getting the right sized block, which in some cases might mean doing multiple transfers.
You need a /16 but all you can get is /18. Allow for it multiple times. And I'm going to explain, because there's some stuff in the staff report as well related to this. But that was mentioned as well. Organizations with a very large growth rate. With the transfers. Okay. So let's go over this in a very short amount of time. This text would replace 8.3. Okay. And get rid of the - not get rid of, per se, but change the 24 month and add in a whole bunch of stuff. So let's go. New ORGs, end sites, end users, who do not hold any space. So new entrants. And they can demonstrate 50 percent immediately by what they have will immediately qualify for a transfer based on a /24; an ISP, /21. Now, this was based on the old NRPM. So what we were looking at doing was removing out the /24 and /21 and just saying whatever your 50 percent immediate utilization is, you qualify for that space as an example. Existing ORGs, prior to qualifying, you must administrate 80 percent based on Section 4. Once you've demonstrated you're 80 percent based on Section 4, everything now is based on what is in this policy. And this is aggregate, by the way. This is - this is not your last block. This is not the fourth block back. This is just 80 percent across the board, keep it simple.
Any organization that qualifies under the sections will be approved for transfer. We'll see - you get a total amount that you don't need additional justification. It's cumulative. If you do an M&A transfer, then that amount would change based on you now having applied getting new blocks. And organizations for rapid growth, this is very important. Organizations may be approved for the transfer of additional address space equal to 20 times the organization's calculated average monthly use. That calculation allows you to look back three to 12 months from the date of the current request which is a very different model than we have today. Right now we have a forward looking 24 months sort of policy in transfers. In a rapid growth scenario, you can come to ARIN and say the last three months I've used a lot of space. Extrapolating that out for the next 24 months. Make it simple. You can return space. I know it sounds kind of odd these days that you can return space, that people don't see it, this allows for you to return space and you can then take that and remove out of your monthly usage calculation. M&As are taken care of. And then what we've done is in 8.4 it's basically the exact same text. So there's no differences really between an 8.3 and 8.4 transfer. So the first question is do you support decoupling 8.3 and 8.4 transfers from standard 4.x requirements. You still need to show that you're at 80 percent under 4.x. at that point now everything else moves into Section 8 as far as from a calculation point of view. So if we can, if people want to come up to the mics, if you have any questions, if you want to talk about what portions of the sections you support, if there's overwhelming support, whatever it may be, do we want to continue, how do we continue, et cetera. This is different from 14. So I'd love your input on that.
Matt Petach: Matt Petach, Yahoo! I think this one is on the right track compared to 14. I think looking back for the fast start is a nice idea. This really feels weighty, complex. It's, as you say, four pages of material. I have a lot of concerns with the number of clauses. And as the legal assessment said, there's a lot of complexity involved. I give nominal support for the concept. I'm not sure that as it currently stands, though, it's in the right place.
Kevin Blumberg: Thank you.
Heather Schiller: Marla Azinger, Frontier Communications. No support. I don't see this solving a problem. I believe recent changes made in September remove roadblocks to new ISPs and end users. Changing the transfer policy is not needed. As a person who has assisted with multiples of market transfers I did not experience a problem like this proposal alludes to. ARIN staff already approves multiple transfers if a request falls within a growth pattern. If the request exceeds the set growth pattern, then the review of usage with growth plans will support the new larger transfer requests and it will be granted.
Now, if someone is totally full of it and they're - I'm sorry. Not me. I'm reading for Marla Azinger - now, if someone is totally full of it and they're actually trying to hoard five years' worth, then, yeah, it's going to get denied. So in review, I don't see a problem needing resolved by this proposal. What I do see here between the lines are two things: One, some community members might wish to increase the 24 month plan to a larger size like maybe 36 or 48 months like originally put forth years ago. But that would be a new proposal. Two, M&A transfers are a lot of work for those actually purchasing an entity. I've personally worked neck deep in at least five of these. The addressing as I've witnessed myself can be all over the place and the transition is painful with initial customer loss than after four to five months has a rebound in massive growth spurt.
In addition, the records and transition of that address space can take sometimes a year or more to straighten out. Honestly, I think M&A transfers just need to be let loose from the news. ARIN policy has unknowingly been written into a strangling point that can possibly damage a company when all ARIN really needed to capture was a scenario where no customer base existed and IPs were being purchased with a company name and that was it. Now, three years later, we have a transition policy that takes care of that. So in summary I see slimming down the M&A policy for everyone being needed. At most a year grace period should be given to a transferred entity before requirement to deplete usage.
Kevin Blumberg: Two things. First thing, I should mention this does not touch the 8.2 M&A transfer at all. The second thing is after the text was frozen, so that the community could look at it and we could get the guides printed, et cetera, the staff and legal came out. And two things came out of the staff and legal. Two very important things from staff. The first was that slow start is not used as a criteria for an 8.3 transfer. So that - all of those aspects of this proposal will get removed. The second part to this was that multiples are allowed. So the concern in this policy about not being able to do multiple transfers to handle a need or a transfer approval is not actually the case as well.
So there's definitely lots of text, as was mentioned, that can actually be stripped out of this proposal and we can start to get to the heart of it, which is looking at your rapid growth to look back which doesn't really get taken care of today and calculations like that to make it easier.
Dani Roisman: Dani Roisman with SoftLayer. So I appreciate how this started. I think it's a valiant effort, especially for new entrants, who can find the whole process intimidating. Someone mentioned earlier today they found themselves a part of their consulting business is helping with ARIN requests. That's all they do, for that one person, is helping with ARIN requests. It's definitely a difficult process. As Marla mentioned, of course, it will be difficult for an M&A process, et cetera. But I think we're going about it the wrong way. I think we're adding more policy to help make policy less intimidating, less complex. I've mentioned it before. I think the right way of doing it is just removing the barriers for all transfers. I think we have a pretty decent amount of data that we can collect from RIPE who has run a barrier free transfer functionality for a while now. At least we can see how many new entrants have come in and have transferred in and how much hoarding has occurred, et cetera. And I lost my third train of thought.
John Curran: Are you in favor or opposed to this proposal?
Dani Roisman: I'm completely opposed to this proposal because I think we're doing it the wrong way, and I think we should make a much simpler proposal that simply does away with 8.2 and 8.3 needs basis.
John Curran: With respect to this proposal, you're against it, is there any way it could be changed so you'd be in favor of it?
Dani Roisman: I don't think this can be changed. I think it has too much in it that I'm opposed to.
Owen DeLong: Owen DeLong, Black Lotus Communications. I speak in favor of abandoning this proposal. There is no change that could be made to make it palatable. Basically attempts to rewrite Section 4 and decouple Sections 8.3 and 8.4 from Section 4 when back in the days we advisedly put decoupling into 8.3 deliberately and subsequently 8.4 for very good reasons. The problems that we're now seeing expressed with Section 4 should be addressed by modifying Section 4 and not by decoupling 8.3 and 8.4 from Section 4, making allocations and assignments different from transfers to any degree larger than the amount of time has not had any really good logic put forth behind it. And I don't see a reason to do it.
Kevin Blumberg: Thank you. Martin.
Martin Hannigan: Martin Hannigan, Akamai Technologies. I'd like to just echo Dani Roisman's comments. I think that what we should be focusing on is eliminating needs testing altogether. I'm not in support of this proposal. It's way complicated. My head melted just trying to read it sitting here today. But I wanted to point out one section in particular. 220.127.116.11 where you talk about things like held equipment, current customers, customer orders, there seems to be a trend with policy that in my opinion is starting to cross the line with respect to interfering with our businesses. And I mean this in a good way. My competitors and my customers are on the ARIN AC and submitting this information to the staff is one thing. Having this stuff written into policy is a whole nuther story, and I think we should try to avoid that in the future. But I'm opposed to the policy regardless. Thank you.
Kevin Blumberg: Thank you, Marty.
Jason Schiller: Jason Schiller, Google, ASO AC. So as the originator of this policy, I'm going to apologize for its omnibus nature. I do also hate omnibus policies. But I felt it was needed. And the reason it's an omnibus policy is because it's trying to do a lot of things. It's trying to do three different distinct things. The first thing it's trying to do is it's trying to support slow start in a transfer market. We had heard from staff concerns in previous meetings that slow start with regard to the transfer market would be an issue. So it was trying to establish a way to do slow start in the transfer market. It was also trying to, in some sense, make immediate need less difficult but also give it teeth at the same time. So what it was trying to do with immediate need, rather than compelling you to deploy within 30 days, which I've heard from a lot of operators that have end sites that this is impossible for large organizations for large address holdings and that they simply just don't comply with it.
I wanted to give something that had teeth that was enforceable, something that ARIN could look at and measure and make a decision. So that was changed. There was a calculation as to whether we should simply make all of these changes in Section 4 and let Section 8 refer back to Section 4. I personally thought it was more contentious to change the rules in Section 4 with ARIN allocations and assignments because we are so close to the end of the game and it felt like changing the rules of the game. But if that's what the community wants, I am very happy to take that back and rewrite these changes into Section 4 and make Section 8 lean and slim and say it's everything in Section 4 with a few exceptions. I'm happy to do that. The other thing that this policy was trying to do was it was trying to make it easier for people to justify and get space and to have a predictable result. So what we did was the simply doubling.
You have to prove that the space you've got you're using and that shows that you have need for additional space. And if you can do that, then you can simply double and get another sized block that's equivalent to what you're currently holding. If you're holding a /16, it's more than 80 percent utilized, you can qualify to transfer one or more blocks up to the equivalent of the /16. The problem with this approach is it penalizes people that are growing more rapidly than that. People that haven't been growing for a long time and now suddenly have a new product and they're on a steep curve. So the third thing this policy tried to address was to deal with people that had rapid growth. The way it did this was basically take a look back window, measure what your run rate is, give you a two year supply. In short, the policy's trying to do three separate things. And I felt that we needed to do all of them together because if only one of these things passed, it would be unfair. So I apologize for the omnibus nature.
Kevin Blumberg: We have a question: The AC could go off and completely rewrite this. But my sense is - personally my sense is we'd rather have you come back with some new ideas than try to do something on your behalf that doesn't necessarily. And so do you have a preference either way? Is it better to come back with three smaller proposals for the community or to have the AC really dive into this? And I don't know if that's doable or not.
Jason Schiller: I'm happy to accept a laundry list of changes that the AC thinks would make policy palatable, that the AC thinks is what the community is looking for and I can rework it and send it back.
Kevin Blumberg: Thank you. Just to close this, if there's anybody in support, please come up to the mic. Otherwise, I think we're good. Thank you.
Draft Policy ARIN-2014-1: Out of Region Use
John Curran: Next up is Out of Region Use and it's going to be Milton Mueller, Draft Policy 2014-1.
Milton Mueller: Hello, everybody. Time to wake up. Do we have slides? We have slides. Yes. Out of region use is a policy that's been discussed now for two meetings. And in earlier iterations it was turned down in a couple of other meetings, and that indeed is the crux of the problem statement for this. It always has been that current policy neither clearly forbids nor clearly permits out of region use. Yet it's happening. Applications are coming in. There have been proposals to limit out of region use and they have failed both for practical concerns and because the community did not support them. The next logical option which the author of this proposal came up with was to try to come up with a proposal that clearly permits out of region use. And we recognize that there were issues raised by permitting that that needed to be addressed in new policy. This proposal would add a new section that simply states that ARIN registered resources may be used outside the ARIN service region and that such use is valid justification for new or additional resources. It tries to define what out of region use means.
It does that in more detail than you have on the slide here. I would recommend reading that part of the proposal on page 6. And then it comes up with a very important limitation. It says if you are going to justify your need for ARIN resources based on out of region facilities, you can't also use them to justify resource requests from another RIR, so called no double counting element of this policy. In order to avoid no double counting, the policy tries to come up with some documentation requirements. And I won't read this through. But fundamentally it tries to set a threshold below which we don't have to worry about this documentation. Above that threshold, it asks basically for a list, the utilization status of all resources of the same type held with any other RIR that is used or available for use within the requested service region.
We would apply ARIN policy to the determination of efficient utilization or utilization thresholds rather than the local RIR's policy. This policy has been discussed on PPML and it was just discussed the day before yesterday at NANOG at the Public Policy Consultation. And there were concerns raised in the staff and legal review. Staff and legal wanted us to clarify whether it is a whole registration or a portion of a registration that is referred to. They suggested it might be inconsistent with ICP2, which is a document passed by the ICANN board about the creation of new RIRs. It asked whether this policy would make ARIN subject to laws in other jurisdictions. And it noted there are US restrictions, legal restrictions in the US that would be applied to ARIN on dealings with certain countries that are not in the region. And it raised, somewhat speculatively, the potential for additional government oversight that might be caused by this. The reaction from the PPC, according to the reports I have, which are secondhand, I wasn't there, first of all, that there was strong support for the idea. There were also people who said: What are you talking about? Why do you need to authorize this? Hundreds of US firms are already getting non-needs-based /22s from RIPE, which apparently has no concerns about out of region use.
There was some questioning of or resistance to the documentation that would be required by this policy and some unresolved questions about how to best verify or enforce that prohibition on double counting. If you don't get into these somewhat demanding documentation requirements. And there were concerns expressed about whether we were creating some kind of trap by even making a distinction between in region and out of region use. So we can continue the discussion.
John Curran: Microphones are open.
David Huberman: I have a question for staff. David Huberman from Microsoft. This has been talked about for quite a few years now. And the genesis, which is easy to forget, is that the staff were put in a fairly awkward position as it started to get more and more petitions for address space from organizations who operate outside the ARIN region but were setting up equipment in ARIN's region to base the network and then they were backhauling the traffic to their home countries for use in customers in their countries which are outside the ARIN region. Again, bad for staff, bad for ARIN. Really bad position there if the RIR system was to mean anything. It's now 2014, and we're just about out of v4 address space. My question for John and Leslie is how germane is that original problem?
John Curran: Leslie, are we still receiving the requests from people whose equipment may be located here but their customer demand is entirely outside the region?
Leslie Nobile: All the time.
John Curran: Remains an issue.
David Huberman: If that's still an issue, I think the real brass tacts here for this community, in my opinion, are: Is the Regional Internet Registry still important, or is that idea deprecated by current events? I would - my opinion is I'm in strong support of this policy. The idea of RIRs make no sense to me anymore.
Milton Mueller: I think the key reason why they're getting these requests is that the unevenness of runout over the different regions. And, yeah, clearly if you have lumpy distribution of free pools, then you're going to get arbitrage or attempts at arbitrage across these free pools.
Dani Roisman: Dani Roisman, SoftLayer. So the Internet routing table doesn't have any preference for IP addresses in region, knows no bounds on geography. Works anywhere you announce it in BGP. I definitely agree this policy should move forward. I think the RIRs should have the same take on the physical location of an IP address as the Internet routers have. I think I agree there are concerns with the way the language for the double counting, whose policy efficiency utilization based on which RIR's policy, I think that definitely needs some massaging and rework. I don't have any good constructive feedback on how to rework it. But I definitely think the policy should continue and that out of region - that use of IPs in a geographic region which is outside of where the RIR is actually located should be completely permitted and not restricted in any way.
Milton Mueller: Thank you. The back mic.
Bobby Flaim: Bobby Flaim, FBI. I'm opposed to this policy for a number of reasons. I think number one the one David brought up. I guess we have a different take. The whole Regional Internet Registry system, at this point are we willing to disband ARIN and what it stands for and what it's doing and this might be something which would kind of lead to that. You know, also the verification. We heard from Leslie Nobile in the Barbados meeting when she was talking about companies from outside the United States trying to obtain ARIN IP addresses and there were problems with that, how do we verify outside the ARIN region, it would be more difficult. That's something that is actually a good service that ARIN provides. Some of the other things is are you willing to subject ARIN to outside laws, especially from OFAC countries which does present a sincere legal issue. So these are reasons that this policy would have very serious repercussions.
Milton Mueller: Online.
Heather Schiller: Marla Azinger, Frontier Communications. I have supported reasonable outside region use as I have seen there are circumstances where it is more logical for them to use specific RIR IP addresses. But when it comes to the transfer market, I'm not sure this should be micromanaged. I'll defer to and hope to hear from the companies that actually need this like Amazon, Google, and Microsoft to state what is or is not feasible.
Mike Joseph: How convenient. Mike Joseph, Google. I strongly support this policy. I think we all realize that an IP address can't possibly live in a particular region. Certainly not a prefix. We have IP addresses that span circuits across regions. We have cloud computing infrastructures. And we have Anycast. And today we have many parts of our IP space held by an entity in ARIN service region but used worldwide. ARIN's policy on this is something of a gray area and in fact ARIN staff interpretation of this has changed recently. So I think this policy is actually very necessary. ARIN needs clear guidance as to what the community wants in terms of ARIN's interpretation of global use. Specifically, this policy recognizes that ARIN exists to serve entities in its service region, not to provide addressing for its service region. And that's a very important distinction.
This policy doesn't change the fact that ARIN will continue to service entities which have a basis inside ARIN's service region. They'll speak English. They'll talk to ARIN. They'll deal in US dollars. But they'll deal with ARIN, their home RIR, for their worldwide needs. And that's an important aspect of what something that many of us depend on. For those entities here who operate multi national companies or multi national networks even, it's simply not practical to try to get address space worldwide. And nor should it be. I can't put ARIN space on one half of a link and RIPE space on the other, but nor should I have to. The fact is the RIRs weren't set up to create private pools for North American companies to use for North American purposes. They were set up to create entities which you could go to in your own language in your own region in your own time zone to be able to transact business with the RIR system. And this policy recognizes what's been happening for years now but simply needs to be codified. So I recognize that there are some rough edges, specifically the fairness of the /22. Specifically concerning the needs test for space outside of ARIN's region. And I'm confident that we can work through those. But this policy is extremely important to many entities here and I strongly support it.
John Curran: FYI, closing the queues for the microphones. People who are interested in speaking on this should find their way to one of the queues. Thank you.
Matt Petach: Matt Petach, Yahoo! I have a confession to make. I run a Global AS 10310. It was issued by ARIN and I'm using it in other places. I noticed that this policy says "resources." It doesn't say "IP addresses" or anything specific about that, which means that I've been in noncompliance or in the gray, fuzzy area for a number of years. I'm concerned as MJ was about the specifics of the address requirements that are listed in here. But I do think the general case of large global companies like myself, well, like Yahoo!, sorry, I'm not Yahoo!, but we do need to be addressed and codified. Thank you.
Milton Mueller: If I could keep you there for a second. Could I ask you about the documentation requirements and whether you find that burdensome or you have better ways of proposing that we enforce the no double counting requirement? Is that what you were going to ask him?
Matt Petach: I think there's some work that needs to be addressed on how you would validate and verify that the same items are not being used to justify space in multiple regions. I don't think that what is codified in here adequately encompasses that. I would almost actually suggest that we bring first the notion of, yes, recognize that resources are being used outside of the region. Codify that that part is acceptable and then do a second attempt at how do we propose strictures on that and do those particular strictures separately from the notion of, yes, it's okay to do this.
John Curran: I just had one little comment. Those of you whose Number Resources, ASN numbers, IP blocks being used outside the region, don't run and hide. You're okay. The challenge we have is not with the usage outside the region, it's when someone comes up and makes a request and they say this is entirely for use for supporting customers outside the region. Not some incidental use, not some amount, not split up my global network, but someone who comes out and says I need resources entirely for use outside the ARIN region, that's been problematic and, as we've said in the past staff report, in actually making that match ARIN's current statements in NRPM.
Milton Mueller: Heather.
Heather Schiller: Comment from Kevin Otte. Support. And I think many of the discussion points, especially Mr. Joseph's, can be applied to 2014-15 inter RIR ASN transfer discussion as well.
Milton Mueller: Back mic.
Terri Stumme: Terri Stumme, DEA. To save time, I'll just say first off ditto what my colleague from the FBI stated.But in addition to that, it says that ARIN staff would continue to require that all organizations requesting space would need to have a legal presence within the ARIN region. We discussed this when we put fourth 2013-6 wherein staff was unable to verify these organizations from outside the region. They would set up a shell company just to create a legal presence, but they were unable to verify who these entities were. That creates a problem for law enforcement when we need to find people in a hurry, when we're issuing subpoenas. In addition to that, I do believe it undermines the primary role of the RIRs to manage and distribute public Internet address space within their respective regions. Again, verification of these individuals is critical, critical to our ability to effectively do our investigations. So that's mine.
John Curran: I'm closing the queues in ten seconds. If you need to speak on this, please approach the queues. Five, three, two, one. Queues are now closed.
Jason Schiller: Jason Schiller, Google. I generally support this proposal. I think there are some language that needs to be tweaked a little bit. I think the most critical thing we need to fix is there's some text in here that suggests if you're holding space from another RIR - actually this last sentence on the paragraph on the screen - if you're holding space from another RIR, then that space will be judged as efficiently utilized based on ARIN policy. So that sentence reads: "The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy." I think that's problematic. I don't think that we as a community should be trying to enforce our rules on another region. If you're concerned about utilization of address space held in another region, you should apply that region's policy. So one possible rewrite is to change that to based on the applicable RIR policy. I understand that's kind of a barrier for staff to be conversant in all RIR's policies.
The other possibility is simply dispatch with that test and make sure double accounting isn't occurring. The way to do that is to ask the applicant to list all of the resources that they have and how they're being utilized. And a quick scan could make sure that nothing that's being used to justify space in another region is also being used to justify space in the ARIN region. That might be another way out, but it's a less strict standard. The second thing I think we need to address is this letting little networks not have to show what they're using in another RIR region. Basically the way I read this is if you need less than a /22 out of region, you're allowed to double dip. And I don't think that's what we want. And then the third thing, which was already in the previous slides as a reporting from what came up in the PPC, I am a little concerned about this defining what is in use and out of use, use of ARIN addresses.
I think it's okay if you want to charge me more because it's more difficult to verify my customers that are out of region. But I am concerned that this could lead to other policy, and I would just caution against that. We don't want to measure, for example, efficiency for in region different than out of region, for example. I think that would be a terrible idea. This policy is not suggesting that. But I am standing up now cautioning future proposers of policy that this would be a bad idea. I generally support.
Milton Mueller: Back microphone, Marty.
Martin Hannigan: Martin Hannigan, Akamai Technologies. I do not support this proposal. I'm a heavy user of MDN. Effectively every single, at least the way I interpret this policy, every single request I make to ARIN going forward would be subject to these draconian documentation requirements. Most notably "any". We already have Section 12 if we're concerned about nefarious activities with respect to the applications. And "any" is way too vague. My experience with ARIN would also lend me to believe that I would be the "any case" every time. We haven't had to specify one way or the other up to this point whether address use is allowed or not out of the region. I'm in the same boat as Matt. I apologize. I'm using my addresses all over the world because I can. They're globally routable and unique. I think if this is really a requirement and people really do want to go forward, I think that we should solve all the problems that it creates before we move it forward, not afterwards. Thank you.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I'm the author of this thing and trying to solve this problem. While I'm sympathetic to the idea that, hey, it's not a - we haven't had to specify this before. The problem as I see it is nothing to do with v4. It has to do with v6. People are deploying v6. They have global networks. Nowhere does it tell them are they supposed to get their global resources for their global network from their home RIR, are they supposed to get it from all five RIRs. They are left wandering in the wilderness trying to figure this out. They ask questions. They get cryptic answers. I'm tired of the crypt - the fuzzy nature of it all. This shouldn't be hard. You shouldn't have to have the secret decoder ring to know what you're supposed to do and what you're not supposed to do. So we need to say something in plain language. Now, that's a whole heck of a lot harder than it sounds.
So we've got to figure this out and we've got - and we can't open the door. We can't just open the floodgates for some metaphors that were used for some other things. There needs to be some reasonable restrictions. We find some stuff, we're working on that, we're trying to. But the first sentence of the whole thing is really what we're about here, and then it's, well, how do we make that first sentence work?
Milton Mueller: Got it. Okay.
John Curran: Thank you, Milton. Thank you.
Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update
John Curran: Moving right along. Moving right along, we now have ARIN Policy 2014-16, Section 4.10, Austerity Policy Update. I see Dan coming up. So it must be Dan.
Dan Alexander: Okay. The text of this can be found on page 16 of the Discussion Guide. So I was going to avoid going through all the details of the policy and kind of talk about this at a high level rather quickly to try and make up a little time. Mainly because the feedback that we got from the PPC this week was also pretty clear. There was conversation in Chicago and a lot of discussion about whether or not the ARIN region should have an austerity policy to ensure new entrants for a long time after the free pool ran out would have blocks. So this proposal was given to the AC as an attempt to do that. One of the first steps or approaches that it took was to try and replace the transition technology section, Section 4.10, which basically had blocks set aside to ensure for the deployment of NAT and other transition technologies into the future.
The feedback that we got at the last meeting was that that wasn't a good idea. A lot of people liked the transition technology section that's in place and should be left alone. So the rewrite of this was to leave that section intact and simply add an austerity section to that in addition. And in order to fund that, it was going to take some space from the block that was reserved for the transition technologies. The feedback that we've gotten from there is that that's not a good idea either, that people think the block that's reserved should remain. So the question becomes whether or not, one, this policy, this proposal is even something that the community wants, and/or whether this may just be a situation that gets overtaken by events, since if there's no way to supply IPs for this pool, is there a point to it. So what we're looking for, what the AC's looking for, is some direction whether or not we should continue to work on this; and if we should, where would that address space come from if you really wanted an austerity policy. Back mic, Mr. Blumberg.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I supported this policy. Initially I thought this was a great idea. Other regions have austerity policies. We should do something similar. Let's look out for the smaller guys. Then I realized we have an austerity policy. The community said, hey, do you want to get IPv4 space, get some v6. That's what our community has said. And I am a firm believer of that. I put in a subsequent policy that will show up sometime whenever on the list which deals with a routing technical issue which 28s are useless for new entrants if they want to be able to kickstart their network with v6 and change it to /24 just across the board. But that's a different issue. I firmly believe that once we run out in the free pool, if you want to use what's left in the free pool out of a dedicated pool, then, to put it colloquially, man up and get v6.
Matt Petach: Matt Petach, Yahoo! I'd like to echo Mr. DeLong's comments: That ship has sailed. Let's get on the v6 boat. The transition technology block is great for that little bit you need to tide you over but that should be the only purpose for it. I do not support this proposal.
Dan Alexander: Thank you.
John Curran: Anyone want to give feedback? I'm closing the microphones. One remote.
Heather Schiller: Marla Azinger, Frontier Communications. I don't support as written. That said, please correct me if one of my interpretations you're about to hear from me is wrong. First, I'd like to point out that this policy shouldn't be expected to be used a lot yet. This is a forward thinking policy. If it were getting used a lot right now, I would seriously be wondering what is going on with request reviews. Second, what is happening to the /11 that's being removed. And why is that being removed? I don't agree with just adding it to the free pool so basically one specific company of a certain size now can get a /11. Leave it alone and let it show how the other changes have an effect for a couple of years before you go yanking half of the available space away. Third, and last, I want to draw attention to the fact that this doesn't just tweak 4.10, but it changes it completely. This removes access to these IPs to anyone other than a virgin company with no affiliates. Currently it's open basically to anyone needing space for transition technology. That said, I do support this part of the proposal change.
Dan Alexander: To answer her question, the intent was the austerity policy put in place the mechanism so new entrants after the free pool depletion could continue to get small blocks. Where that space would come from, it was suggested that the /10 that's reserved for transition technologies would be split in half and an /11 would continue to be reserved for the transition technologies and the other /11 would supply the pool for these austerity allocations going on in the future.
Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate
John Curran: Next up 2014-17, Change Utilization Requirements From Last Allocation to Total Aggregate. And it's Andrew Dul. Come on up, Andrew.
Andrew Dul: Okay. This policy comes from the idea that there are some small organizations, smaller organizations that are having trouble justifying their next allocation because of the three month window and the sizes of blocks that they need. There's an example here. The example is also in your packet for you to read. For the sake of time, I'll encourage you to read your packet. And here's the text. In the staff review, the staff noted that the policy would have the potential to allow an organization which is very large to get a big additional allocation without actually using it. To fix this problem, there are three options that we have discussed.
The three options are here. During the NANOG PPC, it kind of seemed like we kind of coalesced around the second option, which is to add a requirement that every block must be utilized to at least 50 percent. Based on that feedback and the feedback here, unless it's different, the feedback from this meeting, my intent is to add that requirement to the text and send it back out and then hopefully we can make it recommended for the next meeting. So the discussion: Do you believe this policy needs to happen at all? And do you see a need to mitigate the issue? That is fairly clear that people believe this issue needs to be mitigated based on the PPC feedback. So in the interest of time, I'm going to ask kind of a smaller question set, unless you happen to want to opine in the same way as was earlier in the week. If you don't agree that we should move forward by adding the second requirement here to the text and bringing it back for discussion later, we would like to hear from you. Otherwise, I will do that. And we will talk about this next time.
John Curran: You've heard the plan. The microphones are open. Unless you speak, Andrew will add that second requirement and we'll see this at another meeting and on the list, on the PPML list.
Vint Cerf: Just to confirm, or at least undo my misunderstanding. In the second bullet, supposing that that's adopted, would that mean that someone could justify additional space if all the blocks were only 50 percent utilized across the aggregate?
Andrew Dul: What it would read was 80 percent overall and individual blocks 50 percent. The union of the two. We have a remote comment.
Heather Schiller: Remote comment from Marla Azinger, Frontier Communications. Part of this policy alludes to, and I strongly disagree that this is only a problem for small ISPs. Medium and large ISPs also have issues with this due to corner case issues. For example, purchase of a company but no IP addresses come with it. No policy exists for ARIN to address space for that renumbering. So instead the ISP has to run themselves out of address space literally before getting more IP addresses. There's also the situation of network upgrades that require massive coordination of bringing up new routers while leaving the old one up and running and needing efficient amount of IP addresses in both routers at the same time.
ARIN is not going to give address space for that. Yet again, your medium to large ISP is forced to scary short on addresses and coordinate new allocations in a very squeaky manner. This community really needs to stop itself and comprehend that every entity has equally straining circumstances and in opposition to that famous saying size does not matter. Be it 80 percent of last allocation for small, medium or large, it's frustratingly difficult and sometimes business interfering. I don't support this policy. And sadly I'm not really - I'm not sure there really is a policy that could be written to cover all of these situations in one swoop.
Andrew Dul: I would encourage Marla to send me a note if she has other ideas about how to fix her issue. But I would like to point out that I believe this policy actually makes it much easier for every organization if we adopt the changes as suggested to meet the allocation for next block. So I think this is actually making things a lot easier, not harder.
John Curran: I cannot conceive of a circumstance where someone would have a more difficult time under this policy. That's very hard, even with the added requirement of each block at 50 percent. Okay. I'm closing the queues. Get in the queues if you want to speak. Thank you Joseph. Okay. Queues are closing.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I generally support the policy. But I'm actually concerned that we're turning the wrong knob. We're turning a number but what we're not doing is defining what efficient utilization is. And I mean really defining what it is, because we're leaving this up to staff and that's why we have this policy in the first place is because staff's interpretation of efficient possibly conflicts with what the community's understanding of efficient utilization is. So my concern is that we will change this. Things might be wonderful, or what we could find is that staff reinterprets what the word efficient means and we go back to square one. I hope not. But that's the issue. We don't have a definition for "efficient." And I'm wondering if that is a simpler way of dealing with this problem, or it's needed to be added to this to really lock this up for the future.
John Curran: This would effectively change the current definition of efficient utilization of your existing space from nearly all, nearly all, nearly all of your existing blocks and 80 percent of your most recent block to 50 percent of all your blocks and 80 percent overall. That would be the definition of "efficient." If you have a better definition, I definitely want to hear it. But we're not going to create a new definition for "efficient." We're going to use whatever numbers this policy ratifies.
Kevin Blumberg: I guess I should clarify.
Andrew Dul: Are you asking about what the definition of "used" is because what counts towards 80 percent, is that what your question is about?
Kevin Blumberg: Yes. So my concern is that we have the numbers, 50 percent and 80 percent, but what is considered utilized, what is considered allocated, what could change and therefore - that's the word. Efficient utilization is the part that can change. What 50 and 80 percent actually means.
John Curran: Full agreement. The definition of what's utilized is very interesting. When you assign address space to a dynamic pool we spend some time looking to see what does it mean to be utilized, and then people who have address space assigned that's locked up in one way or another, the famous TPIA case where it's assigned because of resale. If this was going to be a measurement that we were going to need as an industry for the next 30 years, I would tell you we should have one page for every network technology and what defines efficient for that type of technology environment.
My question to you is: Is defining efficient, i.e., what is the numerator and the denominator for a given technology that's used to calculate what percentage utilized you are, is it worth going through that effort at this point in time or not?
Kevin Blumberg: Another way to put it is if staff embargoed what their definition and use of efficient was, I would 100 percent support this and we could just leave it at that point because then I wouldn't worry. If there isn't going to be an embargo on what efficient utilization is, then it's just a moving target.
John Curran: I don't understand what that means.
Kevin Blumberg: Embargoed means that the current way we understand efficient utilization doesn't get reinterpreted, which is why this policy is from what the author said, this is one of the reasons why the author has this policy here.
John Curran: The only - we're not going to change how we calculate usage. The only extent that that's happened is we reported in a policy experience report is 100 percent utilization of a past block gets very difficult to achieve in some circumstances. And we effectively consider it utilized because it's trapped. Someone is at 97 percent and can't possibly redeploy those last addresses somewhere else. But we don't change the definition of what we use. The only time we have we report it in a Policy Experience Report that 100 percent means fully utilized and it might be actually a little less than 100 if you isolated addresses in your network.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. I would accept either of the last two mitigations. The first mitigation is not acceptable. This policy has already been delayed more than it should. There are real organizations that really need this for a variety of reasons. As to the large versus small and now we're picking on the large organizations thing, you know, we can put whatever we want in policy but the reality is large organizations are going to have more difficulty getting blocks sooner than smaller organizations real soon now. Any organization that's currently large enough to burn through a /8 in three months is unable to get that allocation today. And pretty soon it will be any organization that needs a /9. And shortly after that it will be anybody that needs a /10. And we'll probably accelerate rapidly towards a /24 from there.
Mike Joseph: Mike Joseph. I support this policy. I came up because - first, let me clarify that. I actually oppose the additional limitations, first and third bullet point. The second one I see no problem with that. So I disagree with Owen on the third one at least. I came up because it seems like while we're discussing the finer nuances of the wording of this particular policy, there does seem to be quite a bit of consensus around it. So while I realize this is not recommended at this point, you said you'll bring it back, but I really hope that you can bring it back as a Recommended Draft Policy, because it seems that the community strongly supports doing something here and there doesn't even seem to be that much distinction as to what we should do, more about how we should word it.
Andrew Dul: Absolutely agree with you. I intend to bring it back as recommended at the PPC in NANOG in February. You should see text from me, a proposed text change from me in the next week, after I have a chance to work through that.
Matt Petach: Matt Petach, Yahoo!. I strongly support bullet point two. I will voice a certain level of concern definitely as Owen did with bullet point one. I don't think that has any place in a policy like this. I actually sympathize with Marla to some degree. I don't think bullet point three the aggregate /18 equivalent has a place as an arbitrary defining line. I think saying, all right, we're coming down to the last of the v4 pool, let's change our requirement slightly, bullet point two sounds wonderful. Let's make it fair and equitable for everybody across the scope of the size changes. Thank you.
John Curran: Queues were closed. Marty, go ahead.
Martin Hannigan: How does this affect MDN?
Andrew Dul: This is not inside MDN policy, so it doesn't affect.
Martin Hannigan: Especially bullet point two?
Andrew Dul: That's correct.
John Curran: Thank you, Andrew.
Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments
John Curran: Next up two policies, 12 minutes. R.S., come up, ARIN 2014-18: Simplifying Minimum Allocations and Assignments. I ask people at the microphones to speak whether you're in favor or opposed and be succinct in your remarks.
Rob Seastrom: This is one of a trio of proposals that talks about needs based allocations. The AC has taken the unusual step of summarizing it on one slide. Removes needs test for small allocations and possibly larger allocations. More on that in a moment. Imposes rate limit of one allocation under this policy per year. Problem statement: I'm actually going to read from the slide. I know this is a big faux pas but the type is - well, I guess we can - the type's okay but I'm going to read from the statement anyway so we're all on the same page.
New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative and time burdens of making their way through ARIN's needs testing process. For small allocations, the burdens of needs testing may exceed the value of the resources or may deter small, less, well-funded organizations' ability to receive an allocation from ARIN. As ARIN was created to provide Internet resources to all organizations within its geographic territory, this disparity in the policy manual needs to be addressed. The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation.
Policy statement. Again, I'm going to actually read from the slide. Insert into the NRPM possibly as 18.104.22.168 a minimum IP allocation size has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirements defined in any other active section of the policy manual, all organizations may apply and shall automatically qualify for the current minimum IP block allocation upon completing the normal administrative application process and fee requirements and all organizations shall be eligible for such an allocation once every 12 months. Where this is in conflict with any other section in the policy manual, this section shall be controlling.
So we have some questions. There's some support for loosening needs based number policy. Like I said, this is one of three that we have on the docket right now. Is this the right approach? What is a minimum allocation anyway? As of September it's /24 across the board. But there's some possibility it might end up being /28 in some cases. Notwithstanding some recent RIPE studies. When this policy was initially written it was not /24 everywhere. How does this policy proposal interact with the existing needs based allocation and assignments? Does order of execution matter? What if you apply for your free /24 before or after applying for some needs based address space? Is this address space counted? Could you get a free ride if you asked for it later? This section shall be controlling verbiage is, this would be the only policy that has it in the NRPM. And it's possibly a problem.
There has been little support and a fair amount of opposition on the mailing list and we'd like to hear from you. Please step up to the microphone.
John Curran: Microphones are open. Please express your interest or concerns about the proposal.
Leif Sawyer: Leif Sawyer, GCI Alaska. When I was growing up, I had a grandfather who would give me $20 every year on my birthday. I didn't have to ask for it. It's what this policy seems like. It's grandpa ARIN giving me a /24 every year on my birthday. And while that sounds great to me, it also sounds like a great way to run up the free pool which actually might be a great thing. Right, Owen? But there's a part of me that says that's a really bad thing. So no, I'm not in support of this.
John Curran: Any change that would make you in favor?
Leif Sawyer: Abandoning it.
Joe Provo: Joe Provo, Google. Strongly opposed and it cannot be repaired.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Strongly oppose. This is actually different from the other two policies. This is a Section 4 policy. This is deleting the free pool in a way I'm very uncomfortable with. And I'll leave it at that.
Adam Thompson: Adam Thompson. Last company that I worked with that required an MDN allocation was perfectly successful under the previous amendments. And I can't see any realistic circumstances where the new amendments are necessary. They might help slightly but they're not mandatory. They're not required to actually achieve your goals. And so to me this seems like just a needless change. I do not support it.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. As Leif pointed out, this policy has one attractive quality. It would drain the free pool. That's not enough. Everything else about -
Rob Seastrom: You support making it like a /8 every year?
Owen DeLong: No. I support abandoning it. As I was beginning to say, that's not enough in the positive column when you consider all of the negatives. Number one, the problem statement is fundamentally flawed. There is nothing all that onerous or burdensome about the ARIN process for a small end user. I have helped many, many small end user organizations and small ISPs get small blocks from ARIN. It's just not that hard. If you have an actual need for address space, it is very easy to fill out the form, put in the right answers to how you're going to use the addresses and get your address space. It takes a few days now because the workload's gone up as a result of runout, but that's to be expected. As appealing as it is to find some creative way to just get rid of the free pool so we can get on with v6 and be done with it, I don't think this is the right approach to doing that. To paraphrase Cathy - sorry to pick on you, Cathy. We all like ponies. But this pony is a dead horse and we should stop flogging it and abandon it.
Rob Seastrom: Center microphone. Front center.
John Curran: Closing the microphones. Approach the mics if you wish to speak. Queues will be closed.
Matt Petach: Matt Petach speaking for himself only. I support this policy long enough for my refrigerator to get a /24.
Rob Seastrom: We have a remote comment.
Heather Schiller: Marla Azinger, Frontier Communications. Opposed to this. There is no fixing it.
Rob Seastrom: There's no what?
John Curran: Fixing it.
Rob Seastrom: Irreparable. Last chance for microphones. The chair will kick me off the stage in five, four, three - bye.
John Curran: Thank you, R.S.
Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization
John Curran: Our final policy proposal for the day, Draft Policy 2014-19: New MDN Allocation Based on Past Utilization. And we'll have Andrew Dul come up.
Andrew Dul: I'm between you and dinner and beer. All right. Let's go. This policy is a follow on to work that was done earlier this year around updating the MDN policy. And as part of that policy, we defined two methods to permit a new site to obtain an allocation. This problem statement notes that a third option is needed for sites which won't qualify under immediate need and have a larger requirement than the minimum. I already said that.
Policy text: Basically there's a rewrite but really the bottom bullet is only the only addition. It says a three month supply if there's an applicable one year utilization rate, specific to the use to be covered by a new MDN on to which to base a three month supply. So we now, if this policy were to be adopted, we have three methods to justify a new MDN site: Immediate need requirement; use current minimum allocation, /24, or use the three month supply based on prior utilization. Comments on this text and whether or not you support or do not support this change.
Adam Thompson: Adam Thompson, Manitoba Exchange. Reiterating my comments from the previous one. This change does not appear to have any harmful effects but in my opinion it also seems to not be necessary. So I can't say I oppose it but nor would I support it.
Andrew Dul: Not necessary because you do not know of an organization who would use it or -
Adam Thompson: I believe that the existing criteria are in fact adequate. The modification would make life a little bit easier for certain organizations, but it does not impede their ability to conduct business.
Andrew Dul: Rear microphone.
Martin Hannigan: Martin Hannigan, Akamai Technologies. Do you want to summarize the PPC conversation on this or -
Andrew Dul: You're welcome to if you would like.
Martin Hannigan: I think you should take a crack at it.
Andrew Dul: During the PPC conversation, Marty raised concerns about the current language which states evidence of need is a concern to him and his organization. I'm sorry, evidence of deployment. And that he would like to see that part changed.
Martin Hannigan: My point being that I'm not sure how you can deploy a network without IP addresses. Seems like the policy itself broken to begin with. And I'm not necessarily in favor of the changes that you're making now, but I would probably have no comment if you actually would fix that particular point there. I think it's fair game since the policy is being reviewed and potentially changed. I think that again I'd like to echo my earlier comment that we seem to be crossing some lines with respect to how deep you want to delve into our businesses, which I'm not necessarily disagreeing that you don't have a right to ask us to justify our needs. Although, I think we should eliminate needs as we've said many times at the mic, but I think there are more effective ways to do this up to and including the officer attestation.
Most of us work - not most of us, some of us work at public companies and those things are taken quite serious. In fact, every time I have to have one signed, it's at least one to two hours or multiple meetings to make sure that the executive signing the document actually understands what we submitted and that it's accurate. So I would like you to change that. And if you do, I might actually support this.
Andrew Dul: Let's collaborate on what we should change it to.
Martin Hannigan: Just take it out, go back to the old language that says submit a plan. We make plans and we know how to do that. And it had worked up to this point.
Heather Schiller: Remote comment from Marla Azinger, Frontier Communications. I think the current policy works. While I understand the point here that a new discrete network needs address space to fit the load being moved over on to it, this does not explain the amount of address space left behind in the network it left. What if this now makes the region or network it left have only a 20 percent utilization? If in fact these discrete networks don't have separate org IDs, then there's no reason that address space can't be moved over with them. Or at least to help accommodate the move ARIN approves just a small allocation for this current policy to get it started and then you move IPs as you move clients.
Otherwise, there are a lot of networks that could play this game down to the city and just start splitting things up with the new ASN and get a lot more address space for each of these new ASN supported discrete networks.
Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. Yeah, I suppose there are a couple of ways this could be gamed. But the reality is it's a lot of effort to game it to any level of significant gain. And I don't think that the free pool is going to last long enough for that to matter all that much. On the other hand, we do have real networks that are really running into problems trying to grow and need this policy. So I think we should move forward with it. On the evidence of deployment versus a plan, there are lots of ways to show evidence of deployment that don't require you to have invested in maybe I'll get my addresses, maybe I won't.
You can get letters of intent. You can get various other things that show you're serious about deploying and use those in a way that meets the test. I don't think that's going to be a problem for most organizations. But anybody can write a plan for anything. And I can write a plan to deploy 16.7 million virtual machines tomorrow on a Linux box in my basement and ask for a /8 under immediate need. Not a great idea.
John Curran: If folks would approach the queues, I'm going to close them in ten -
Martin Hannigan: I wanted to address Owen's point. Sure. Anybody can make up stuff. It happens all the time, whether it's someone asking for a /24 or potentially larger. And I think that the vast majority of us are actually honest, hard working people that just want to get our addresses and operate our companies. And I think punishing us with - frankly, it's a ridiculous requirement. It's a complete oxymoron to expect me to go spend millions of dollars in capital, have millions of dollars in capital expenses only to not be able to justify the addresses and have my equipment sitting there effectively unused or underutilized which is another problem in itself. And obviously the free pool is being reduced. But I need a way that I can actually operate a business and submit plans that are reasonable. And I'm willing to compromise on that. But as it's written, again, I think it's pretty ridiculous. Thank you.
Mike Joseph: Mike Joseph, Google. I support this policy. Marty's comments notwithstanding, I'm not suggesting whether we should or should not change the particular section around deployment. I think that that's a conversation we should probably have. And I wouldn't have any problem seeing that conversation incorporated into this policy if we have consensus on that point. But at its face, the point of this policy is to allow entities which have MDN's to essentially split an MDN. You have an MDN. You need to split it up. This allows you to get address space for the new MDN based on the user's load or whatever resource will move into the new MDN. This is a real problem that real networks have. And I don't think that there's a lot of opposition to the idea of splitting an MDN. And I don't think we should make it harder to do so. So I support this policy. I support it as written. But I also welcome a discussion about the points concerning deployment.
Andrew Dul: Any other remote? Heather, any remote?
John Curran: Thank you, Andrew.
John Curran: We're actually not that far behind. We are approaching adjournment for the day. Between us and adjournment is Open Microphone. I will moderate the Open Mic session. Microphones are open to raise any matter. We'll have one of these today and one of these tomorrow. Okay. Center front go.
Dani Roisman: Dani Roisman, SoftLayer. I wanted to bring up some discussion I learned this week. I'm still exactly not sure how accurate this is. But as you've heard, I have concerns about needs-based transfer. I am actually a buyer in the market for my company to ensure we have IPs that we need to continue to grow. Immediate need and continued growth. One of my concerns was within ARIN in order to complete an 8.3 I'd have to find a buyer, attempt the 8.3, and if the 8.3 doesn't work I have to actually back out my deal with the buyer.
I have been hearing that in fact you can essentially pre-register for an 8.3 using the STLS Transfer Service. I only learned that in the hallway conversations here. I did confirm with a few registry services folks. I wanted to propose we somehow make that much more clearer in the ARIN documentation and discussions.
John Curran: Excellent idea. Yes, you can prequalify for a transfer. We'll tell you exactly what you qualified for. And that actually, I mean in theory you could have an auction, if you had all pre-qualified bidders bidding and know that that would complete. We would process the transfer when it was completed as long as what was transferred matched what each one was pre-qualified for.
Dani Roisman: In addition to making it more clear in general, also would be nice to know what happens if I get pre-qualified but in between my pre-qualify and when I actually submit an 8.3 I could submit an 8.2 in the meantime, or if I get an actual direct assignment in the meantime or whatnot.
John Curran: Some of that is actually on the website. But we need to make it more clear. Thank you. Good point. Center rear mic, Marty.
Martin Hannigan: Martin Hannigan, Akamai Technologies. In our earlier discussion we were talking about eradicating needs testing, and the voices are growing louder. I think that some of the slides that said there seems to be some interest in eradicating needs-based testing are actually kind of trying to pour a little water on it. I think it's a lot stronger than we're being - you guys are letting us on to believe. And I think that there doesn't seem to be the ability or time or place that we can actually have the discussion as to what the compromise might be. I want to throw a quick idea out there. I have a little experience with surge in terms of the staffing issue, if that really is the issue, which I do believe you have the surge issue. Why not automate and maybe self-certify the applications and increase the questions that you ask and document them and do something like the TSA does, pull every nth one out and actually do an audit and verify them and address your surge that way? I don't know that that would absolutely work for everyone or for you, but I think it's really the time to start thinking about alternatives to needs testing. Thank you.
John Curran: Marty, three questions: First, are you talking about needs testing for transfers or for assignments?
Martin Hannigan: Transfers.
John Curran: Second, you suggest that there might be alternative approaches and so it's not the ARIN staff job to explore that -
Martin Hannigan: I understand. I'm not trying to imply that, but seems we're out of time.
John Curran: Do you want to have a discussion among people here? We actually have a breakout room today or tomorrow you can use, or do you want to submit a policy proposal?
Martin Hannigan: None of the above. I think it should just happen. Thanks.
John Curran: To the extent that people want a different approach, the way to do it is to get a policy proposal and get it submitted and you guys can find Marty and figure out what that says.
Dani Roisman: Can we get a breakout room?
John Curran: Yes. Grab any AC member, we know where it is.
Martin Hannigan: I'd be happy to participate and I appreciate that. But we had the opportunity to poll the room with respect to that question. I believe Mr. Huberman suggested it. And he was pretty much shot down out of hand.
And I'd like to - and I actually saw something funny on the Twitter feed. Are they really taking a poll to take a poll? So I would appreciate it if you would consider having a poll to have a poll. Thank you.
John Curran: Recognize we only do - if you have a presentation and you submit something, we would actually poll. But it's hard to have people raise their hands and say do you want to eliminate something when they're not sure whether it's everything or transfers, under what circumstance. So we need to have clarity before we ask the room something. Otherwise, we'll all have a different idea what was polled. Okay. Center microphone. Go ahead.
David Huberman: David Huberman from Microsoft. My question I guess is for Mr. Sweeting. I'm a little confused about the PPC. This is the meeting that happens at NANOGs on Tuesday mornings. Okay. He's deferring to Mr. Curran. All right. So Andy said he's going to take the policy proposal he's shepherding, bring it back probably as a recommended draft at the next PPC. So I don't get it, because most of the Board's not at the PPC. Roughly half, maybe a little over half the AC was at the PPC this time. And there were maybe six or seven or eight folks who got to the microphone over the course of four or five hours. And this was a well attended PPC. So can you explain a little bit more about what the purpose of future PPCs is and how they really fit into the PDP for the AC.
John Curran: The AC can make use of a Public Policy Consultation at NANOG as a meeting for opposing, for finding proposals or for measuring support in order to recommend something to the Board.
David Huberman: Okay. So there are five physical meetings now, five in-person meetings with remote participation. And the policies -
John Curran: Two ARIN meetings, three NANOG PPCs. Lots of opportunity to improve policy.
David Huberman: I don't necessarily know how I feel about that. But I do know that I don't like the fact that many of our elected representatives aren't attending that.
John Sweeting: Dave, a lot of the AC members do participate remotely. The ones that aren't there, especially if they're shepherds and their proposal or policy is being discussed there.
David Huberman: So this meeting, fairly well attended, how many AC members were actually watching in there, roughly?
John Sweeting: I believe we had the majority of the AC there this time with the exception of a few that were traveling to get here.
John Curran: Recognize that there's only a few AC members who are the shepherds on a given policy proposal.
David Huberman: But they decide as a body whether or not to advance a proposal, right?
John Curran: Based upon a show of support by the community. The other AC members are there to confirm that that's what they heard. It's not as if you're trying to get X number of AC members to support your proposal. They're all checking each other to see what the shepherd said is accurate. So as long as the shepherds are there and there's enough community, if you believe there's not enough input at the PPCs to safely poll the community and
that those shouldn't be used to advance policy proposals, I want to hear you say that, and that's something that I'll take to the Board. The Board right now, we've talked about it, I've said the AC has asked for flexibility. We do look at the counts of how many shows of hands there are before we advance. If the next PPC has 14 people in the room, I don't think it matters whether or not those 14 want it, the Board may say that's not an adequate support. But it is something we look at.
David Huberman: To answer your question, before this meeting, and in some respects before the Bellevue meeting, in May, the PPCs were very poorly attended, in my experience, with very poor participation. The last two NANOGs have been wildly successful, the two largest NANOGs in NANOG's long history. But I look at who was here today. And I look at who was in the room, and there's a lot of overlap. Not a whole lot of separate operator support of our ecosystem, our Public Policy ecosystem at the PPC such that -
John Curran: So what's your proposal?
David Huberman: I don't have a proposal. I just have a real concern that the PPC is inadequately representing the community.
John Curran: And so we should do what?
David Huberman: So I am forming an informal working group to look at this problem or look at this situation, define the problem statement and actually give concrete suggestions to the Board to increase participation.
John Curran: Sounds like a great plan.
John Sweeting: So this is just another tool that we have that the Board has provided to us. And we're very cognizant of the fact that some PPCs, it's not well attended, and it's not that - you won't find that often that we'll take something that's never been to a PPM and take it all the way through, unless it's something like the one that was so greatly supported by the community on the List that we felt it was incumbent upon us to actually speed that through the process, and because the community was asking us to. So I mean, it's not like we try to sneak things through the PPCs or anything. As a matter of fact, we usually say we want to get it to the PPM.
David Huberman: I appreciate that. And to clarify, when I said AC members weren't there, I'm not talking about the individual members, not the AC in general, just the mechanism of the PPC is a bit scary to me because it's low attended.
John Curran: We've had low attendance. It's getting better and better. But we also try to be a good co-host with NANOG, which means we accept the constraints of location, room and time that we have. People want to respond just on that topic? I see people arriving. Go ahead.
John Sweeting: Also, this was put in place to address the concerns of a lot of people that while the cycle was just too long, especially if it ended up having to go to two meetings. So that's why this really works well. We get it to two meetings. One may be a PPC, the other one a PPM.
John Curran: Gives you a more refined policy when you get to the PPM.
Cathy Aronson: Two things: One, we're all aware on the AC about the PPC. But the other thing I wanted to say is that I think this joint NANOG/ARIN thing, you know, it makes our meeting here really short. And we don't have as much time to discuss the policies as we used to. And that concerns me as well.
John Curran: I guess what would you ask us to do?
Cathy Aronson: I don't know entirely. Like maybe somehow combine the PPC and this meeting, because we do it twice in the same week. I don't know.
John Curran: Something that's worth thinking about, this is something that the Board has actually talked about a couple times -
Cathy Aronson: Because the other NANOG meeting is a separate PPC. That's actually kind of good because we might get feedback that we can use on the AC. But this just becomes a little frenetic.
John Curran: Something to recognize. We actually polled the whole community, ARIN and NANOG, and one of the questions we asked specifically was, hey, should we combine so ARIN would have a distinctly blocked off track, we would just meet during NANOG, have the ARIN Day or something, it would be blocked off and we wouldn't have to - like NANOG might go another day, maybe go four day NANOG, of which we take one day in that. And we meet at every NANOG.
Or we do the ARIN days after every NANOG. But we only meet three times a year co joined with NANOG. That was one proposal. The other proposal is maybe this PPC isn't right and we should go completely separate. The community actually on all the polling questions we sent out last year split 50/50. Right down the middle. And I actually presented this to the Board in January and again we talked about it in August at our strategy workshop. It's not lost on us that we have two ARIN meetings, three NANOG meetings, two of which overlap, giving you a one, two, one double weird schedule. We're open to suggestions. I'd love to hear the community galvanize itself and tell us this is where we want to go. This is your meeting and how you want to schedule it. We do have some constraints when we work with NANOG. Some people say those constraints aren't worth it and we shouldn't be doing this.
But other people pointed out there's more operators there. And even if we only get five more operators, they have a different view that may not be in this room. So we're very open to suggestions. So back on this topic, PPCs and NANOG.
Jason Schiller: Jason Schiller, Google. I have similar concerns to David Huberman about the kind of limbo status of the PPC. Either make it a real meeting so that I can get my employer's attention and send the AC there and we'll have a real meeting and we can talk about draft proposals and move them to last call, or make it not a real meeting and don't move proposals to last call. That would be very helpful to me.
John Curran: What's your preference?
Jason Schiller: I don't care. Make a decision.
John Curran: We want your preference. Those are two different directions. You actually have to turn the wheel one way or the other.
John Curran: You're in the median right now. There are roads on both sides.
Jason Schiller: I think the cycle is long and probably more than two meetings is beneficial. But it needs to be - if we're going to move things to last call, we have to be very clear about not calling it a PPC. Call it an ARIN meeting. And bring the AC and bring the Board and let's have it properly attended. I think that the PPC as it stands now is not very valuable.
John Curran: One question about bringing the Board and AC. I don't know, - I can imagine bringing more AC members so they can see the spirit of the room firsthand, because they are actually all going to be in a room talking about the level of support and the conversation and what they heard. The Board really doesn't do a lot during the policy. I'm not saying - my dear Board, direct supervisor, doesn't do a lot during the policy discussions. We're happy to do it. But we're also sensitive to travel. Do you really want to fly the whole AC and whole board in for every meeting.
Jason Schiller: Certainly the whole AC and I would expect a lot of this community to show up. If that's not happening, I don't think it should be a real meeting.
John Curran: Okay. Thank you.
Jason Schiller: If it's not a real meeting, you could certainly do something else with it. You could make it a workshop where people craft policy. You could make it a specific discussion.
John Curran: I'm trying to ask you what you want to do. Now you're talking about both of them.
Jason Schiller: Get operator concerns how would this affect you as an operator if this policy were to come true tomorrow.
John Curran: That's what the PPC's about.
Jason Schiller: No. The PPC as it's run today is just like this meeting. It's not specifically focused on imagine this policy came true, what would be the operational impact, for example.
John Curran: If you want us to go that direction, you should write that up so we know what it is. The operation impact workshop of a policy, because that's a new thing. I think it should be written and discussed by everyone.
Jason Schiller: All right. I'll send a mail.
John Curran: Other comments on NANOG and the PPCs. Back microphone.
Mike Joseph: Mike Joseph, Google. I'll give you some specific suggestions, first off. Five meetings a year is too many. Five-policy making meetings a year is way too many. If you, as all of us do, have an interest in policy, that means that anytime a policy could be advanced, we have to be present to be able to speak on it. That is too much travel even for members of the Board and AC, in my opinion.
John Curran: There's remote participation.
Mike Joseph: It's not as effective.
John Curran: I know at least one remote participant who would disagree. I think we could have two or three, and it would still be just as effective.
Mike Joseph: They have the right to disagree. I think it's not as effective. Secondly, as far as my specific suggestions, I would suggest that we bring back the John Curran or whomever, giving a talk on the On-docket Report and a PDP and a brief description of how one might participate. But to actually incorporate that as a talk at NANOG every cycle or whenever you want to do it. I think that would be a fine way to inform the operator community of what's happening at ARIN and invite them to come partake in the ARIN process, which exists for folks who are able to talk about the policy in a, where we have the time to talk about it and where we have the full membership and representatives here to have that discussion. So I would suggest the two ARIN meetings and I would be possibly open to one tacked-on day to one of the other NANOGs. I think people have voted - people I've talked to seem more in favor of June than February. I'm somewhat ambivalent on that point. But I would support that, that would be three, way better than five.
John Curran: Joseph is there. Everyone sees him. People who like that schedule. Go get him and let's write that up. Because there's no reason we have to have a schedule we presently have. It is the position that has the current inertia and a good proposal to the contrary would definitely move us off the spot. We just haven't had a good proposal to the contrary. NANOG and PPC. We'll close the topic. Final comment.
Adam Thompson: Adam Thompson, speaking purely as myself to provide my perspective as a first-time NANOG attendee, first-time ARIN attendee. I would happily have given up a social, free drinks, free food, to attend the PPC. I am not going to give up the NANOG technical talks to attend the PPC.
John Curran: Good to know. In terms of specific changes?
Adam Thompson: Either run it the morning following NANOG or on an evening right after NANOG or in the middle of the NANOG track as dedicated time. But don't ask me to choose between the NANOG tracks and the ARIN track. Put them together at the same city in the same hotel at the same time, that's fantastic. I only have to fly one place once.
John Curran: What track conflicted for you this time?
John Curran: There was a Yang Tutorial that was contrary. And even tutorials get in the way?
Adam Thompson: Any technical content is my primary reason for being at NANOG. My primary reason for being here today is the policy content, and you're forcing all the operators who are not purely policy focused to pick which one's more important and pretty much every operator's going to pick operational.
John Curran: NANOG has been very good, the program committee, in keeping us deconflicted. That wasn't the case at first. But now we only generally run contrary to tutorials. But you're saying that's still a conflict? Good tutorial. Even tutorials, that isn't enough deconflicting, we need even more, is what you're saying. Are we done with NANOG PPC?
Matt Petach: I will just say I unfortunately represent the program committee. I want to take that back to NANOG because that was something we talked about at the program committee lunch. Both sides are kind of realizing this. Thank you for bringing it up.
John Curran: Done with the NANOG PPC discussion? Because if we don't close this discussion we'll get to actually continue a meeting into a social, which is what you're suggesting earlier. Brandon Ross: Brandon Ross, Network Utility Force. The choice between PPC and a social. I do want to point out that many of us, while we are drunks, also get a lot of work done at socials. So socials are actually - socials are very important to my business. I would have a difficult time choosing between -
John Curran: Done with NANOG and PPC. Now all other topics. Microphones are open. Center front.
Owen DeLong: Owen DeLong, Black Lotus Communications. I actually was standing up originally to comment on what Marty had said about removing needs basis. Removing needs basis itself obviously is a policy matter. But some of the other things he touched on were modifications to how ARIN does what they do in response to the existing policy. And those would be not policy matters but should go through the ACSP.
John Curran: That's correct.
Heather Schiller: Remote comment, Kevin Otte. I wanted to clarify something. I think it was Kevin Blumberg said during the austerity measures discussion, he said that we have such a policy, get IPv6.My confusion lies in how IPv6 impacts IPv4 allocation. Can you get more IPv4 if you just have IPv6 allocations? Or do you have to demonstrate utilization of those IPv6 allocations as well? That's one comment. The second comment is about remote participation. If there was some way to eliminate the lag and let us speak directly rather than a human to text speech engine, I think that would dramatically improve the effectiveness.
John Curran: They'd prefer to have an automated voice rather than you.
Vint Cerf: No, a microphone -
John Curran: In real time.
Heather Schiller: Really, I'm all right with it.
John Curran: Understood. There are technologies for that. Okay. If you want to respond, Kevin, to the first point, i.e., IPv4 and transition.
Kevin Blumberg: For many years to come, without IPv4 you will not be able to do IPv6. You need to be able to bootstrap your network with critical infrastructure with mail servers, with whatever to be dual stacked. And I believe it falls under the spirit of what this is. No, you're not going to be able to get v4 for everything. That's what the transfer market is going to be for. But to get what I would consider an austerity /24 which allows you to continue to operate or to start to operate on the Internet getting v6 and having v4 for the bootstraps for the things you need to me seems like a perfect legitimate use.
John Curran: Folks, I'm going to close the queues. Now we're just going to drain the queue. If you have any topics, go. Center microphone. Go ahead.
Seun Ojedeji: This is Seun. I have three comments. My first comment is to the NRO. I'd like to ask or call the NRO to please kindly release the process for generating the single proposal for this region, the IANA transition. Please release it as soon as possible. I'm scanning, and I see that Liz (phonetic) is actually in the room. I would like to hear from him what is actually delaying the release, and is there a timeline on when the process would be released? My second comment is a minor one, in relation to the website program. I would appreciate if I click on each of the policy identifiers, I would like to see a link or a content for the policy. Right now you click on it, it just shows me the shepherd name.
John Curran: The link on the agenda? Good point.
Seun Ojedeji: This is my first ARIN meeting and I'd like to thank you for tolerating me.
John Curran: Regarding the schedule, process of the NRO we'll use: As soon as we have one we'll publish it. Actually some of the input discussed today will go into that because there's already been mail back and forth. But we can't publish something that hasn't been settled. At least enough that we can say this is our proposal. But it's going to happen very quickly. I know many of the groups next week in ICANN expect to hear what the RIR process will be. So we have to have something coming out very shortly. Rear microphone. Center rear. Microphones are closed. Go ahead.
Izumi Okutani: Izumi Okutani from JPNIC and speaking I suppose on behalf of the APNIC community. I'd like to share a question that was raised in the last APNIC meeting related to utilized justification for inter-registry transfers. As you know, we do have justification criteria in place to be compatible with ARIN policy for APNIC and ARIN to do their transfers. And I believe RIPE region will be adopting inter-registry transfers, which means APNIC and RIPE region will start the transfers. And RIPE region doesn't have the justification criteria. The question from our community is: Would this affect ARIN community criteria to do the transfers with APNIC community by us doing a transfer with RIPE region, which does not have the justification criteria? If the answer is no, then that's fine. But if you have any concerns, then it would be really helpful if you could give us your feedback, before the coming APNIC meeting in February 2015 so that we can start the discussions.
John Curran: Excellent question. Let me rephrase briefly. Because we currently have compatible needs-based policy with APNIC and APNIC soon will have compatible policy with RIPE that doesn't involve needs test, the fact that they have an inter-RIR transfer policy with RIPE that does not involve a needs test does not change our assessment of our transfers to their region. So staff has reported that in fact we'll continue to do inter-RIR transfers if an organization and ARIN transfers to an organization in APNIC as long as APNIC continues to apply the needs test that it will for that transfer, that transfer is fine. We'll have this potential that organizations in the APNIC region will transfer them to the RIPE region and no needs test will be applied. This is what would happen by default or is possible by default on the current policy trajectory that's in place in the APNIC and RIPE regions. And so it's actually bringing that to this region's attention. And to the extent that our policy is now not best in that, that's something for this region to consider and either speak in those regions or speak here with policy proposals. Is that appropriate? Thank you. Someone wants to respond to that.
Kevin Blumberg: Kevin Blumberg. I would just like a clarification. If an entity in the APNIC region can justify a /16, gets the /16 from somebody in the ARIN region, transfers it then off to somebody in the RIPE region without any need, then comes back to the ARIN region, says I need a /16, look, I'm out, transfers it off and says, look, I'm out, transfers it off, is that okay?
John Curran: In the ARIN region we would ask APNIC each time does this party have the appropriate need. If they said yes each time, we would complete the transfer. That doesn't answer your question, but it tells you how we process the NRO transfer policy.
Kevin Blumberg: Thank you.
John Curran: Center front.
Matt Pounsett: Matt Pounsett, Rightside. I wanted to echo something that Cathy touched on earlier.
John Curran: The queues are closed. If you're not in the queue, don't approach it.
Matt Pounsett: I'm a little concerned about the compression of the agenda, that we're at the same time getting more policy proposals every year and less time to discuss them in. I'm not exactly sure what the fix is for that other than possibly running all day on Friday. But I'm not sure I like that at all. I don't have a good suggestion for the fix, but maybe something to be thinking about.
John Curran: For context. We have a huge crop of policy proposals right now. If we have that in three years, we definitely have problems, and we're not set up correctly, because I don't think we can sustain this level of policy development with the current meeting structure.
You can address the meeting structure. Note that meeting structures laid in advance with hotel contracts and things like that. So if you address it in the meeting structure, that also is a multi-year process.
And so you have to sort of look out and say where are we going to be; is this still going to be a problem; does the depletion of v4 change the policy volume? Yes or no. So add the time lag to solve anything to that dynamic, but it is a definite circumstance we're facing.
Matt Pounsett: I suspect at least for the moment anyway the difficulty is in with the meeting structure, because when NANOG moved to starting on Monday, that moved us from two and a half days to one and a half days. And, look, that seems to be the more immediate problem. And similarly to losing time to discuss policy proposals, we've lost things like the Policy Hour where we can do discussion of the PDP. I haven't seen an outline of the PDP in probably two years. And it's changed in that time. Since I'm not going to the newcomers lunch where that stuff is presented, not being a newcomer, I think we need to look at the meeting structure and see if we can figure out a way to have more time to do things in.
John Curran: You think more time per meeting is necessary, even if it means changing where and when we meet?
Matt Pounsett: I think it would be very useful.
John Curran: Thank you. Center middle mic.
David Farmer: David Farmer, University of Minnesota. I wanted to quickly thank the people, whoever was responsible for choosing jazz last night, thumbs up. And also the volume level of the music at last night's social was perfect. Can we do that again?
Ole Jacobsen: Ole Jacobsen, IPJ. Today is October 9th, International Postal Day. I looked it up. The announcement from NTIA was on March 14th. That's by something in Norway called, American measure, which means roughly not very accurately seven months ago. And I'm really surprised, speaking of compressed agenda, that this is the first time this community is being presented with what's going on. Am I wrong about that?
John Curran: We meet in April where we talked about it very briefly. And we meet in October. Twice a year. So that's correct. It is what it is.
Dani Roisman: Dani Roisman, SoftLayer. Regarding the needs-based stuff, I'm definitely going to work on - I'm going to figure out how to get access to this breakout room. If you're interested in discussing this, I'm going to sit here after the meeting is adjourned for 15 minutes. Come by, give me your contact info so I can send out information as to when and how we're going to meet. Just one quick thing about needs-based. We had a lot of conversation, spoken about this workload on the staff. We've spoken about the burden on new entrants to this space, small ISPs, et cetera. I don't believe we've sufficiently discussed the issue of people actually using IPs but not going to ARIN to have the records updated. That is definitely, definitely happening. Make no doubt about it. RIPE makes it very easy to update the database so there's actually accurate information. The ARIN transfer policies make it difficult to always make sure the database is updated. If a company has need, they will use it regardless whether or not ARIN is willing to update a database record. And I think we need to shift the focus back on allowing the American Registry of Internet Numbers to act as a registry and no longer as a policer when it comes to transfers.
John Curran: Needs-based for transfers, you are talking about.
Dani Roisman: Needs-based transfers.
John Curran: John, you'll work with him to get AC members and him in the breakout room.
Dani Roisman: Appreciate it.
Kevin Blumberg: Kevin Blumberg, The Wire. Two things. The first was the compressed schedule has actually created another issue which is we're missing a lot of the reports which give out the really good information like the statistics of how many small ISPs there are. I don't know a solution. And for me personally, one and a half days of not enough, I'd rather have two and a half days where I'm twiddling my thumbs at the end than one and a half days where my brain is about to explode.
In regards to the software development update. One of the priorities that seems to be missing is any kind of compatibility with the other RIRs, whether it be APIs, feature sets. I just didn't see that on the criteria of the software development update in terms of its prioritization. And I would urge the developers within ARIN to work on compatibility across the RIRs.
John Curran: The engineering teams get together, that's one of the NRO coordination groups, get together very frequently and have monthly calls. So this is not an infrequent thing regarding trying to stay coordinated. But we also have established systems that have different back ends and different database structures. We do work on compatibility, but we're also separate businesses. It is not one business with five front-end RIR systems.
Mike Joseph: Mike Joseph, Google. To Kevin's comment, there are many companies out there that implement common APIs, yet are separate businesses. This is a tractable problem. You can solve it if you choose to. Speaking of tractable problems, during - I think it was Nate's presentation this morning - unfortunately questions weren't taken, but concerning all the development efforts that were underway at ARIN. And some of the things pointed out just seem to be very concerning for me. For example, he's talking about SWIP being easy for small ORGs because they can do it in ARIN Online, but perhaps he hasn't logged into ARIN online recently because that function was removed. You can't SWIP through ARIN Online.
In fact, if you're IPv6, you can't enter a simple SWIP through email either nor through ARIN Online. The only way to do it is through APIs. So that's a regression. Earlier we heard about a regression with the Whois. We're talking about doing two-factor security. But there's no way to do - excuse me, there's no way to do security for API keys. We still don't have https support for Whois RWS. So the fact is there's a laundry list of features that are not overly complex and yet don't seem to be getting any attention in this prioritization process. Many of these security-sensitive.
John Curran: That's actually quite true. But let me address that. As someone spoke to earlier today. Last year we were on a fairly heavy push to get the RPKI effort both hosted and up/down delegated out the door and it gave us a short feature list of all other features other than RPKI. We actually, with Board guidance, adjusted that earlier this year and now we're in catch up mode. And we've implemented, of the requests that we received in terms of suggestions, we've implemented about half of them. But there's still a backlog. Now, we're moving much more aggressively to catch up. And I think we're making great progress in catching up now that we don't have the RPKI ball of fun in front of us for deliverables. But we are in a backlog. That's very much the case. I do think that we made great progress over the last, from last meeting to this meeting. So hopefully you're seeing that. It may not be the features you were waiting for as much as features that others were waiting for. We've been going on the ones that the most users have asked about.
Mike Joseph: I'm still confounded by ARIN's obsession with serializing requests for features. There's a way to parallelize and that is you beef up your development or outsource portions of it. There's no lack of demand for services and features from ARIN. And as many of us are happy to fund those efforts through our dues that we think should be funded. And I don't know that we are - I don't know that shrinking ARIN's development effort or keeping it stable through a large burst of software projects is actually ideal.
John Curran: It's actually a good question. We actually right now have multiple development teams. We have an Agile approach. One is always flipflopping the other. But it's a fixed amount of capacities. Multiple teams. Not serial.
Mike Joseph: Doesn't have to be a fixed amount. You can hire more, outsource, bring in temps.
John Curran: So what we have is based on a certain total budget size for ARIN, and one of the questions that comes up is: Should we add on more resources to take down the queue even faster? We have ample reserves and that's something that I think tomorrow people talking about those reserves, our fee structure and our rate of investment it would be a great discussion. It really is - that dial is in the hand of the Board. And if we want to invest more, either by taking down the reserves or by whatever approach, either permanently or short term, I'm all for it. But we want to make sure we don't overspend. So it's really you guys talking to the Board about what you need. Okay?
Mike Joseph: I'm sure you won't hear any lack of me talking about what I need. Thanks, John.
Public Policy Meeting - Closing and Announcements
John Curran: Thank you very much. We now have a social right around the corner and we've got about 12 minutes to get to it, to get the first bus. So I'm going to move most expeditiously. Vote now. Elections are open. www.arin.net/public/election. If you're a designated member rep -
Kevin Blumberg: First bus is at 6:30. We've got time.
John Curran: Multiple buses, first one is 6:30. Look at that. Do we want to open the mics back up? Never mind.
John Curran: Vote now if you're in the ARIN elections, if you're the designated member rep. Thank you to our sponsors: Comcast, Google, ServerHub. Okay. Tonight's social, Baltimore Industry, Baltimore Museum of Industry. There's buses starting at 6:30. Open bar, buffet dinner, full access to the museum. And buses come back starting at 8:00. Don't forget the meeting survey. If you have our event app, you can find it there, or you can also find it online either way. Tomorrow we start breakfast at 8:00, the meeting at 9:00. Our member meeting is open to everyone. You don't have to be an ARIN member. Okay. We'll have reports from all the departments and it's open to everyone. Thank you. Enjoy your evening.