ARIN 36 Public Policy Meeting, Day 1 Transcript - Thursday, 8 October 2015

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

Table of Contents

Opening Announcements

John Curran:  Good morning, everyone. Please come in and be seated, and we'll get started.

I'm John Curran. I'm the President and CEO of ARIN. I'd like to welcome everyone to ARIN 36 in Montréal. I know some of you have been enjoying the city for a few days. Some of you are just joining us now.

We should have a couple of good days of discussions about ARIN, its services, policies. Hopefully you'll all enjoy it, and looking forward to some productive meeting.

I'd like to say that the Board of Trustees is here today, and we have the Chair and Vice Chair, Vint Cerf, Paul Andersen, up here. I'm the President and CEO, obviously. Other Board members, Tim Denton, Aaron Hughes. Bill Sandiford and Bill Woodcock are all in the audience.

We also have our Advisory Council here – Dan Alexander, our Chair; and Kevin Blumberg, our Vice Chair. And, well, you know them all. Advisory Council members stand so people can see you. AC members also have a nice, little ribbon on their badge so you can figure them out.

The AC is the group that's responsible for primarily leading the Policy Development Process. So these are the people who work on policy proposals, help you with them, get them submitted, discuss them. They'll be leading the discussions that we have today. And so if you have a question about a policy or want something being discussed, find an AC member. They're easy to find.

We also have our Number Council here. Louie Lee, Jason Schiller, and John Sweeting. I don't see – Louie, are you hiding here? We may not have Louie. We may just have his hat. Jason Schiller. And I know John Sweeting – I saw him in the hall. They actually have a call right now regarding the CRISP Team. I'll talk about that in a little while, but they're also in the audience.

We have a number of folks from the other RIRs – Allen somewhere? I know you're here somewhere. The RIPE NCC – Andrew, Axel, Nicholas, Salam, and Janos, the whole gang from RIPE. From LACNIC, Gianina, yes? Sorry, miss. And from APNIC, Geoff Huston and Nurul Islam. Yes, very nice.

ARIN management team. Myself and Nate, who's the Chief Operating Officer. Basically I get all the credit; he does all the work. It's a great division of labor.

Cathy Handley is not here. She's off – right now there are meetings regarding the WSIS. The World Summit on Information Society is having its update meeting. It's the + Meeting. Cathy is off there.

Richard Jimmerson, our CIO and interim RSD Director, is here. And Erin Allgood, our HR and Admin, in the back. Susan Hamlin, who makes this meeting happen. Mark Kosters, who leads up engineering. And Leslie Nobile, Senior Director of Global Registry Knowledge. She helps work on integrity and accuracy issues. And Val Winkelman, our finance, is here somewhere hiding.

So Fellowship Program. We have a Fellowship Program. Our Fellowship Program allows people who are interested in ARIN but may not have the resources to attend to come in and attend these meetings. We've expanded the Fellowship Program.

So we actually have a number of people coming from each of those various ARIN sectors. From Canada, we have Glenn McKnight. Glenn, are you here? Our Fellow. Thank you.

From Canada as well, Gary Molenkamp. Gary? Our Fellows are here. Very nice. They each have mentors, Rob Seastrom and David Farmer. And from the U.S., we have Marvin Arnold. Marvin, are you here? Thank you. Mike Hammett here as well. Yes? Mike? Very good. And Leah Symekher. And all of them have mentors as well assigned, people who have been here for some time – Brandon Ross, John Springer, and Cathy Aronson.

From the Caribbean we've really expanded the program, helped get more people aware of what we do. So we have José de la Cruz. Yes? Hello, José. Good to see you. And Jason Hynds. Roosevelt Lewars. Roosevelt? Yes. And Daryl Wade. Very good.

And, again, mentors for them – Leif Sawyer, Leslie, Tina, and Charlie Liu.

The Fellowship Program helps us develop people aware of how ARIN works and our policies so they can help keep the community fresh, help bring in new insights, also help take the information they learn here and bring it back to their communities. Very happy with that and happy we have expanded the program.

Okay, Postel Network Operations Scholars. We have two of them. This is a joint program with NANOG that we do. Omar Eissa, are you here? And Razan Abdalla. Razan? Yes, very nice.

I'd like to welcome all the first timers. We do have a number of first timers. They got to meet the ARIN representatives and staff this morning, learned about ARIN.

They filled out the surveys on what they thought about the First Timer Breakfast. I have their survey responses here. And I won't read them all because that would take a while. But we'll draw one of them, and we'll issue a gift certificate for people who took the time to fill out their surveys. I will ask Owen DeLong.

You may have to go up the steps for me to hand you this.

Yes, it's a tradition. I always know where to find you in the audience.

The winner is Daryl Wade. Daryl. We will send – you'll get an electronic gift certificate. We'll send that to you very shortly.

Vint Cerf:  The check is in the mail.

John Curran:  The check is in the mail, exactly.

I'd like to welcome our remote participants. You can participate in ARIN without coming to lovely Montréal. Frankly, I'd come here and other destinations but sometimes it doesn't work schedule-wise. Remote participants are full participants. They have the webcast and the transcript. They can download all the meeting materials, including the Discussion Guide. Most important.

There's a chat room where they can be on the record with a virtual microphone and have their questions read. And they participate in the show of support, the polls that we do regarding policies and the support in the community.

Okay. Wireless. You probably already know this, if you've been here awhile, but if not, we have two wireless SSIDs. One of them is open, nanog-arin legacy. And the other one is nanog-arin, secured with username nanog, password nanog.

Okay, attendance stats. We have 59 attendees from Canada, we have 118 from the U.S., six from the Caribbean, 25 from outside the ARIN region, and 29 remote participants.

Okay. If you share information on social media with the tags ARIN36 or get6 on a tweet, you have a chance to get a gift certificate. Help get information of what we are and what we're doing out there.

I'd like to thank our sponsors, Telus and Service Affaires.

(Applause.)

John Curran:  I'd like to thank our webcast sponsor, which I was going to say Alphabet but it says Google. So we'll go with Google. Google. Go Google.

(Applause.)

John Curran:  And then our break sponsors. We have CIK TELECOM, Belair, ColbaNet, and ServerHub for the breaks. Thanks.

(Applause.)

John Curran:  Okay, you have a ticket. If you turn in your ticket – it was in your package – during the afternoon break, you can get your ARIN 36 tee shirt with a nice Montréal logo and very nice.

We're going to have some discussions, some reminders. So particularly when we're going through the draft policies, we want everyone to have a chance to speak. So that means that please respect other people. If you've been up at the microphone, let other people who haven't spoke get to the microphone. Please state your name and affiliation each time you're recognized at the mic. There's a list of programs and courtesies in the program.

So please, please be polite to one another.

Today's agenda. We have a lot of things on today's agenda. It's a busy day. So we're going to have an IAB/IETF Activities Report. We're going to have a policy Implementation and Experience Report. The AC On-docket Proposals Report. I'll give an update on IPv4 exhaustion, IANA Stewardship Transition, and Fees and Services.

We'll have a report on the ARIN Board and AC Election Procedures, followed by the NRO, Board, and AC candidate speeches. And we'll have a software development update. And we're going to squeeze this all in by 5:00 p.m.

Okay. Regarding policies. Today we're going to talk about a number of policies. Two of them are Reommended Draft Policies. Recommended Draft Policies have the potential of being adopted and included in the Network Policy Manual after this meeting.

So the recommended ones, this is your last chance to comment on them. We then have some Draft Policies, and – one in the morning and four of them in the afternoon. So it's going to be a very busy day.

Tonight we're going to Cirque Eloize. I was told people went there earlier this week on another social. And buses will depart at 6:45, 7:00, and 7:15. And then the return shuttles start at 8:30 and run back til 11:00 p.m. Bring your name badge, please. We like to know who you are.

You also have a little ticket about the social. It's in the – your name badge is in your badge here. So bring the sticky one.

Okay. At the head table I think I've introduced everyone already. Oh, except Andrew Dul. Andrew Dul is our jabber monitor. That way the remote participants, when they ask a question, they'll be recognized. We keep the jabber monitor up here with us.

I'd like to start right in on the first presentation, which will be the IAB/IETF Activities Report. Cathy Aronson.

(Applause.)

John Curran:  People may not know this, but we ship Cathy off to the IETF to sort of be the canary in the coal mine, keep track of what's going on there, report on interesting developments. It's one of the more interesting presentations we get.

IETF IPv6 Activities Report

Cathy Aronson:  And it's really great. It's all right with the world because Vint is sitting next to me. Last time he wasn't. So I didn't get to hear his little commentary. And now I get to. And it's very exciting for me. It's a highlight.

So just to brag for a moment, first, I finally got my jersey. I got to see the Northern Lights right in my neighborhood, and that's a photo I took. So I didn't know what it was at first. I thought there was a town there, but there is no town there.

And then I finally figured it out. It took me a while. And I wanted to thank Aaron Hughes, because he was my – made IETF ever so slightly less boring, as he sat next to me and thought, wow, I'm glad I don't have to do this every time.

So this is a little bit, my disclaimer. I go to what I want and I'm not official anything.

So I have some highlights. I don't know if you can read the IETF Wi-Fi thingy we got, but it was really pretty funny. Something about how the network is – it's been compromised and we're all going to die, basically. It was great.

I have a really limited amount of time to do this so the slides I'm actually going to talk about have an asterisk, because I had to pick and choose, because I have 13 minutes.

This was a survey that we did at the IETF. Thanks to Aaron Hughes. It's a highlight. I think it's going to be a continuing segment. The footwear of the IETF. Love it. Really, really strange.

Okay. So something really exciting happened. They showed Citizenfour and then they actually piped Snowden into the IETF, and he talked about what we should be doing with protocols, and it's all up on the web if you want to watch it.

It was pretty awesome. The IETF should be working on making things more secure and more anonymous, and there's a bunch of human rights stuff I'll talk about later.

So we had a little meeting before the meeting to talk about best current operating practices documents. And if you're interested, talk to Aaron or I about that. We're trying to make a more global process and more global documents that everybody can use and figuring out a place to house them.

So IEPG is the bunch of operators. They get together at IETFs. And most of the people at IETF don't know that. It happens the Sunday before from 10:00 to noon, and usually there's really a lot of interesting presentations at the IEPG, the Internet Engineering Planning Group.

This time we talked more about DNSSEC. There's a lot about DNSSEC and the different algorithms and who is recognizing what and what gets dropped and that sort of thing. So if you're interested, there's a link. I'm not going to go into a lot of detail because I have 13 minutes.

There's some more other things the RIPE NCC has been doing that they're talking about with the Atlas probes and geolocation. Not really going to talk about this, but there was also a presentation at NANOG about this F-Root stuff which is pretty cool. There's links to all these things in the slides. I'm not going to talk about that. But it's there.

6man is a v6 group that maintains the v6 protocols. Let's see, what did we talk about? Oh, so I mentioned in my early slide that there's a new – I don't know if it's new to you guys, but it was certainly new to me. Aaron Hughes was like this is old news, but for me it was new news because I live in Wyoming.

But, apparently, because the router advertisements in v6 are multicast, when you're at a meeting like this, if there's v6 on the network, your cell phone battery dies really fast because it has to respond to every single one of these things that comes on to the network and leaves the network and comes on to the network and leaves the network. So it just sucks your cell phone battery.

So if you wonder why you don't have any cell phone battery when you come to a conference, guess what...

So there's a draft to try to change some of the messages to be unicast so that everyone doesn't have to respond to them. So if you didn't know that, like me, now you know.

Let's see. I'm not going to talk about that. It doesn't have an asterisk. I have a lot of 6man slides. So Sunset4 and v6ops met together because they're trying to figure out what to do with Sunset4. Sunset 4 is sort of trying to just maintain v4 so that it interacts with v6 but not really add anything new to v4. And v6 ops are the operations people doing v6 or the nonoperations people trying to write operations documents for v6.

So these are, what, little bits from the charter that I've started doing. So we had a joint meeting and we talked about some different ways to hook the groups together, and these are some of the documents that are being worked on.

Okay. So this is my slide before the slide. I've never done this before, but I have to have a slide before the slide. I'm pretty excited about this.

So in the world as we know it, like, if some big company really made a big change, they could probably change like our food supply or various good things could happen, if big companies kind of took a stand.

So at V6 Ops, a really nice guy from Apple talked, and I was pretty excited about it. Because they've actually made all the apps in the App Store have to be v6.

And they've put in a NAT64 gateway so you can test and basically you can't have an app in the App Store that isn't v6. It's pretty awesome.

(Applause.)

Cathy Aronson:  And if more companies did that, we would actually have more v6. So, anyway, I just think it's pretty exciting and I think they should get some kudos for that, because you can't turn off v6 on an app in the Apple App Store. You can't do it. It's awesome.

Anyway, moving right along. But his presentation is online if you want to check it out. But it's pretty awesome. They even put in testing so that if you're writing an app you can test it. So it's cool.

Let's see. So this is a document that our own Vint Cerf worked on. Let's hear it for him. And it's actually a really interesting read. It's just a new way of thinking about address space and addressing for different functionality as opposed to just like one address for a device.

But maybe in the New World Order you need to have multiple addresses for multiple functionality or privacy or all kinds of different things. And since we have more address space, maybe we should use it that way. So it's a pretty good – do you want to say anything?

Vint Cerf:  Just one observation. It turns out that the kinds of devices that we carry around these days and the ones that we use in the cloud typically have multiple processors. It's not unreasonable to imagine having multiple addresses to allocate to different virtual machines and things like that, in addition to which you may need separate v6 addresses in order to deal with the v4 NATing in addition to the ability to do v6-4, in addition to being able to do native v6.

So the general conclusion is if we're going to do assignments, either we should allow the users to generate v6 addresses at need, like with SLAC, or, alternatively, instead of allocating a DHCP single address, allocate a prefix and allow for the dynamic assignment of additional addresses that need. So that's the summary of what we're trying to propose. Thank you.

Cathy Aronson:  Thanks, Vint. I didn't know he had written it. So it was pretty fun to read it. Anyway. Doesn't have an asterisk.

Let's see. Oh, I always like to highlight these. This is an actual operator talking at the IETF. We love that. It's the largest ISP in Greece. And his presentation was pretty interesting, if you want to check it out. I'm sure – I don't know if I have a link to it. But 90 percent of their CPE are v6 capable in Greece, and that's pretty exciting.

Let's see. I don't have an asterisk. This is just because I can and I'm up here and they said I can do whatever I want. So it's a slide of pictures I took. The elk is from my yard just to brag a little.

Anyway, next, Homenet. So Homenet, I had to have that slide first because next is Homenet.

So they're still arguing about what routing protocol to use. And there's a big discussion about – I don't know if you say "bable" or babble. I kind of prefer babble because – but there's a new routing protocol. And they're talking about using it, but it's not an IETF standard. So can an IETF standard refer to an IETF standard that isn't an IETF standard.

Anyway, so they're still debating. And I think eventually we're all just going to have Homenets and maybe we don't really need a routing protocol. I don't know. Anyway, they're still arguing about it. It's awesome.

And you can – anyway, that's what Homenet is. This is what they're arguing about. Sorry, I'm ahead of myself.

So they're still talking about what routing protocol to use or not use, and it was a long discussion. And here's some other drafts that are at Homenet, if you're interested.

And some more new drafts. There's a lot of drafts. So here's ANIMA. It's self-configuring, self-managing, self-maintaining whatever networks. I'm dubious.

And this is more about the charter. Thank you, Einar, for taking my slides at the last minute and reordering them. So there's a lot going on in ANIMA and us, those of us who manage networks. Don't worry, there will be a little hook so you can still configure it, I'm sure. That was sarcasm.

(Laughter.)

Cathy Aronson:  I was really fascinated by this auto-bootstrapping thing. So you have like an operations network in parallel to your automatically configuring network, and somehow your operations sort of out of band network self-configures itself and then it allows you to somehow manage your automatically configured network.

Vint Cerf:  And then a miracle happens.

(Laughter.)

Cathy Aronson:  Then a miracle happens. I don't know. I listen and I take notes. I think I have – do I have – yeah, this is what I was thinking at the time. They were talking about dumping out of band in favor of using a production infrastructure. Anyway, that's what I thought at the time.

And someone who was sitting near me, I abbreviated the quote, but let's go reinvent something from 30 years ago. I don't know. Maybe it's the future and I don't understand it because I used to run a network. I'm not really sure, but we'll see. It could be everything configures itself and fabulously works and they don't need us anymore. It could happen, right?

Automatic Prefix Management, we won't talk about that. But there's a lot of other automatic – autonomic things that are going on in ANIMA.

The human rights stuff is pretty interesting. I don't have a lot of time to talk about it, but there's a whole movement to make sure that the Internet – that you have right of assembly and right of communication and all that sort of stuff on the Internet.

It's pretty interesting work going on there. And they're going to be putting out a video. Maybe if my talk is more than 13 minutes next time we could play the video, because they were interviewing people all through our industry about human rights on the Internet. I think it's going to be really good.

So hopefully if you ask for more time in your surveys maybe I could play it. And there's no clock so I guess I can just keep talking.

So, anyway, this is some more of the human rights stuff if you're interested. It's really fun to check out.

I love this. Do you know they use rats to detect mines now? That's awesome. It's like a rat – I don't know, I stole it from Nalini's slide. I thought it was awesome. She did have a picture of the little rat that I didn't steal.

But it's like they use them to detect mines, like land mines. It's pretty cool. It's random. Sorry.

The IRTF awarded networking prizes, and these are some of the talks, if you're interested. I'm missing the commentary at the table.

Okay. And this is another sort of ANIMA-e Simplified Policy Abstraction stuff I'm starting to follow. I'm not sure about it yet.

And then, oh, exciting news from the IETF. Heather Flannigan has been working to make it so that there's no more ASCII art in RFCs. For those of you who don't know, until right now you had to make network diagrams using ASCII characters, awesome. And I don't know, she's been RFC editor now for a handful of years and she's been working on it since day one, you could tell. She's awesome.

And might be that you could have something besides ASCII art soon. She just launched a new web page. You should check it out RFC editor web page. Super cool.

And I went to the Security Open Area Meeting. And there's some really interesting work being done by some folks in this community – Randy Bush and some other folks – on securing the network and encrypting things. If you want to check that out, pretty interesting stuff.

I think there was a good quote from that, although it's hard for me to – it's hard for me to read my slides at this distance. I guess I've got to wear my glasses.

Is it there? There it is. I try really hard to get the quotes randomly and out of context every chance I can. And 6 Lo does v6 over low power, high latency, different devices and factories and in the ocean and Vint's intergalactic Internet.

So there's a lot of work being done in 6 Lo. And my favorite quote of the IETF, I don't think we really want to design the bits and bytes here, like if we're not going to do it at the IETF, where is it going to happen? I got no idea.

But they said that in 6 Lo. I think what happens is the agenda gets so full that they insist that we take everything to the Mailing List.

So we're in a meeting to talk about designing protocols, but there's no time to do that. So awesome. Some more work going on in 6 Lo. These don't have asterisks so I'll – but if you want to check it out, there's a lot of work going on.

The ISOC Briefing Panel. They talked about these challenges. It's pretty interesting. It's all on the web if you want to check it out.

And then I went to DNS Ops. There's a lot going on in DNS Ops. There's some more drafts. Like I said, I didn't put an asterisk by them. DBOUND is another DNS group I went to. This is what they do.

So, anyway, and then the global routing group, GROW, is doing interesting work with DDOS and blackholing routes so your DDOS attacks aren't as hard on your network. So that's some pretty interesting work happening. They have like these U-turn prefixes they're mixing and making DDOS as close to the spammer as possible. So that's some pretty interesting work. And these guys are one of the operationaly kind of groups at the IETF, the routing guys.

I love this. So they're working on like the automatic cars that drive themselves or even having your car be smarter. So maybe you're three cars back from somebody who jams on your brake and your car will know that that guy jammed on his brakes. It's pretty cool stuff. So I'm kind of excited about it because maybe I won't hit anybody.

And so this is another human rights kind of thing, global access to the Internet for all. And they're starting to – this is a research group in the IRTF, Internet Engineering Research Task Force. Interesting to be checking out especially as the work goes on.

Let's see, Delay-tolerant. So this is more of the Internet galactic stuff, like how do you deal with devices where there's big delays in our network and make it work.

Underwater Case Studies. They talked about it in that group. So I added a new little slide here. If you're ever going to go to the IETF, these are the things you could do to be ready. And if not, that's fine. If you don't want to go, then just listen to my report. It's way more fun, or not.

Let's see, we made an IETF drinking game, because Aaron and I sat next to each other a lot and people say the same things over and over and the Mailing List talks about pickpockets and social tickets for sale. So luckily we didn't actually drink every time, or we probably wouldn't have made it here.

And these are my where-to-find-information links. And this is my favorite thing ever, you guys, and I think that we should have it everywhere. It's Why Am I Talking, and then there's the whole flow chart. Is it a new idea? No. Then why am I talking? Has somebody brought this up before? Yes. Then why am I talking? Anyway, it's hilarious. I took a picture of it from my seat and I couldn't help myself.

Vint Cerf:  How come it only says please be concise and there's nothing in there that says shut up?

(Laughter.)

Cathy Aronson:  I think because why am I talking is a polite way of saying shut up.

(Laughter.)

Cathy Aronson:  Anyway, that's I think – that's all I have. So I know it was kind of fast, but I guess it's gone, it should be up permanently, that slide.

(Laughter.)

(Applause.)

Cathy Aronson:  Anybody have any questions? Or, Aaron, do you have anything you want to add? It's a lot.

Vint Cerf:  Aaron said I'll drink to that.

Cathy Aronson:  I know, right? I haven't read the draft, but I want to say this. Oh, I have to drink to that. Anyway...

John Curran:  Thank you, Cathy.

(Applause.)

John Curran:  We shall stay on time, and that means we go directly from Cathy to Dan Alexander who will give the Advisory Council On-Docket Proposal Report. Richard Jimmerson will do his presentation a little later.

Advisory Council On-docket Proposals Report

Dan Alexander:  Good morning. Let's see. Aha. So as John mentioned earlier, there's two proposals that are in a recommended state. And the key point of that to remember is that these have evolved and are developed to a point where the AC feels that they're actually ready to go to the Board if the consensus in the room agrees with that move.

The rest of the proposals that we'll be talking about today are actually in their draft state. So these proposals are not ready to go to the Board and we've not moved them into that recommended state. So the main reason we're here talking about them today is to get both opinions and feedback on how they should evolve or whether the Advisory Council should continue working on them or if people just feel that this is not the way they would like to go and the AC should abandon the efforts.

It was also mentioned during lunch, when you're all eating, there will be four tables around the room. And there's a little sign on each of the tables. And what we do is we raise these topics so people can gather during lunch and either hear people's feedback on the topic or provide their own.

And there will also be AC members sitting at these topics – or at these tables, so we can hear your input regarding these particular topics, because one table will be discussing the two drafts or the two proposals that are in a recommended state. There's also two proposals on the docket that are discussing out-of-region use, because there's been a running topic going on right now about ARIN resource holders who are using ARIN resources outside of the region and how those should be considered in evaluating requests or transfers.

There's also a table topic about life after v4, since the free pool in the ARIN region is now depleted. We're looking for input on what people think how the policies should evolve now that ARIN has no pool to distribute and we're typically managing v6 requests and/or transfers.

And, finally, there's the topic about micro assignments from Section 4.10. Section 4.10 is a policy in the Policy Manual about getting small allocations for v6 transition, where those small blocks can be provided by ARIN for 6 to 4 NAT deployments. So providers for several years to come would potentially have access to a small amount of v4 space to continue growing their networks.

A /10 of this address space was actually reserved for this purpose. But there's – a question has been raised, and the conversation has been going on for some time, if these micro allocations are given, are they actually routable on the global Internet, because they're smaller than what most people will accept as routes.

So there was actually a proposal submitted about a year ago on whether the smallest assignment from this reserve pool should be a /24. But we actually abandoned that proposal in the past mainly because the free pool was still available and this pool was not actually being used. But now that there's starting to be several allocations made from this pool, it might be worth bringing this topic up again.

Finally, there's also a – a policy breakout room is available. So if people want to talk about a particular idea, a particular proposal, feel free to reach out to any of the AC members, and if you want to – there's a room available to sit down, have a conversation or, of course, you know, grab us in the hall at a break, sit down during lunch, over a beer at a social, anytime. We're basically here to hear what you have to say.

We're also trying something new for the first time during this meeting. And typically during a lot of the policy discussions we'll do a show of hands to get a sense of the room as far as what your opinions are.

At the end of today and at the end of tomorrow's meeting, you're also going to get an email. So all the registered attendees, whether in person or remote, will get an email after all of our discussions today that list all the proposals that were discussed during that day's session. And it's just a simple opinion poll whether you're for or against or impartial.

And we're experimenting with this as an additional way for the AC to get feedback on what the sense of the community is.

And that's it.

John Curran:  Any questions for Dan?

(No response.)

John Curran:  Okay. Thank you, Dan.

(Applause.)

Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments Recommended 

John Curran:  Wonderful. So we're now going to enter into the policy block where we talk about the policies that are up for consideration.

The first two are recommended draft policies. I'll actually do the staff introduction for the two recommended draft policies, and then we'll have the AC shepherd come up and speak to them.

And so I will now begin with the first one, which is Recommended Draft Policy 2015-1:  Modification to Criteria for IPv6 Initial End-User Assignments.

So 2015-1 originated in a proposal, Proposal 215, from February of this year. The shepherds are Scott Leibrand and David Huberman. It was presented at ARIN 35 and the Public Policy Consultation at NANOG 64. It was advanced to recommended state in June of this year. It was revised in August.

It is online and in your Discussion Guide. You all have this beautiful Discussion Guide that has everything we're talking about.

Online people, if you're a remote participant, you can download the Discussion Guide. The proposal would add criteria to 6581, the initial criteria for IPv6. There's already a list of independent criteria. This would add a new criteria which allows any end-user organization large enough to have 13 distinct sites to immediately qualify for an IPv6 address space directly from ARIN.

Again, users have to qualify. End-users coming to ARIN for an IPv6 address block have to meet existing criteria. This would add one more criteria thus making it easier to obtain address space.

Policy can be implemented as written. It poses no legal concern. The policy would have minimal resource impact from implementation. We would fairly promptly update our guides for the registration staff and the online materials.

So that's it. I'd now like to turn it over to Scott Leibrand who will give the AC presentation. Come on up, Scott.

Scott Leibrand:  Thank you. Sweet. I can run faster than the slides. Probably talk faster than them, too, unless I try not to.

So this is, as was already mentioned, Recommended Draft Policy 2015-1. The policy statement here is pretty simple. There is a class of end-users for whom renumbering would be quite expensive, compared to the cost to the community of letting them get IPv6 addresses.

Those end-users, if they don't get IPv6 addresses, are likely to do things that are less than ideal – ULA NAT66 or delaying their IPv6 adoption. Those end-users look something like this.

They have lots of locations all over the place, staff in each location, devices, subnets, but they're not multi-homed. These are often organizations that have something like an IPVN, where they have a single provider, and it doesn't make a lot of sense with that many distributed locations to try to multi-home. But it does make sense for them to have a single IPv6 allocation that they can route to their upstream, and they have a contiguous network that will allow them to do that as a single router announcement and use that everywhere.

But given the way IPv4 works, they're generally using RFC 1918 space and NAT. So we're attempting to get these organizations to do the right thing in v6, which is different from what they're doing in v4.

So we could require them to multi-home. But that doesn't really benefit anyone.

We could require them to get an IPv4 direct assignment in order to qualify – so they could qualify for v4 assignment because they've got lots of locations and stuff, but that requires them going to the transfer market.

It requires using up scarce IPv4 resources they don't really need just to qualify for v6. If we made the policy say if you qualify for v4 you can qualify for v6 that would not be a problem.

But we said if you have v4 you can qualify for v6. They don't.

So there's a lot of text in 6.5.8.1 but all we're doing is adding red text. If you have a minimum of 13 active sites within next 12 months on a contiguous network, that is sufficient to get an IPv6 direct assignment as an end-user.

So the rationale here I alluded to earlier, it's in regards to the benefits to these organizations versus the cost to the rest of us. These organizations are the ones for whom getting a direct assignment from their upstream and then having to renumber everything, if they change upstreams, would be very cost prohibitive but the cost of carrying their one extra route in the DFZ spread out but not actually that large.

So in order to strike that balance, we didn't want every organization to be able to qualify for this. So the threshold was set at 13 sites which is how many you have to have to get a /40 initial assignment under the existing v6 policy.

It also requires contiguous network so that you're not going to be the kind of organization that gets a /40 and announces it as 16 /48s.

So the question for everyone here in the room:  We've had this presented at previous meetings and we discussed it on the Mailing List. It didn't have much in the way of opposition.

There were a few editorial comments and such. So the question to you is:  Do you support it as written? If not, are there any changes that you would like to see in order to allow you to support it?

And are any of those changes substantive and in the scope of this proposal. I've heard several suggestions for we should also do X, where also doing X is probably best done as an additional Policy Proposal after this one.

I've seen other suggestions for changing the editorial nature, not changing the text but changing the way it's bulleted or changing the way it's organized, things like that.

If anyone feels strongly about those, you can bring them up. But they shouldn't prevent us from moving this forward because those can be done as editorial changes after this meeting.

And if you have any other questions, concerns or suggestions, I'd love to hear them.

John Curran:  Anything else? No? So Vint or Paul, one of you can moderate the discussion.

Vint Cerf:  Happy to do that. Are there any comments on this particular proposal? Any suggestions or changes that are urged? Owen.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. I support it as written. I would support it more if the threshold were reduced to four or even eight.

Vint Cerf:  But you would still support it in its current form?

Owen DeLong:  Yes.

Vint Cerf:  Thank you. Anyone else? Don't forget to identify yourself, please.

Gary Giesen:  Gary Giesen, AKN. I'm also the original proposal author. I support it as written obviously. I would suggest that anyone who would like the threshold to be lowered submit a revised proposal after this one's been passed. And I would support that as well. But I think we need to move this one along. So let's get it through.

Vint Cerf:  Thank you for that. Other comments? Going? Going?

Kevin Blumberg:  Not online. Kevin Blumberg, The Wire. Just two comments. The first is:  I believe at the last meeting there was significant discussion in regards to the bit boundary, and it was left because the consensus at the time was that it was a good start and to leave it at that as it got smaller and smaller, so the concerns grew and grew.

So just a little bit of historical on that one. As far as cleanup and editorial changes, I reread the section and the duplicative nature of having within 12 months at the top and then within 12 months again, and then within 12 months again, is very poor writing. I would – I know there's been a lot of comments in regards to just re-editorial cleaning it up as part of the final.

I would absolutely support that, if it's doable. But otherwise, make it happen.

Vint Cerf:  Thank you. I don't see anyone else at the microphones. Anyone else online?

(No response.)

Vint Cerf:  In this case, I think we're ready to formalize this. So we need to have the vote takers prepared. Are you ready? All right. So if you support this proposal, I would like you to raise your hands and keep them up, keep them high, so that the vote takers can count.

So just leave them up there, even if the blood drains out of your hand, until the vote takers tell us they've gotten all the positive votes.

Scott Leibrand:  If you absolutely must you have a redundant hand.

Vint Cerf:  However, you're not allowed to use them at once. I'm sorry, Paul, don't cause trouble.

(Laughter.)

Vint Cerf:  Keep them up, please. This is part of our exercise policy. Vote counters are still counting. Finding a way to do this online would be really attractive, wouldn't it? Vote counters, are you done? Okay. Thank you. Is anyone opposed to this, you can put your hand down now – is there anyone opposed to adopting this policy?

John, is there any reason to ask for abstentions? I don't think so. Okay. I'm so accustomed to that as Board Chair.

So I see no one putting their hand up against this policy. So vote counters, would you please come and report your results.

By the way, while we're waiting for this, I notice not everybody has the Discussion Guide in front of you. If you want it, it's available outside at the registration desk. So you might want to go pick one up at the break. Thank you very much.

There are 154 people in the room – I'm sorry, 152 people in the room. Two are remote. And the vote is 47 in favor and 0 against.

So thank you very much for that. John, you may have the floor.

Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations

John Curran:  We'll move right ahead. That information will go to the AC for their consideration. We'll now pick up the second Recommended Draft Policy, which is ARIN 2015-4:  Modify 8.2 Section to Better Reflect How ARIN Handles Reorganizations.

So this originated in Policy Proposal 218, which was in April of this year. The shepherds are Owen DeLong and Andrew Dul. It was presented at the ARIN Public Policy Consultation at NANOG 64. It was advanced to Recommended Draft Policy in July. It is online and in the Discussion Guide. This is my copy, but if you want some there are some out at the registration desk. We'll get some more in here.

It's also online. Obviously you can download the Discussion Guide. This proposal will clarify 8.2 transfer policy for reorganizations. It does by adding the word "reorganizations" to the title and clarifies that evidence of acquired assets is only required for merger and acquisition and not reorganizations.

The proposal clarifies a point about reorganizations that has been confusing to some customers. It can be implemented as written. There's no material legal issues. Minimal impact. It's the routine just making sure we update the documentation and staff training. This is very much existing practice. So very easy to implement.

I'll now turn this over to Owen DeLong who will do the AC presentation.

Owen DeLong:  Good morning. So we got this from staff originally through the Policy Experience Report that 8.2 didn't really cover how we handle trend reorgs.

The first policy bullet doesn't really apply. So we made some small changes to the policy to clarify that. This is the sort of red line end result.

And so now we're basically asking the community:  Do you support updating this section or not. If not, what changes do you feel need to be made?

So I'll leave this up because I think it's the most relevant thing for discussion and with that we can move on to discussion. This came very close to being put through as a editorial change without the need for community input, but some people felt that it was significant enough. So we did decide to play it safe and go to the community for input.

Vint Cerf:  I'll entertain discussion, but I have a question for Owen.

Is it the case that one would expect a company who had already gotten an allocation to come to ARIN saying we have reorganized and we need to do something, as opposed to ARIN saying:  You've reorganized and therefore you have to do something? John wants to respond.

John Curran:  Very much the former. Companies reorganize and sometimes have multiple ORG ID. So the reorganization affects where their address blocks are held among multiple organizational IDs and they want to update that, and we process these but we'd like to make sure we're processing them in a way the community expects.

Vint Cerf:  So Alphabet might come, for example, and say we're now Alphabet Soup as opposed to Google. Are there any questions or issues on this proposal?

Owen DeLong:  This would also cover transfers to the subsidiary Alphabit.

Vint Cerf:  Subsidiary characters as it were, yes. Larry Page says we're all characters now. Okay, is there anybody online who has a comment or anyone here at the head table? I can't even see the darn microphone. Thank you. Go ahead.

Celeste Anderson:  Celeste Anderson, USC, Los Nettos. I have a question about people who have legacy and how to reORG because you're requiring them to sign an RSA. So if someone doesn't want to sign an RSA and basically reORGs then the information in ARIN will be inaccurate. So I'm just wondering how you dealt with this.

John Curran:  So a legacy address holder can update their contact information but can't change the organizational record that it's assigned to.

So if you have new contact people you can change that, and you can get reverse DNS services and just like you received all the services that someone else does but you can't change your organization handle without coming into an agreement. That is correct.

There is some issues that we, for the US government, we have many, many departments that have signed the RSA. But there were a couple of hanging-over issues.

I don't know if people are aware, but yesterday we announced a new RSA/LRSA which addresses some of those. So it's quite possible that whatever was hanging you up is no longer an issue. You might want to take a look at the revised one that came out yesterday.

Celeste Anderson:  I was just asking generally for the community because I know quite a few people with legacy space have not signed an RSA.

John Curran:  If you haven't signed an RSA you can update your contacts but you cannot change your organizational handle. This doesn't change that in any way.

Vint Cerf:  Thank you. Any other questions?

(No response.)

Vint Cerf:  I understand, by the way, that the online system is five to ten seconds delayed. That's the recent information I have. So I'm going to pause a little bit longer than you would expect in case there's people out there waiting to say something.

Yes, we have one more comment. Please.

Sandy Murphy:  Sandy Murphy, PARSONS. I stepped to the mic only because I'm not certain what the last paragraph means. So the company comes and says we want to reorganize and ARIN says, okay, we now need to verify that you meet the ARIN policy and, oops, no, you don't. Okay. So now either return some of that or transfer some of it.

Does the company at that point say, nope, sorry, not interested in doing either of those, forget that we asked; or are they now in the process and they're going to have to go through?

John Curran:  So, recognize the particular proposed change doesn't change that language, and in fact it makes it clear the paragraph you're talking to.

The reorganization says that they – for mergers and acquisition transfers, they must provide evidence. When there's a reorganization all within a single entity – so it's not a transfers to other entities, we are generally not looking at the total combined utilization.

However, for a case where you do have address blocks that are coming in from multiple entities, the last paragraph is presently applicable, will remain applicable, and what it is we do tell people if you have more resources than you can qualify under current policy, then you will need to arrange to do a transfer of the excess address space.

We have had people abandon their update at that point. But in a lot of cases they're well aware and have already – one of the reasons they're coming in and doing this update is because they're planning to transfer the extra address space. That's what's caused them to go back and look at their records and realize they need to do it.

But, no, if they abandon the update, they abandon the update.

Sandy Murphy:  Okay.

Vint Cerf:  Yes, one more. Center microphone, then the one to my right.

David Huberman:  David Huberman from Microsoft. I want to talk about Celeste and Sandy's comments and respond to John.

A while ago we all sat here and ARIN had a roughly 50 percent success rate with transfers submitted, 50 percent were approved and 50 percent were not often abandoned.

John and the staff have done a great job – I believe the number they published this week was 86 percent approval.

So the staff's doing a really good job getting transfers through. But where we have the problem and where we need to continue as a community to do work in Section 8.2, in my opinion, is it's all the transfers that don't even come to the door.

Celeste's experience mirror my own. The Microsoft Corporation I work for bought address space and were unable to transfer it to ARIN not because of ARIN but because the company we transferred it to has to fix some of the records and enter into an RSA on those records, and their lawyers are advising them not to. We'll solve that problem.

But it's a pretty typical outcome of 8.2. At the same time, Sandy brings up the last paragraph of this. The last paragraph is some scary text.

If you don't know ARIN very well and you're just trying to run your network and you send someone to ARIN to go clean some records up, this text would scare me. This text says ARIN's going to take away my space if I'm not using it.

Now, it doesn't really say – it kind of says that. Maybe it doesn't. It can be read that way. Luckily ARIN doesn't act like that. ARIN's a benign organization and the staff work hard for the Internet.

But this paragraph is scary as can be. And this is why a lot of the transfers never hit the door. That's all.

Vint Cerf:  I've got several people. So just hang on for a second. I think there wanted to be a response. I see you. But if you'll hold on for a moment there's a response coming back. Owen had his hand up and so did John.

Owen DeLong:  I defer to John.

Vint Cerf:  John, you had a response.

John Curran:  You're raising an issue that's outside the particular Recommended Draft Policy being discussed. I do want to note – it's sort of my fault – Richard has a policy – Richard Jimmerson has a Policy Experience Report which talks about this very last paragraph, and that will probably kick off discussion about what could or should or shouldn't be done with it.

But we didn't get to see the Policy Experience Report because I thought Cathy's presentation was much more interesting.

We'll see it right after the break.

Vint Cerf:  In that case, the conclusion I would reach is that we can proceed to discuss this particular policy change, and then adopt any other discussion at another time.

Owen DeLong:  That's what I was going to say.

Vint Cerf:  That's good. Now, finally, I'm sorry, thank you for your patience.

Marc Lindsey:  I've been standing up here for a while the conversation may have lapsed a bit, but I'm going to say it anyway. I agree with David's point. My name is Marc Lindsey. I'm with Avenue4. I advise a handful of participants in the process.

A lot of them, they come to me and ask me questions about what this last paragraph means, and it does scares them and they choose not to go through with an 8.2 process because they're fearful of this.

I explain to them how ARIN typically handles this. And they say, yeah, I hear you, but this language still suggests I could be in a revocation situation even though I've been using the address space in a certain fashion and holding them for 10, 15 or 20 years.

So if we're going through a process that really clean things up that really don't change ARIN's policies, this seems to me to be a good opportunity to kind of revisit this last paragraph because it is dampening the 8.2 transfers that companies are intending to make, would like to make but are not because of it.

Vint Cerf:  So thank you for that. It seems to me, though, important that we stay focused on the particular policy proposals that are before us.

So my recommendation would be that we reach some conclusion on this one, since it's recommended policy, and then let's take up this question of the last paragraph as a separate matter.

So let me ask if there are any other comments on the current proposal.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. I would just want to say that – remind folks that we brought this proposal forward, as Owen said, out of an abundance of caution. Mostly editorial. A delete of a paragraph is way more than editorial. And so let's keep them separate.

Vint Cerf:  Yes, I think – we had one more comment. Good. I think we're generally in agreement that we should try to amend more than that which is proposed right now.

Are there any comments from online, jabber?

Andrew Dul:  No.

Vint Cerf:  In that case, vote takers, please prepare. Are you ready? All right. So all of you who are in favor of adopting this policy or recommending to the Board that it be adopted raise your hands and keep them up, please, until the note takers are completed, have completed their task. Thank you.

I know it's tempting to guess that they finished. But until they tell us they've finished, keep your hands up. Why does it feel like I'm doing a hold-up, like put your hands up? That's it. Perfect. We just need – instead of a gavel I need – no, no, we won't go –

Paul Andersen:  You're in Canada.

Vint Cerf:  I'm in Canada. That's a good point. Hands up. Are we done, vote takers? You can put your hands down. Are there any who oppose these changes? I see none. We should have drum roll or music or something.

But in this particular case the answers won't be much of a surprise, will they. There are 152 people still in the room, three remote. 47 are in favor. Zero against. It must be the same people who vote. Is that all? We only have 47 people who ever vote?

John Curran:  There's a large number of Board who often do not vote. ARIN staff –

Vint Cerf:  Is that b-o-r-e-d?

John Curran:  Though they would vote if we did your gavel-gun idea, I think. And then there's – RIR staff from other regions often don't have a view. So between the Board and us and the staff – you see.

Okay, so we're going to move right ahead. We have one more policy to do before the break. Draft Policy 2015-11. I don't need to do an introduction because it is just a Draft Policy. So it will be presented by Milton. For folks who want a copy of it it's in your Discussion Guide.

There are Discussion Guides on the side table. You can actually run over there and get one if you want one. I'll bring Milton up to do the presentation – I'll bring R.S. up to do the presentation.

DRAFT POLICY ARIN-2015-11: REMOVE TRANSFER LANGUAGE WHICH ONLY APPLIED PRE-EXHAUSTION OF IPV4 POOL

Rob Seastrom:  So the problem statement. There's a broad class of policy proposals that seek to clean up language that's now obsolete or a dead end because it says effective until exhaustion. And if there's anyone in the room who is not aware that we're out of IPv4 addresses, let me steal our president's thunder and tell you we're out of IPv4 addresses.

So here's the policy statement for 2015-11 that I'm going to commit the sin of reading it aloud.

Remove the following sections of the NRPM:  Section 8.3, Transfers to Specified Recipients ARIN region, remove entirely the second bullet, which is the source entity will be ineligible to receive any further IPv4 address allocations, et cetera, et cetera, until the exhaustion of ARIN's IPv4 space.

And Section 8.4, which is Inter-RIR Transfers to Specified Recipients, similar language, "or until the exhaustion of ARIN's IPv4 space, whichever occurs first." 

Since this is a Draft Policy, we do not have staff and legal feedback on this yet. But we would like your feedback, you the community. Yeah, it's good to get rid of obsolete language, but is anyone actually confused by this language? Discussion. Microphones.

Vint Cerf:  We're ready to have discussion. Microphone on my left.

Sandy Murphy:  Sandy Murphy, PARSONS. Could you go back to the language slide, please? Okay. So that's a remove entirely something which is an either/or, because the "or" part no longer applies.

But if you remove it entirely, you're removing this business about being ineligible for 12 months after a transfer approval.

Did you intend to remove that?

Rob Seastrom:  That seems to be the intent of the policy. And that was the way I read it.

Sandy Murphy:  Okay. That's stronger than removing the part of the either/or that is no longer applicable. I'd just make that observation.

Vint Cerf:  Good point. Let me get the center front microphone and then the center rear microphone.

Matt Petach:  Matt Petach, Yahoo!  I was in favor of this until she clarified. I don't think we should take both parts of the either/or out. So I would oppose it as it currently reads.

Vint Cerf:  Thank you. Rear microphone, please, in the center.

Geoff Huston:  Geoff Huston, APNIC. Are you aware that ARIN is going to get a small dribble of space in March of 2016 and an even smaller dribble in September, March, and so on? There's a certain amount of this global IPv4 recovered stuff that is going to in tiny amounts come back and be ARIN IPv4 space twice a year.

So when you drafted this, were you aware of that? And I'm making no comment for or against. I'm just really saying:  ARIN will not run out again and then quickly run out a few more times.

It's going to bounce off the bottom.

Rob Seastrom:  I'd like to respond to that, which is that we're certainly aware of that. We're certainly aware that's happened once already, and it has evaporated like a spilled glass of water on a hot day.

Geoff Huston:  Certainly true, but what I'm saying is would this apply to that space and are you raising it, the application of this to those tiny dribbles that vaporize instantly. It's nitpicky, I know, but the issue is there will be more space coming through in that pool.

Rob Seastrom:  I would never criticize you for nitpicking. I would feel like a hypocrite.

(Laughter.)

Vint Cerf:  Microphone over on my far right.

Michael Sinatra:  John, did you have a comment?

Vint Cerf:  I didn't see that, John.

John Curran:  I don't mean to jump the line but to Geoff's point, IPv4 exhaustion has occurred, but for avoidance of doubt, it might want – it might be a good thing to make sure that we understand it's occurred and it's not a recurring event.

And that might require the AC to revisit this. In other words, even if space comes back in and for some reason the wait list was really low and was all satisfied, we would still be in our final exhaustion phase. And the AC should probably make that clear so someone doesn't try to argue with ARIN to the contrary.

Vint Cerf:  Let me get the microphone over on my left.

Michael Sinatra:  Michael Sinatra, ESnet, speaking for myself, which I will be doing the entire time I'm here. I will not be speaking not for ESnet or any part of the US government, so let's just get that out of the way.

(Laughter.)

Michael Sinatra:  If this is something we really want to waste our time with, first of all, look at the wording. It says "until exhaustion."  Exhaustion has happened. That wording is still valid. There's nothing invalid about that. It just means that exhaustion has happened. And you look at the wording, you say, okay, exhaustion is happening, this kicks in.

I don't think we really need to mess with it, but if we do want to mess with it, to Geoff's point, why don't we just simply say "or until the free pool is at a point below the requesting address space" so that we just keep it at that and not and if the free pool fills up again because there's reclaimed address space, that condition can be met whenever it's met.

Doesn't seem like we need to completely delete this or really even mess with this that much, because it's logically still sound.

Vint Cerf:  Thank you for that.

Owen?

Owen DeLong:  Owen DeLong, ARIN AC,  Akamai. I find it interesting we're getting wrapped around the axel on the "or," because it's not an either/or-or, it's two possible events, and the second "or" having occurred renders the first half of the "or" inoperative anyway.

So this policy proposal is a 100 percent no op anyway. I don't support it as written because it's just make work to pass it and the language is already clear and we've got better things to do.

Vint Cerf:  I'm sorry, Owen. Clarification. You say don't support it. You mean don't support changing –

Owen DeLong:  I do not support this policy proposal that we are discussing.

Vint Cerf:  Thank you.

Let me get over on the far right and then microphone in the back.

Dani Roisman:  Dani Roisman with SoftLayer. I'm also the author of this proposal.

So, back to Sandra and Matt's point earlier, and to the one Owen just mentioned, because the "or" has occurred, because exhaustion has occurred, the entire bullet is no longer operative.

What I'm proposing is we don't necessarily need extra clauses in the NRPM which are non-operative for people to actually worry about and read and attempt to interpret.

So I think, as we said, exhaustion has occurred. Therefore, the first half of the bullet is no longer applicable. And that's why I'm proposing it's no longer necessary in the NRPM.

Vint Cerf:  Thank you for that. Let me take the microphone in the center rear.

Sandra Brown:  Sandra Brown, IPv4 Marketing Group. I agree with Dani the current text should be deleted. What I see happening is there are many entities out there that have two or more ORG ID in the ARIN system, and what they'll do is they'll stay on the list to get IPs from ARIN in March or whatever date that Geoff talked about with one Org ID, and they'll do the transfers with another Org ID.

So they defeat the purpose of the text by just having multiple ORGs. So basically the current text is not having an effect for many, many companies, especially the larger ones.

And it has an effect only for the smaller guys. So this is just penalizing the smaller guys. You may as well get rid of it.

Vint Cerf:  Thank you for that comment. I'll take comment – anyone – yes, over here, please.

Kevin Blumberg:  Kevin Blumberg. I have a question for staff to clarify because we're having a lot of discussion on this in regards to exhaustion.

If an ORG goes and gets space from the microallocations pool, which is not exhausted, I'm just wondering if until exhaustion, if we have actually reached technical exhaustion because we have space and that is why it's there.

John Curran:  So this language, when it was written, in bo,th cases, and discussed before the community, indicated a single-time event that applies to the open free pool, not the reserves we have for particular purposes.

So right now staff interprets that exhaustion has occurred. It's a binary that's been set and won't get cleared. I guess what I'm trying to say is when you remove this, if this policy is adopted, and you remove these sections, we have no problem because there's no longer any reference to the phrase:  Until the exhaustion of ARIN's v4 space.

If you don't remove this text, right now it's our belief that exhaustion has occurred and will never unoccur, and if that's not the community's belief and you keep this text in here, you might want to make sure we're following it correctly, because we believe exhaustion has occurred and interpret this clause as therefore being nonoperative.

If the community somehow thinks that on the statistically low event that somehow enough space comes back, that we then no longer are exhausted because the waiting list goes to zero, and you want this operative, then you should let us, A, keep – you should keep the text in, and, B, you should make it very clear to us that that's your meaning.

By default right now we consider exhaustion having happened.

If you keep the text, and you think exhaustion is a state, not an event, please clarify that in some other policy.

Vint Cerf:  Thank you, John. I saw another hand waving there. Was that yours?

Andrew Dul:  Andrew Dul, ARIN AC. I'd like to point out to the community that there's another bullet in the transfer policy that is almost identical and talks about – specifically about transfers. So I'll just read the 8.3 bullet.

It says:  The source entity must not have received a transfer allocation or assignment of IPv4 Number Resources from ARIN for the first 12 months prior to the transfer request. This restriction does not include M&A transfers.

So people who are reading this as, well, just strike the part after the "or," the part before the "or" is mostly in the next bullet in the policy. It's not exactly the same. But it is almost the same, in my personal opinion.

Vint Cerf:  Thank you. Center microphone.

Scott Leibrand:  Scott Leibrand, ARIN AC. I concur with what Dani said, that this is indeed a useful clean-up that only – and we've heard it clarified several times, this only takes away something that is no longer operative.

I would have agreed with Owen this is kind of unnecessary make-work, except the fact that two people got up at the microphone and misunderstood this clause on the floor of the ARIN meeting where we have the most informed people in the ARIN community commenting on policy.

The fact that people read this and don't understand which – where the parentheses go around the various "ors" in this clause and misinterpret it as to perhaps still apply means we need to be very clear for the community and we need to get rid of this because it no longer applies.

That's my opinion, so I support the policy.

Vint Cerf:  Thank you, Scott. Are there any comments coming from jabber? No.

Andrew Dul:  No jabber comments at this time.

Vint Cerf:  I do have a question. This may sound a little crazy, but let's suppose for the sake of argument that v6 some day actually gets deployed and everybody is using it, and v4 address space somehow becomes available, do you want to deal with that problem when it shows up as opposed to trying to deal with it now? John.

John Curran:  So if the community makes clear that exhaustion is a state, not a single event that's occurred, then that state will be entered in – in six to eight years, because there will be a point in time when people with large IPv4 blocks don't need them and decide they're of limited value and worth and decide to reduce their size category, because their single v6 holding would get them much lower fees.

So it is actually something we've talked about in the ARIN Finance Committee for modeling long term. So, there is a chance that six, eight, 10 years from now we could be in a situation where there's, again, an IPv4 free pool.

I think right now there's a pretty big DECnet 5 free pool. So there will be a v4 free pool one day.

But our staff interpretation is that this is an event and it has occurred, not a state.

Vint Cerf:  Is there a declaration that we need to make in some sense, for clarity sake, we are in the exhausted v4 space now? That's the current state of affairs. Do we need to say that somewhere?

John Curran:  We announced it.

Vint Cerf:  I know you announced it. But does it need to be part of the NRPM document or something? I don't know. I'm just wondering.

John Curran:  There needs to be a policy proposal if the community wants some other outcome.

Vint Cerf:  Okay. Are there any other comments? So the real question is whether we want to continue to work this question, whether we want to continue to either take this policy as is proposed or modify it or abandon it.

And I guess I need to know, the AC needs to know whether you want to continue working on this.

Dan Alexander:  This being in a draft state we're not doing a show of hands in the room, but we do encourage the feedback via the digital polling that will come out later today through the email.

Vint Cerf:  That's fine. So we're done with this I think. Robert, thank you.

John Curran:  Thank you, R.S.

(Applause.)

John Curran:  Okay. We are slightly ahead of schedule. How did that happen? We have six minutes. We are slightly ahead of schedule. I actually see Richard Jimmerson in the audience and will bring him up, and we will do the Policy Implementation and Experience Report, which should go about ten minutes and should take a little bit of your break time, which is good.

POLICY IMPLEMENTATION AND EXPERIENCE REPORT

Richard Jimmerson:  Thank you, John. My name is Richard Jimmerson. I'm going to give you the Policy Experience Report today. The purpose of this Policy Experience Report is to review the existing policies as they exist in NRPM as we've practiced them as the staff and to identify areas where newer modified policy may be needed.

This is based on our operational experience of working with customers in exercising NRPM and also feedback that we receive from customers on a regular ongoing basis about policies and procedures inside the ARIN organization.

And we do this to provide feedback to the community and make recommendations where appropriate. You'll find that not all of these are recommendations. Some of these are more informational. But we have three of them that we would like to talk to you about today.

One of them is issuing prefixes longer than /24. We do this under the policy where we have reserved a dedicated IPv4 block to facilitate IPv6 deployment.

Also going to talk about concept of IPv4 Address Block Swapping and 8.2 Transfer Return Language.

First, prefixes longer than a /24. NRPM 4.10, we have a dedicated v4 block to facilitate v6 deployment. This block will be subject to a minimum size allocation of a /28 and maximum size allocation of a 24. This has been in the NRPM for some time now. We've only issued two blocks under this policy. They've both been /24s.

We did bring this to your attention in this Policy Experience Report. I know we don't have a whole lot of experience with it, but we expect, now that we've reached depletion two weeks ago as of today, that we expect this will become in high utilization between now and the next time we have an opportunity to do this in April of next year.

Some potential issues that we see is organizations who receive longer than a /24, they may experience some routing-related issues. There's been some discussion about this in the past. There has been a policy proposal that was not ultimately adopted as discussed earlier. I think the community dropped that because we hadn't reached depletion yet but now we have.

There's also some reverse DNS-related issues from an ARIN services perspective. Reverse DNS for something longer than a 24 is not something that we do today. It is something that we can employ workaround on right now that basically involves us doing reverse DNS for the entire C or /24. But if we need to, and we'll determine if we need to do this going forward, we may do something like the C name method for reverse for things that are longer than a /24.

We've got two requests so far. And we want to let you know that we will keep the community informed about this policy as it enters expected high-volume use.

I would encourage any of you who are interested in this, there's going to be a table today at lunch where we're going to talk about some research that RIPE NCC did on behalf of the community.

We actually made some experimental allocations to the RIPE NCC out of this /10, and they did some reachability testing for /24s and other prefixes that are longer than /24s, and they'll let you know at that table what the results were.

I expect the results that you'll find in speaking to them is that nothing other than research networks perhaps can see anything longer than a /24 inside the /10.

IPv4 Block Swapping. This is a new thing. This is brand new. We have only seen this twice. I'm going to explain what it is. And we're doing this out of full transparency to the community. This has only happened in the last two weeks. The reason why we brought it to you at this meeting is because we expect to see this several more times between now and April.

And we haven't made a decision on how we're going to implement and how we're going to move forward with this. And we wanted to give you an opportunity to tell us if you think that is wrong.

But here's the scenario:  Small ISP sells a market to another provider. It includes all the customers, all the equipment, but specifically excludes the IPv4 address blocks. The seller of the market wants to retain those because depletion has happened and they don't want to give their IPv4 to someone, even if they're selling to markets.

The seller of the market wants to retain their v4 for that reason. Then this happens. Renumbering issues cause the buyer of the market to suggest to the seller that instead of renumbering perhaps they can swap blocks.

The seller of the market agrees to include the IPv4 blocks in the deal but only if the buyer of the market agrees to provide equal-sized, unused blocks to the seller of the market in the deal. Then ARIN receives an inquiry from both of those customers.

They've submitted a transfer request, asked if they can submit transfer request. This is the issue:  The companies agree to swap the blocks, may run into needs assessment or subsequent transfer constraint issues with their request.

So if they come in and they do a transfer, the recipient has to do a needs assessment according to policy. The two companies want to swap IPv4 blocks with no net change in IPv4 holdings on either side.

So here's the considerations, and we wanted to make you aware of this. ARIN staff considers a request to swap equal space to minimize operational impacts not contrary to the intent of NRPM and will accommodate customer requests to exchange equal amounts of address space.

And basically what we're doing is we're using the transfer vehicle to actually get the request in. We note that they're swapping even-sized blocks, no net change on either side. So we're forgiving a needs assessment on the recipient side and we're forgiving a 12-month lockout on the source side in doing so.

So you can come to the microphone to talk about this. We'll talk about it at the end if you like, but we put this in front of you. We've only seen it twice. We would expect to see it more between now and April. Community feedback is needed if you desire us to do otherwise than this.

And the last one I have up is NRPM 8.2, mergers and acquisitions. This is perhaps the more actionable one. On a weekly basis, we hear from – customers come to us and they're talking about the return language in 8.2, specifically the part that states in bold here:  ARIN will work with the resource holders to return or transfer resources as needed to restore compliance.

People are seeing this language. All they want to do is do an 8.2 transfer. There was an acquisition and they want to transfer the space, but they're afraid because of this return language, just that the existence of the word "return" is in there that ARIN is going to go revoke their resources.

So some organizations are concerned that ARIN will revoke their resources if they submit an 8.2 transfer request because of the return language that's in the policy. Despite explicit language in the RSA agreements precluding reclamation for low utilization, ARIN staff attempts to reassure customers they can initiate the 8.2 process and state they plan to later transfer the resources to another organization under an 8.3 or an 8.4. Their concern about 8.2 return language causes them not to submit the request and leave inaccurate data in Whois. We hear about this on a weekly basis. I imagine that for every one organization that contacts us to ask about this with their concerns, there are at least 10 other organizations that just read it and never contact us.

And there's likely a lot of stale data in Whois as a result of people choosing not to initiate the 8.2 process because of this return language. Considerations:  Perceptions here are very real. The customers are telling us this, and will continue so long as the NRPM return language remains. So we wanted to call this to your attention.

That is the three issues. And we're happy to take questions.

Aaron Hughes:  Aaron Hughes, Board. A point on 4.10. The initial reason for prefixes to be assigned that are longer than a 24 was for the purpose of uniqueness, not the purpose of reachability.

I am unaware of any draft RFC to update OSPF or BGP and the requirement for unique identifiers still exist. That should probably be noted and people should be reminded that it's not intended for reachability but it is intended for the purpose of building v6-only networks with unique 32-bit identifiers.

Vint Cerf:  Thank you, Aaron. Microphone on my far right and then the left.

Mat Pounsett:  Matt Pounsett from Rightside. I actually was also going to note on that part of the reason we wrote in the original policy there they would be assigned out of the same /10 was so that ARIN could publish the /10 that it would be using to allow people to exclude that /10 from their prefix length filters if it was necessary.

So, yeah, if that's not being published or people are unaware of that, then maybe we can do something about it. On the subject of ARIN permitting swapping of address space, I see no problem with that.

I imagine most other people don't. All of the needs requirements in there are based on handing out new address space if there's no change to total holdings.

Vint Cerf:  Thank you for that. Microphone here on my left.

Matthew Kaufman:  Matthew Kaufman, currently employed by Microsoft, speaking for myself, I think. I sure hope so.

On the swapping, I think that the interpretation is totally reasonable. I think it would be nice to draft and have a real policy that says this, primarily so that people reading the policy are reminded that this is something that they could do which might make it better for everybody operationally.

And on the subject of the return language, I wholeheartedly agree that it's a perception thing. I have advised many people, myself, to be very wary of that particular language, and I know of at least a dozen transfers that you've never seen because of it.

Vint Cerf:  Thank you. That's a strong signal to the AC.

John Curran:  I have a comment and then we have another one.

Vint Cerf:  Go ahead.

John Curran:  The return language is particularly ironic, because parties that put their resources under an RSA, there's an explicit prohibition against reclamation for low utilization. It completely preempts the language.

So it is nonoperative, parties who are concerned about it, but having it in the Policy Manual causes concern.

Matthew Kaufman:  Everyone I've talked to is legacy.

Vint Cerf:  One more comment.

Kevin Blumberg:  Two quick things – Kevin Blumberg. In regards to micro-allocations, possibly an editorial change to let people know it's globally unique, globally unroutable – micro allocations. I think the data is very similar to that, and I think the people in this room that are very happy with the policy as it is are very aware that it's not routable at this time and that it probably will never be routable.

But I think that your Joe average end-user or ISP coming to look at this policy thinks that it might actually be usable. And maybe just an editorial change to the title for the micro allocations to sort of enforce that might be another way of doing it.

In regards to the swapping, I'm confused about one thing:  If an entity that is smaller swaps space to an entity that's bigger, and that entity has no assets at that point because they've sold the company, they've sold everything, then why is – if we have the needs model, why is that considered trivial versus nontrivial?

Richard Jimmerson:  In the two cases that have been presented to us so far, it doesn't involve a company that has gone out of business. It's just that one company has sold one of their markets to another company. So both companies still exist, and the company that is selling the market wants to retain the v4 and has said that they're willing to allow the organization receiving the market to retain the address space for that market only if they receive an equal amount of address space back.

Kevin Blumberg:  I guess what I'm saying is if you have two entities and this is 10 percent of their total holdings it doesn't matter one way or another. If you do an asset sale with the IP swap and the market is the that entire company to begin with, and they go from it being 100 percent instead of being 90 at 0, then you're swapping back and all they're left with is a shell of IPs –

John Curran:  If I could – we haven't had that case. We've had cases where it's been operational entities that have other markets and other business.

Kevin Blumberg:  Right, I just wanted to clarify because staff views this as having a minimal impact, et cetera. But there are situations where that would not be the case.

Richard Jimmerson:  We could be presented with that case in the next six months, it's true. We have not yet.

Vint Cerf:  We have two more comments, apparently.

Scott Leibrand:  Scott Leibrand, ARIN AC. We recently adopted a policy change regarding the last of your issues that removed the word "revoke" from return, revoke or transfer.

We did that with the intention of getting rid of this misunderstanding that ARIN might revoke your space when the RSA says they can't.

Now we have people who say, well, even though the word revoke is gone, the fact that the word return is even in there is still scary.

Richard Jimmerson:  It is and we receive inquiries weekly from them about that.

Scott Leibrand:  Would it be efficient to remove the word "return" and just have work with them to have transfer? Or would these organizations still be scared by the word "transfer" as much as they're scared by the word "return"?

Richard Jimmerson:  I'm not entirely sure. I know right now the concern they voice with us has to do with the return language.

Vint Cerf:  John.

John Curran:  To be clear, the concern is about nonoperative language, and you're asking a question whether or not the policy itself should change rather than removal of nonoperative language. That's a different question.

Scott Leibrand:  Well, we removed the inoperative language. That's done. What's left is operative language, which is to say ARIN will work with you to try and get you to give the space back to them for free. Yeah, right. It's operative language but it doesn't actually happen in the real world. So removing that is almost a no op and I would be fine with that.

I am wondering if there's anyone in the room who can speak to the people who have these concerns and say if the word "return" was removed and we were left with – okay, Owen just said over my shoulder that we could add the word "voluntarily" transfer and that might address it.

John Curran:  That's a possibility.

Scott Leibrand:  I'd like to work with anyone who is interested in this to get good language that will solve this. There is a Draft Policy on the docket for later today or tomorrow that would remove this entirely as part of a much bigger change, but I suspect that there are a number of people who might want to remove this just without all the other stuff that goes along there.

If anyone is interested in that after this week, we can probably put it in a new policy proposal and make the same sort of change we tried to make the first time but further along to really get rid of any remaining concerns.

Vint Cerf:  Thank you, Scott. Microphone on my far right.

Marc Lindsey:  Mark Lindsay, Avenue4. On the 8.2 return, I'll respond to Scott, part of it is there's this gap, right, and you only get to the RSA or LRSA after the request has been approved. What if your request is denied? You're still looking at this language as potentially impairing address space that may not currently be subject to any contract and saying, oh, if I submit this I'm opening myself up to this sort of implicit threat of having to transfer or having to give back before I get approval. Once I sign, I have some protections, but my broader point is ARIN doesn't need to have this in the NRPM to do this. It can encourage anybody who comes with address space and say, hey, by the way, we've got this mechanism called 8.3 and 8.4. If you're not using it, why don't you give it back? So you don't need to have this implicit threat that's dampening 8.2 requests when staff can do it as a matter of coordinating with those who are making those transfer requests in the first place.

John Curran:  So there's two interesting issues there. The first one is it is true that people wonder whether we'll apply this language even if their transfer request isn't approved.

This truly is a case where it's only if the request is complete that we then work with them on that. And another option would be to make plain that upon completion of the transfer, ARIN will work with – that would be one answer.

The other one, of course, is for parties who are concerned about that, upon entry, they can enter the RSA before doing a transaction and their resources are protected in that manner.

Owen DeLong:  Owen DeLong, ARIN AC, Akamai. We're getting really wrapped around the axel. When this language included the word "revoked," it was clear that revoked was an action taken unilaterally on ARIN's part against the resource holder and the return was a voluntary act of the resource holder. Apparently when we removed the word "revoke," people lost sight of that.

So I would suggest that instead of removing language, what we need to add is language that clarifies that return is a voluntary act of the resource holder and not ARIN revoking the space as people are now apparently interpreting the word return to mean.

Which is kind of silly, but I understand the confusion. So be it. Can we go back to the swap? The problem I see with treating swaps generically as benign and just blanketly accepting them is that you apparently have one organization which has resources they weren't using and one organization which has resources and a deployed network that they were using. And the second organization now sells the operational networking customers to the first organization, and the first organization as part of that exchange wants to trade the resources they weren't using to the organization that no longer has the operational network using the resources.

And so you're essentially taking one group that had resources they weren't using and giving them to another group that no longer has need for the resources but wants to keep the resources.

I do not see that as benign. I do not see that as a good thing at all for the community. I see it as an end run on the intent of the policy and the goodwill of the community, and I resent it.

Vint Cerf:  And later you'll tell us what you really think.

(Laughter.)

John Curran:  Presumably, Owen, you'll work with people to get policy language?

Vint Cerf:  Microphone on the far right. My far right.

Joe Provo:  Joe Provo, Google. Putting my hat on as a former guy who ran a cable company, I see the intent of the swap as, hey, I just bought a market. I don't want to number everything needlessly. And that sounds like the existing cases were operating entities that were actually doing stuff. It wasn't, as Owen indicated, somebody who was just trying to sidestep needs assessment.

I just want to – I think there's room for that sort of dangerous action, and while the staff hasn't encountered it to date, I do think we want caution with just a blanket, operational, tacit approval of swapping, and it might require policy adjustment. I just wanted to raise that red flag, understand it so far hasn't been a problem but it sounds like we might open a door to the problem.

Vint Cerf:  Thank you for that. I'll close the queues except for the people waiting to speak. I'll take the microphone in the center rear.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. I would implore people to not take the worst motives that could possibly be thought of and apply them to all situations.

Equally, we probably shouldn't take – put our heads in the sand and assume everybody's motives are the best, but maybe find someplace in the middle about making assumptions of what people's motives are.

Most people are good most of the time. Let's get over it.

Vint Cerf:  And the last comment, over on my far right.

Dani Roisman:  Dani Roisman with SoftLayer. Regarding the language that ARIN may ask for return, may revoke. The organization can return. I think if we're talking about putting in language that states that the organization may voluntary return, I don't think it has anything to do with transfers. I think at any point in time any organization should probably know they can voluntarily return any resources back to the registry if they so desire, and if that's the point and we just need to clarify and write it out, let's just find a good bullet somewhere and say, at any point in time you may return any resources you wish to the registry. I don't think it has to be shoved into the middle of transfer language.

Vint Cerf:  Thank you for that.

I think that we now exhausted our discussion on this topic. And it's pretty close to a break time.

John Curran:  Yes. Okay. Thank you very much. Thank you, Richard, for your report. Folks who want to pursue these ideas with policy, one way or the other, get together and talk about it, and you know where to find your friendly AC member.

We are actually on break, and we are going to resume at 11:00 – let's be generous. We'll resume at 11:05. So you have 18 minutes. I look forward to seeing everyone back here in 18 minutes, where we'll pick up with the presentations. Thank you. Break is right outside.

(Break)

IPv4 Exhaustion

John Curran:  Okay, we're going to get started so we don't fall behind on lunch. We have three topics coming up. The first one is IPv4 Exhaustion Update, the second one is the IANA Stewardship Transition Update, and there's fees and services discussion.

I'm going to actually start right in now regarding IPv4 exhaustion. We kind of covered this earlier. It happened. We are now officially out. The IPv4 free pool went to zero. I guess clap. You can clap if you want to clap. I'm not sure it's a celebratory event. But we have hit exhaustion.

The ARIN IPv4 free pool is deleted. The waiting list has been triggered for some time. As people still come in, we have people coming in with requests, they're being put on the waiting list.

We actually had a source of addresses come in. The IANA has a remnants policy that was global policy developed by the RIRs, and they actually issued address space which we had enough people on the waiting list that what we received from the IANA was reissued, per the waiting list policy, to parties on the waiting list. And, again, the free pool remained depleted.

We expect the free pool to remain depleted for the foreseeable future, numbers of years. There are some addresses coming back.

So if you're on the waiting list and you want to know when will I be satisfied, the answer is I have no idea. And no one does. Anyone who tells you that there's a predictable period on the waiting list is lying. There is none. And, in fact, you may never make it off the waiting list.

If you're planning for your business based on being on the IPv4 waiting list, you're doing something wrong. Okay. You may not plan for your business based on the waiting list, because I can't tell you when you'll get off, if ever.

However, there are addresses coming back. So we did have the IANA. The IANA has the remnants policy, and that will produce another block of addresses, another six months.

But it's diminishing, getting smaller every time, not expected to make a huge impact.

We have addresses coming back right now. So let me talk about this. If in the last few weeks you were given one of the last address blocks and said, here, you can either take a /24 or you can go on the waiting list for your request, which was approved at /21, say, and you received that email, we didn't send you an empty email message. We actually put the /24 on reserve.

So if you said I'll take the /24, it actually would be there. Some people are receiving that message and going, look, I was approved for an /18, you're offering me a /24, haha, I understand, but no thank you. It's not worth the effort, so I'll stay on the waiting list for an /18 just in case.

And then that /24, when we receive that response, or if we receive no response and it times out, either way, that /24 goes and is freed up and immediately goes to satisfy the waiting list.

So there's a few people on the waiting list who are getting trickle announcements like, hey, you've been satisfied. Imagine that. Even though we didn't get any large IANA relocation of remnants, even though there wasn't an event, there are small blocks coming in.

Additionally, we send out invoices. Let's see, how does this work? We send out invoices. Parties pay the invoices. Everything works great.

There's another track. Track B. We send out invoices and you don't pay them. This is actually covered in your RSA. And we send you a notice and we send you more notice and we send you more notice.

If you don't pay attention to any of those, then we actually will reclaim the block or revoke the block for lack of payment.

And you'll notice then, because – maybe notice, you might notice, it goes out of Whois and IN-ADDR fails. There's a very short window where that happens where we actually still haven't reallocated the block. And in that very short window, if you come back in, you can save yourself.

But then after noticing that it's not in Whois and it's not in DNS, if you don't do anything yet, we eventually – the block's reclaimed. We put it in hold-down for a short time. Once it's out of hold-down, we use it to free up items on the wait list.

So it is possible for you to lose your address block for lack of payment and for someone else to end up with it 157 days later or approximately, given all the notices and the repeated notices, et cetera, et cetera.

So that's the second source. The third source, we sometimes have address blocks that we've reclaimed but we reclaimed them some time ago. The documentation that we have may not be what we want, and so there's some number of addresses that are held that we're busy cleaning up, we're busy making sure indeed we have the right level of paperwork.

And so we may occasionally have address blocks on hold that aren't in the free pool but will enter the free pool. Again, because there's a waiting list, they don't go to the free pool. They instead are used to satisfy the waiting list.

So that's where we are. If you – you can still put in a request to ARIN. We have people submitting requests for allocations and assignments. Feel free. Come on in.

But you're going to end up on the waiting list and you're going to end up behind everyone else on the waiting list.

Just want to be really clear. That's it for IP exhaustion.

I guess one other little detail, there are two parties that have exceptions here. Critical infrastructure. We have a reserve for critical infrastructure. If you happen to be operating critical infrastructure and you need an address block, there's a policy for that, there's forms for that. Fill them out. You can get an address block. Exchange point operators, guys, that's you.

And let's see. The other one is, as we were just talking about, access to an address block for uniqueness for purposes of IPv6 transition. Again, we have a block reserved for that, and you can come get it. Otherwise, we're out.

I can tell you about the joke that an IP address walks in the bar, asks the bartender for a cider. He says he's excited. Yeah, right. So any questions on IPv4 exhaustion?

No, no, no? If not, we'll move on to IANA Stewardship Transition.

IANA Stewardship Transition

John Curran: Okay, equally exciting topic. I'm not going to use slides because if I had done slides last week they would now be officially out of date.

We have a nice dynamic topic here. So the IANA, as you all know, is the – maintains the Central Registry, about 2,000 IETF registries, about six Internet number registries, and then the DNS root zone. And last March – not this prior March, the prior year, 2014 – NTIA, US Department of Congress NTIA, National, Telecommunications Infrastructure Agency, announced that it was willing to transition the stewardship for that IANA task and those registries from the US government to the Internet community.

Now, it said it needed a plan, and we launched a process of developing a plan. In fact, the process for developing a plan, each community came up with its own.

In the case of the names community, something called the CWG working group came up with a plan. In the case of the IETF, they came up with a plan, the IANA plan, IETF Working Group. And in the case of the RIRs, we formed something called the CRISP team, Consolidated Regional Internet Stewardship Planning activity team. And they came up with a plan. So all three plans for how to handle the stewardship for those affected communities have been put together.

And to be clear, we're not talking about transferring actually any operations, ICANN is doing the operations for all of these. But it's doing them because the National Telecommunications Infrastructure Agency has a contract with ICANN. NTIA is effectively the steward for all of us. It wants to get out of that role. It's willing to do that.

So instead we will all contract with ICANN and ICANN will administer these registries on our behalf as opposed to on behalf of the US government.

So when this was going on, the names community, which has the CWG, the Cross Community Working Group, that came up with their plan, they came up with six community powers. See, they rely on ICANN to represent them. They don't have a distinct RIR structure or distinct IETF structure. ICANN is the one doing the registry operations, ICANN is the one doing DNS policy, ICANN is the one that's providing coordination and oversight.

So the names community is a little different because it's embedded within ICANN. And it said we need certain powers over the ICANN Board, six community powers, ability to control the change of bylaws, the ability to control the change of – remove a Board member, remove multiple Board members, ability to approve the budget and the operating plan, ability to have the Board take on and take an independent review output and actually make it binding on the organization.

When the CWG came up with those prerequisites for its stewardship transition plan, ICANN has to change to make that happen. And ICANN kicked off a Cross Community Working Group called the CCWG. The CCWG is responsible for coming up with a plan for improving ICANN's governance and accountability, which it has worked on for the last year or so.

And it came up with a plan. The plan has evolved a bit. At one point it was going to make ICANN a membership organization. At one point it was going to be something else.

In the end, they settled on a mechanism called a community mechanism as a single member, where there was a council made up of all the organizations in ICANN, and that council is the single member of ICANN.

So ICANN Board ends up with us being a membership organization with one member. The Board's still there, the organization's still there. But there's a single member. So you end up with a membership organization where instead of having 10,000 members or 100 members, you have one.

Membership organizations are interesting. The members have certain powers. So the proposal from the CCWG is that ICANN adopts this, change its bylaws, make ICANN a membership organization with one member, the community council, and the community council would pick up these six powers that it needs to make sure things stay accountable.

The Board wrote back and said they believe in the principles. They believe in the goals. But the actual mechanism of a single community member, given how members work for membership organization, they did not support, and they came up with another proposal.

All of this is in the last three weeks, by the way. Now, this is making progress. We have a plan again for names, numbers and protocols. We have one plan on how to transition it. But we have this ICANN accountability prerequisite which was not met.

And we all expected this to be done – well, the original deadline was September 30th. By September 30th we would have all given the plans this summer. They would have been reviewed by NTIA and they would have pulled the trigger and we would now be done, we would be effectively stewards of the identifiers of the Internet.

That didn't happen. And, in fact, we're now well past the deadline. And so the question is now is this still going to happen? And we actually don't know. We're optimistic.

But the ICANN Board and the CCWG, the Cross Community Working Group, working on ICANN accountability, have incompatible proposals and are in active frantic discussion with one another about which one has a better proposal.

So until that actually closes, we don't know whether or not we can have one combined plan to transition all of this.

There is – it has been noted that the IETF, its proposal for how to handle its stewardship for the Internet protocol registries, is an RFC that already exists. It's an MoU between the IETF and ICANN called RFC 2860. It's been in use 15 years. It's well proven. It's running code, to use their phrase.

So the fact of the matter is the IETF is like:  We're ready. And even if these other folks don't get their act together, we're really ready. In fact, we wouldn't mind it if this happened anyway.

In the names community, we have a relationship with ICANN where ICANN ratifies our global policies. And that's a nice check and balance to make sure the RIRs don't collectively make policies up at random. We actually have to have open and transparent processes. We have to follow them.

But we don't have a relationship with ICANN as a service provider. We don't have a contract or a Service Level Agreement for ICANN to operate the registries – the IANA registries for us, the central one, the one that mostly is empty for v4, has a bunch of v6 space and has a bunch of ASN, 32-bit ASNs in it.

So the CRISP team proposal calls for us to have a Service Level Agreement. In fact, there's a draft Service Level Agreement, and the RIRs are busy working right now to finalize that with ICANN. We'd like to have a Service Level Agreement in place with ICANN. Once we have that in place, we also are ready to go. Our mechanisms are in place. We're not changing the operator. ICANN is our operator.

And so one of the questions that's come up is:  We'd like the names community and ICANN Board to work out their differences so the names community is happy with its plan and its prerequisites and so that they can proceed.

But one way or the other the IETF and RIRs are ready. And we actually may have to say if they're not ready, if the names community isn't ready and remains unready, we may actually have to say we'd like to proceed anyway.

Right now it's one plan with us all going together. We're encouraging the ICANN Board and the ICANN CCWG to work out their differences.

Turns out there's a very significant meeting happening two weeks from now in Dublin, the ICANN meeting. And this will be the topic of conversation. I'm not saying that ICANN doesn't have other topics going on, but this is the foremost question is, can the community come up with one comprehensive plan that covers all the IANA registries, or is it a bridge too far for the names community and the ICANN Board?

That's about a wrap-up. Questions on that? There's not a lot of times I'm going to be standing here taking questions on this topic. So, yes, go.

Andrew Dul:  Andrew Dul, just a quick question, can you give any input on the process of the negotiating the agreement between the RIRs and ICANN and how that's going?

John Curran:  So the SLA, the Service Level Agreement, for ICANN to provide IANA numbering registry services, is based on an outline in the CRISP team proposal. The CRISP team is a team that the RIRs put together with community members. They gave us an outline. We turned to the RIR legal folks, and they drafted an actual SLA. The outline and the SLA that was drafted reflect the existing agreement between NTIA and ICANN, meaning we used a lot of governmental phrasing and terms.

ICANN has come back and said, yeah, we understand why you did it, but we'd like to do it with simpler language.

We think that makes sense. ICANN has suggested some language. We've looked at it. But at this point we're not at the point where we've had an actual discussion.

And there's also a question of we shouldn't be just moving ahead with something; the community needs to see this agreement. It is going to follow the CRISP team outline.

So what we're hoping to do is hoping to have a face-to-face meeting to hear from ICANN exactly what they'd want to change and then based on that send something out to the community and say:  Here's what we think we can do; here's what we think we can't do; here's what we think the final agreement looks like.

We'd like to move pretty quickly on that. But we have to get to Dublin and sit down with ICANN and actually hear them present. They've told us verbally they'd like plainer language. We'd like to actually hear it from them and see what they're proposing.

But, yes, we intend to take the final result and, once we're all agreed, send it out and say this is what we're looking at.

Vint Cerf:  If you don't mind, I'd like to ask John one question.

In particular, none of this is to indicate that we at ARIN or perhaps any of the other RIRs are unhappy with the functioning of the registries by IANA.

And so this is not in aid of removing us from that operation, it's simply to document a new relationship, formal relationship between the RIRs and ICANN for the IANA services they provide.

John Curran:  Right. Very much the case. This is just to make sure we have a relationship that's between us and them for these, so that in the absence of an NTIA relationship someday we're still covered. Owen.

Owen DeLong:  So I got the draft SLA. And it had an address in the message I got to send comments. And I sent my comments to that address, and about two or three weeks later I got a nice email from Izumi (phonetic) saying:  You probably wanted to send these comments to this other address.

I went, okay, and I sent my comments to that other address, and a couple of days later I got a nice email from somebody else saying:  You're commenting on the SLA, so you probably really want to post to this other address.

Is there any way we could make the process of commenting on the SLA ideally to the address in the message that we got the SLA from work, without having to go through that?

John Curran:  Hopefully we won't have to go through that again. I'll take the fall for some of that. So there's an interesting question, which is that, in theory, you folks rely on ARIN to provide a bunch of services. And we rely on ICANN to provide some services along with the other four RIRs.

We all collectively rely on ICANN. Much like the contract for the hotel here or the contract for the break, we contract for stuff so that we can fulfill our obligations to you.

One can argue that the contract with ICANN is this little administrative detail over there, it's just between the RIRs and ICANN no one cares about it.

The reality is, however, that it's the IANA. And we all know how important that is. So while we took the outline from the CRISP team, and the RIR legal team drafted the first SLA, there's a question of how to process the comments.

And are those comments that the CRISP team processes or our legal team? Is that something that the RIR executives collectively process? We didn't have our act together. I'll be the first to say it. We may not have had our act together because I was one of the people – sort of everyone was marching left and I was marching right, but that happens sometimes.

We at this point will make sure when we send out the final draft we have a nice clear comment link on it and say this is what we intend to do, here's where you comment.

I don't know what the comment period is. This is something that, again, five RIRs have to all agree on that. I have to get together with my fellow CEOs. But we'll make sure whatever the process is it's very clear and we don't redirect you like we did the last time.

Other questions on the IANA Stewardship Transition?

(No response.)

Fees and Services

John Curran:  Lovely process. Lovely people. Going full speed ahead. Somehow, someway we'll get there.

Okay. If there's nothing else, I'm now going to open it up to a services and fees discussion.

First topic I'm going to talk about is services. So we provide services to you folks, and when we provide services, we use a mechanism sometimes when we're going to change them, we send out something for consultation.

We have the ARIN Consultation and Suggestion Process. And so if the staff's initiating something, we'll say, hey, we're thinking of changing this, we'll put something out for consultation. That's an ARIN Consult List.

So there are a few people in the room who are on the ARIN Consult List and respond, and even when we cross-post to ARIN Announce that we have this consultation open, but basically the number of comments we get back is very small, very small. And it's lonely out there.

Now, the ARIN Consult List advises me, because I'm the one who actually has to decide what the staff does when it's investment time, what we recommend to the Board.

And I'm lonely, basically. It's quiet out there on the ARIN Consult List. There's a few of you who are frequent commenters, but if you get the same three or four frequent commenters and those are the only people working on suggestions and commenting, it's not clear that we're getting a well-balanced view.

We've talked about this a bit. And, in fact, recently in the last ARIN meeting we chatted briefly about an ARIN Services Working Group.

There actually is a proposal now I brought to the Board to next year formally charter an ARIN Services Working Group. I grabbed some AC members to help me do some drafting of a charter. And we actually will put that charter out before we actually impanel it in 2016. We're going to put the charter out so you can see it.

But effectively what we're saying is it would be a working group, and rather than me processing the comments on the consult list and me processing the comments that are on PPML and me deciding the priorities and the relative merits, I would ask this group to take the first cut at that.

And this way, when we're talking like in development, sometimes we'll have 12 suggestions, and we need to know what's the right order. Well, I can order things. I know how to do one, two, three, four, five, but the last time I checked I don't run a network.

So we're going to ask for volunteers for the Services Working Group. It will be a small group of people – eight, 10, 12, 15, maybe – and we'll ask them to do the heavy lifting of considering these things and helping prioritize them and provide more structured feedback.

I'll use that in making recommendations to the Board, recommendations to the staff on what to develop.

But I think it's better to have a way of you folks formally engaging. We'll send the charter out. You'll see it come out in the next couple of weeks. And of course you can comment on it. You same two or three people who comment on things can comment on it, too. But the goal will be to have a Services Working Group that's a little larger and get more feedback.

I guess questions on the Services Working Group, and then I have a fee presentation to talk about.

(No response.)

John Curran:  No, no, no? Shouldn't be surprised. We talked about this at the last meeting.

Okay. Fees – oh, we've got one. Sandra?

Sandy Murphy:  Sandy Murphy, PARSONS. Is the Services Working Group going to work on the Service Level Agreement?

John Curran:  Yes, actually. Quite frankly – well, not the Service Level Agreement between ARIN and the IANA, because that's an agreement –

Sandy Murphy:  No, no.

John Curran:  But in terms of our services, for example, if we're proposing changing the terms and conditions of one of the services, Whois or RPKI, we would use the Services Working Group to consider that, consider what's proposed, make its own suggestions.

It would be the first buffer for getting community input on terms and services for all of our services.

Sandy Murphy:  Okay. Thank you.

John Curran:  Michael Joseph.

Michael Joseph:  Mike Joseph, Google and Alpha Bit. While I'm happy to see traction here, I lament the fact that it's next year we'll start a working group to discuss services.

I still can't understand why ARIN is unable to document its understanding of the current set of services that it provides now. I don't think we need a working group for that.

I think we need somebody at ARIN to take a piece of paper and write them down and publish that list. In fact, such a list would be a great start for a future Services Working Group.

John Curran:  Right. Actually, probably task one or two for the Services Working Group would be to review such documentation.

Mike Joseph:  Great. When can you produce it?

John Curran:  We're going to work on the documentation, and we're going to kick off the Services Working Group in January, we'll staff it and get that through. But, yes, I do believe it's a very important thing to have.

Mike Joseph:  I do, too, which is why I've been asking for it the last three meetings.

John Curran:  Patience. Good things come to those who wait. Except for v4; then you get nothing.

(Laughter.)

John Curran:  I want to talk about a fee discussion, speaking about good things and those who wait. Okay. So some of this will be perfectly expected. Some of this might be a surprise.

Fee Structure Review Panel. We had a Fee Structure Review Panel that looked at seven different models for how the ARIN fees should evolve.

It produced its final report in September. We talked about it last year. And at the end of the day, we ended up with two very clear outcomes from that process. Now, two very clear outcomes was that there was general expression that IPv4 fee category should be lower for small address holders and larger for larger address holders.

Note that our expenses – our actual costs for a /16 in the database and a /24 in the database are probably indistinguishable, it's database records in Whois and membership relation and so on and so forth. But the benefit, however, is disproportionate and community members said, yeah, the benefit being disproportionate means that the ARIN's recovery of its costs should also be similarly spread based on the benefit received in the community. Some people have more effective benefit; they should end up paying more. Those who get less effective benefit shouldn't be carrying an equal share of ARIN's costs.

The other issue that came up is IPv6. We need to encourage IPv6 deployment and need to have minimal IPv6 fees and avoid creating disincentives on the fee schedule.

And so with those two points, I regrouped with the ARIN Finance Committee and tried to come up with what we could do, and I'm going to bring those to you. This discussion is to advise the Finance Committee, because eventually they need to bring a recommendation to the ARIN Board. The ARIN Finance Committee is a subset of the Board that's responsible for doing the first pass at these things.

We didn't have consensus on a lot of more innovative proposals, by the way. These two takeaways, IPv4 fairness and IPv6 support, were clear. But some of the things like flat fees per members and algorithmic billing approach, a whole bunch of other stuff, did not receive uniform support.

So what we've done, working with the Finance Committee, is we've modeled first the present fee schedule. We took 2015 members' resource holdings and modeled it to make sure we knew what that looked like, and then we looked at a fee alteration where we shifted all the IPv6 categories to be four bits larger.

So if you were a category XX small or X small and we – or you were medium, when we add the shift, you would go down a category because that category could now hold people who had much larger, 16 times larger v6 resources.

We also modeled the v6 shift adding – sorry, the v6 shift through a new XXX large category. People pay an annual fee based as the category that holds their v4 and v6 holdings, whatever puts them in the higher category.

And so in adding a new XXX large category, it reflects the community saying we should recover more from those people with more holdings.

It turns out what we lose with the v6 shift in revenue is nearly offset equally by the addition of the XXX category. I'll talk about that.

We also modeled the new XXX small category in addition to the XXX large. And this is really applicable because there's a possibility that we want to talk about, which would be the possibility of end-users, particularly end-users who have a lot of ASNs, who want to actually pay the same amount they would as an ISP, even though they're an end-user.

Right now, if you have enough resource records, your maintenance fee on your resource records can – at 100 apiece can add up to more than a corresponding ISP, because the ISP only pays a fee based on their total v4 and v6 holdings.

And then the last one is looking at the fairness and equity, if we're going to do XXX large, why would we artificially cap it there, why don't we go to the full IPv4 address space and add XXX large and XXX large, getting us some pretty high top categories.

So those are the five things we modeled. There's a couple of questions I want feedback on, but first let's go through the models.

So our present fee model – that's an eye exam, but this is also on your – it's on the website if you go to presentations, look for John Curran. There's a PDF for the fee schedule.

This is the present fee model. And I guess the most important thing to realize is ISPs, we have 5,137 ISPs. This doesn't model – this models the ISP fees. It shows the end-users and the AS's separately in the upper right.

If you look, you can see we get 13 – sorry, 13972 for ISPs, end-users ASNs total is 16.3 million revenue per year under our present model. So this is the base case.

When we shift all the categories, now an XXX small category is up to /36, not /40. This was widely supported.

Financial impact:  We go from 16.36 million to 15.38. Approximately a million, 980 K drop. So that's what this is. And for people who can see, you can see how people break down by category.

We end up with a lot more extra small ISPs, ones that were previously small in the prior model, we had – I can't see that – 2,000 some-odd small. And we had 1280 extra small. When you go forward, it's nearly reversed – 2,000 extra small and 1280 small.

So users end up – ISPs end up being in smaller categories, generates less revenue.

Next:  If we do that, and in addition we add an XXX large, the new XXX large category catches those whose IPv4 holdings are larger than /12. Right now they pay 32,000. They would end up being falling into a new category and would be XXX large paying 64,000. 36 organizations fall into this we have more than /12 in total resources. For 36 organizations they would see their fees double because they would now be in a new category it would go up 32,000.

Again, getting more from big guys was widely supported. It brings in about a million a year, brings us back up to 16.4.

It would be net revenue neutral. That's what you have here. Again, online the charts are available.

So we could keep going. Beyond that, we could look at adding an XXX small. One of the things people have noticed is that ISPs pay a single fee. It covers their v4 and v4 resources. It covers all their ASNs and it gets them membership.

We charge $500 a year for an ARIN membership. If you're an end-user or legacy and you want to be an ARIN member, you pay $500 a year for the privilege.

Well, it's been – I think the word that was kicked around – someone said poll tax? Is that the word? But I won't say it ever again. It would be nice if there was a cost-effective way for an organization to become an ARIN member. If they were end-user or legacy, this would provide it.

We could add a category and we could allow end-users and legacy holders to become ARIN members by paying for a registration services plan just like an ISP.

They would gain vote. They would not have to pay for the ASN maintenance. Instead of paying per resource record, $100 per year for every record in the database, they would pay based on their total v4 and v6 holdings based on the category that accommodates both.

Moves us towards a situation where ultimately we could have a uniform fee schedule for everyone, because long term I will tell you that end-users' holdings are significantly smaller for v6 than ISP holdings, almost universally.

It's just the way the policies you folks have developed works, is end-users end up with smaller space. So they would end up paying less.

Nominal revenue impact by adding this. We don't really know how many people would jump on board, but it's a possibility and it also gets us towards the direction of a uniform fee schedule. Also addresses the issue of parties that have the desire to participate in ARIN but don't want to pay $500 a year. A lot of them might fit in this XXX small.

Okay. We could keep going and we could add XXX and XXXX large categories. If you want to make the fee schedule completely uniform, then the XXX, 4X large are people who have holdings larger than /8. Nine organizations, folks.

Two of them are under LRSAs and their fees are capped. But the others aren't, and they would see their fees go to 128,000 a year. That would be an increase from the 32 they're paying presently. So when you're looking at the breakdown, that's nine of the 36, 27 would remain in the XXX large.

Financial impact:  We'd pick up about 440,000. We don't need this revenue. This would be as an argument for equity and fairness we would put this in if you really wanted to recover proportionate to benefit. But this is revenue beyond what we're currently getting. And it's not clear that we have a demand for that. We have ample reserves. We have financial strength.

Makes the fee schedule uniform, though, for people who like columns that add up smoothly.

And that's what it looks like in the model. You can get it online.

So lots of schedules. Lots of questions. Really there's two important ones. Oh, one more. Transfer fees. When someone does a transfer, we do a lot of work. And we have people who submit transfers sort of on an ad hoc basis and kind of ask if it will fly and then after we do a lot of work, they say, oh, we're actually not interested, thanks.

We actually also have a number of facilitators have come to us and said this process is screwy. We submit an application with our customer. You do a lot of work, and at the end there's some email that tells us it's approved and we have to now restart everything and now we have to – we had everything together, now we have to get an agreement, we have to get the payment, we have to get all that done. We want to do this up front. We want to pay up front so when it's ready to transfer, you just do it.

We believe that the abandoned rate is an issue and that we're actually getting nuisance requests, requests that people don't actually in good faith want to make but have no charge so why not try.

There's a question whether we should move the transfer fees to the beginning of the process and payable regardless of outcome.

Transfer processing is the most labor-intensive thing we do, because we're often vetting the credentials of an address block, we're often verifying the past legacy of the address block, and there's a needs assessment.

So community feedback. I have one question, and I have one question. I guess I have one more because of the transfer one.

So question one, should we have an XXX small category and allow end-users to pay based on total holdings? Question one, should we add XXX and XXX large categories for consistency? Question one, should we move the transfer fees to the beginning and make them payable in advance regardless of outcome?

Microphones are open on anything that's been discussed. Yes, David.

David Huberman:  David Huberman, Microsoft. So like Warren Buffett has been saying for years:  I want to pay my share of taxes and I don't. I can remember going back 10 years ago and Dave Barger and other big guys saying we're happy to pay more.

I work for Microsoft. We have very large holdings. We're going to continue to have large holdings. You do not charge us enough and you've never charged us enough.

Meanwhile, you're looking at end-users going to 250 as a base fee for a /24 or a /40 or something. They used to pay $100. And that's a much bigger increase than anything big guys have ever seen.

So long and short of it, your second No. 1, yes. Yes, it's not about columns adding up. It is about equitability. And the large ISPs, the large networks have been stealing more than their fair share from the small guys for a very long time at ARIN.

John Curran:  Excellent.

David Huberman:  Definitely yes on the first one there about the extra extra extra small. If we can get the small guys' fees closer to a penny, that would be nice.

I don't support your idea of charging for transfers beforehand. You are a not-for-profit corporation that helps in a benign way the network operators conduct their business at the registry.

You run a help desk that is open from 7:00 a.m. to 7:00 p.m. Eastern on the phone, on email, on the web, on Ask ARIN, in person here at meetings, in person at NANOGs. You're there to help people, the ARIN staff do that very well.

If you get nuisance requests, I don't care. You can deal with them. You clearly have the money. You keep telling us that. Please don't charge people beforehand. Work with them, help them. Be the friendly benign ARIN you always have been. And at the end, you charge. If someone doesn't want to pay it, someone doesn't want to pay it. Either you have a fee for transfers or you don't. But if you're going to have a fee put it at the end, please.

John Curran:  Thank you. Microphone 1.

Dani Roisman:  Dani Roisman, Softlayer. I don't know if you covered this, but I didn't hear it clearly enough, in light of all the fee assessments, did you assess what your target annual revenue needs to be?

John Curran:  At present, the target annual revenue is the base. This is a discussion of how we recover the present fee model. Right now the Finance Committee has not given guidance to me to either increase the revenue stream ongoing or decrease it.

We have made a conscious effort to keep the revenue stream the same this year and spend more. But that was not with the idea that we would increase the fees; that would be building down the reserves a little bit so we can offer more services to people.

But I haven't had guidance to change the recovery. The recovery is felt to be adequate for the organization.

Dani Roisman:  The other thing I wanted to mention with the new inter-RIR policy that RIPE just adopted, RIPE members pay a flat 1750 Euro –

John Curran:  I'm sorry, I'm going to ask you to stop. If you have merits about our fee schedule, I'd love to hear it one way or the other. I actually do not want a comparison to fee schedules with another RIR. I have no interest in that nor having the discussion occur here.

Dani Roisman:  That's not what I was proposing. I was saying I was wondering if you were considering whether or not ISPs that are now paying a larger fee schedule in ARIN might choose to migrate their resources over to RIPE since RIPE no longer has a country-based – okay.

And then my only last point, which was somewhat aesthetic, was maybe instead of adding a whole bunch of Xs, if we go this route, we can choose more creative words like micro mini, nano, mega something, because the four Xs, three Xs, I think it gets difficult to communicate.

John Curran:  I guess my question is in order to support smaller categories and have names, I'm asking do you support any of these changes, I guess, because I hadn't heard that clearly.

Dani Roisman:  I can't answer that because I don't understand if there is a target revenue change or not. I think if the revenue stays the same, I don't support adding additional changes if the end result is the same.

John Curran:  Far microphone.

Michael Sinatra:  Michael Sinatra, ESnet. I was on the original fee structure development committee, so I'm responsible for some of this. I do want to say that I, as a member of that committee, gave the feedback that I do not believe that IP address holdings should be conflated with revenue potential and that the fact that people have a lot of IP address holdings does not necessarily mean that they are rich.

With all due respect to David, who I like very much, and Microsoft, which I regard as a rather rich company, there are organizations out there which have large holdings and cannot afford the fees that Microsoft can afford.

That's one thing we need to think about. There is a very strange loophole in all of this, which is that a lot of the organizations I'm talking about that are nonprofits, they're big research universities and research institutions, often tend to be legacy holders. So they're not paying fees anyway. They now have no incentive to pay fees. They have no incentive to – or even less of an incentive to sign an LRSA, although the LRSA caps fee increases also.

So there's this weird loophole where we have this – this whole thing kind of comes out in the wash nicely, but I'm not sure that's the way we want the fee structure to be organized.

We should at least just keep that in mind. I don't join the consensus that we should be soaking the large holders. I'm not even sure I'm joining consensus that we should be soaking the rich.

But large holders and rich are not necessarily co-terminus. Let's be aware of that.

In terms of the questions:  I think I'm pretty much in favor of a extra extra small category. I'm not in favor of the super X large because of the reasons I just mentioned.

John Curran:  I didn't put it down here, but I guess I'll ask:  Regarding the IPv6 shift?

Michael Sinatra:  The IPv6 shift, I'm in favor of it.

John Curran:  If anyone wants to speak for or against that, they should.

Regarding the legacy. I just want to come back. If you look at the models, you'll see at the very bottom of the model there's a number. Right now it's this 150 number. So legacy holders have a cap on their fees, and a lot of the RSAs that say we can't increase it more than $25 per year, which we fully intend to do, but if you're paying 64,000 but you're capped at $125, it's going to take us a while to get up to 64,000 at an increase of 25 per year.

But it is true we offer favorable fees for the legacy holders with a cap so that there's no real disincentive. A legacy holder who wants the benefits of the RSA and the assurances it provides in terms of rights and so on and so forth won't end up disincentivized to the extent that we maintain this in the schedule.

It is true that even the LRSA fees are scheduled for revision in many of the versions of the RSA.

So center microphone.

Michael Sinatra:  Really quick follow-up. That's the reason that I'm advising people, I can't necessarily advise people to sign an RSA or an LRSA if they're going to be subject some day to these huge fees.

John Curran:  Got it. Center mic, Owen.

Owen DeLong:  I have to go along with Michael on that. I regret having signed the LRSA for blocks when I thought it wouldn't cost me anything and then couple of years later got the big surprise that my fees were being tripled.

I support the triple X small category. I'm neutral to slightly negative on the quad X and 5X large categories. If they produce revenue that we don't need and it's not going to result in lowering the base fee that gets multiplied through the table, I don't see any point in doing that.

And I actually would like to propose a slight modification to the up-front thing for the transfers. I think that making it possible to pay the transfer fee up front and sending out the invoice up front makes sense.

But accepting that it may not get paid at all unless the transfer gets completed and/or that it may get paid sometime between zero and the complete close of escrow, or whatever you call it, at the end of the transfer settlement, whatever that process is, would make a lot more sense.

Because I do understand from some of the brokers that I've been talking to that having to wait for this invoice to come and then deal with it just creates unnecessary delays in the process that are painful for them, painful for their customers, and just unnecessarily complicate the process.

So being able to get invoiced up front and pay when you want makes a lot of sense to me.

John Curran:  Microphone 1. Microphone 1, then remote.

Celeste Anderson:  Celeste Anderson, USC. I believe there should be a small category and that if people could choose between paying that fee or the total of their resources, whichever is less, makes sense, because that just makes sense for the small people.

I'm not necessarily up with charging large categories just for the sake of it. If you don't need the revenue, you shouldn't be recovering it. And I do think you need a number of what we really have for the operating so that that could be put into the fee structure.

And then for the transfers, I think it behooves ARIN to figure out a streamlined, easy way to do it to reduce your operational costs, and that's what you should do to make your costs less for the transfers.

As people who run operations, we're continually looking at how we can make it easier for our end-users to get services from us, and that's where I would suggest you make the changes.

John Curran:  Paul wants to respond on that point.

Paul Andersen:  We tried to simplify because, you know – from the fee report, several scenarios, and I just want to talk about this revenue. I think, at least from my perspective, the way we've looked at fees is we want to collect enough fees to cover the expenses that were occurring.

And if that materially changes – down, up – we would adjust the schedule. And if we were to adjust that schedule, one of the first things we'd do is if it was producing severe excess, we would probably move the model down. Many of them are just a step up with doubling the fee, double the fee, so we'd probably lower it.

The only reason we didn't change it for that is to give a bit of comparison. The other reason we don't change it every year is we realize we try and balance making sure the fees are recovering equitably, at the same time we realize people don't like the number changing every year for accounting purposes. So we try to smooth it out that way.

Most of the excess that we've generated, in fact, over the years has always been from our investment, which we generally budgeted very tightly, and we've always tried to make sure that the fees are matching the operational expenses closely.

I don't want to give a suggestion that there's some desire to collect more revenue, because I think that's quite false.

Celeste Anderson:  So I could suggest that occasionally you could give a rebate to people and it doesn't change the fee structure, but you could one year say we operated very efficiently and the members get something back.

John Curran:  Interesting. Regarding the automation, I just wanted to comment. We have done actually quite a bit of automation for transfers and we're doing – you'll see in the report to come we're doing some of the last bit of handling that automation now.

Unfortunately for the transfers, our hold-up isn't actually ARIN processes. It's documentation from the customers. And it's an iterative process because customers come to us, want to transfer a block, and they don't have a clear set of paperwork. And we have to go iterative with them to say, well, we really need to see when you acquired that company. And now we really need to see what was transferred. And it takes a while to get there.

So I do agree. I appreciate the automation. In fact, we'll see a talk on software automation later today that we've done.

But I do believe transfers are going to be a labor-intensive process only because often they're effectively title work, and it's not a short process.

We have a remote participant. Go ahead.

Andrew Dul:  Remote participant. Marla Azinger from Frontier Communication writes:  I don't support raising the fees on holders just because they have large holdings. Not all companies have deep pockets.

John Curran:  Okay. I'm going to go to Microphone 3.

Matthew Kaufman:  Matthew Kaufman, most definitely not speaking for Microsoft on this topic. I am part of a community network that has a microwave backbone throughout the San Francisco and Monterey Bay Area. We operate using a fairly large amount of IPv4 legacy resources that we hold. And we have not deployed IPv6 because there's no way to do that and pay the same fees we're paying for our legacy IPv4 space.

The fact is that $250 a year is a lot of money to this group. And enough v6 space for us to operate would be even more than that.

So we simply haven't deployed. And that's quite unfortunate, because it's a large group of early adopters who otherwise would be learning a bunch of interesting things about this.

On the raising fees for large and others, I'm not supportive of any things that increase ARIN's revenue. I think that a lot of what ARIN does could be done by two guys in a database server, and if we could cut the revenue and the expenses both in half, that would be great, or maybe 90 percent would be even better.

Obviously organizations do tend to grow as their available revenue grows, and that's exactly what's happened here in my opinion.

And on transfer, I think the way we simplify transfer is we change – we make transfers cheaper for you to process by getting rid of things like needs assessment.

John Curran:  I want to comment on that last one. The problem is not necessarily the policy, it's whether the party representing themselves for the transfer actually is the party that has the right to transfer.

That will not go away regardless of the policy aspects.

Center rear microphone.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. I'm not in support of the large proposals. The small ones – there's some policy issues, and this has all gotten tied up in the policy and the fees. And we've gone back and forth and back and forth, and I'm still not clear where we're going to end up.

It still looks like we're going to end up with size categories that we don't have policy to allocate, which isn't effective in my opinion.

John Curran:  So that's an interesting point. I will say it has been ARIN's – the Finance Committee and the Board has supported a fee schedule that will allow us, regardless of what someone has for holdings, to accurately know what their fees are.

When you have a fee that only – a schedule that only covers anticipated holdings, then there's a lot of edge cases the community doesn't see. And if that happens, we don't know what to bill.

If a judge should somehow someday order the transfer of a /32, I'd like a fee schedule that knows what I need to bill that person even though you never made policy.

Now, the last time a judge tried that, we ended up making them educated. But the fee schedule needs to be able to accommodate everything that could be held, even if the policy doesn't allocate that.

Microphone 1.

Brandon Ross:  Brandon Ross, Network Utility Force. I guess this comment segues nicely with that, one, and I think you know what I'm going to say, but with the v6 shift and then in addition of the extra small category, if I can have a clarification, I mean, that we would once again be in a situation where you would not be able to have any IPv6 space because of the minimum allocation size in the smallest fee category. Do I have that right?

John Curran:  Quite frankly, it depends on what the AC sets for IPv6 allocation policy.

Brandon Ross:  But right now it's /36, right?

John Curran:  No. For an end-user it's much smaller.

Brandon Ross:  But for an ISP at least.

John Curran:  For an ISP it's whatever the AC sets. You're saying you wish the AC would set smaller sizes?

Brandon Ross:  I am saying that I'm against any situation altogether where in order to get IPv6 space is the smallest category, you have to pay more.

I realize that this is a multi-dimensional problem between the AC and the Board, and I'm asking all of you to like work together somehow to make that stop. Because just like the community networks I've heard before, and I commented here before, I have a lot of small customers that continually tell me:  I would love to deploy IPv6, but that $500 a year, or maybe it's 250 a year, whatever it is, it's preventing me from getting the address space.

John Curran:  The IPv6 category shift will make it cheaper for them. It will go from a thousand to 500. The question is if the AC – if we have a category that's XXXX small that only end-users ended up paying in, would there be pressure to allow ISPs to request smaller? Because some people feel the ISPs requesting smaller will result in them doing sub allocations that are smaller.

So it's in your best interest to pay more. We know better than you what you should be allocating. The fact that you want to pay 250 and get an IPv6 address block, if that means your sub allocations are too small, the wisdom of the community will be that you pay more and get a bigger block. That is not a fee schedule issue; that is the fact that the community is imparting wisdom on you and your wallet should pay. Got it?

Brandon Ross:  No, I understand that. If that is how we're arriving there, then I'll have to say I'm against the XXX small category because it creates a situation where we have to have that debate. So if that's the case, then –

John Curran:  It's actually created by the policy minimum allocation. Let's be very clear there.

Brandon Ross:  Fair enough.

John Curran:  You had a comment?

Kevin Blumberg:  Kevin Blumberg. I just wanted to clarify. The community has had a big issue with the fact that v6 ISP automatically jumped you to, I guess, in the current fee schedule $2,000 a month as a small.

And one of the things that was asked for was for some relief either in policy or in fee. And the community has said in policy we don't want ISPs using smaller blocks because they're going to not give to their customers properly.

In this fee schedule – correct me if I'm wrong – a /32 would stay within the extra small. If all you had was a 32, it is now included in an extra small, which would keep the cost down, which alleviates some of the concerns that have been going on within the community that a 32 should not penalize you over v4.

I think if they're smaller, that's a different story. But the key concern was just to get v6 was now $2,000 a year for an ISP, and this would at least drop it down one category.

But just to finish that off and then I'm done, if we help out a huge segment in terms of the numbers of people, thousand, 2,000 people, that's great. I'm really in support of that. But something has to give somewhere.

Either we're telling ARIN to cut services or we're saying no, one extra large or XX large, whatever it is, category is needed to pay for that.

So we can't have our cake and eat it too.

Brandon Ross:  Well, there is one other solution, which is get rid of the smaller fee categories entirely. While I'm not saying that I would necessarily prefer for my smaller providers to all have to pay 2,000 a month, regardless if they have v6 or not, I think that's a better situation for the Internet than it is to have these smaller providers that feel like they can't get IPv6 space because it costs them too much. If they have to pay two grand anyway, then that changes that whole calculation.

I don't like that solution to the problem. If that's the only one, though, I'm more in favor of that than adding a triple X one.

John Curran:  There is a proposal to shift the IPv6 categories, four, and that will make, for someone who would have been small, they're extra small. For someone who was XX small, X small, they would now be XX smalls.

So people can now get a /30 or a /36 and pay half as much as before. That enables someone who is an ISP for v4 to get v6 and not see an increase in many cases.

The question is whether or not we would open up an XX small, which would allow someone who is, for example, an end-user to pay. And, yes, it would be on the fee schedule, but it would be up to the AC whether or not someone was allowed to go and get v6 and only pay 250.

That's a great question, but that's a policy question.

Vint Cerf:  Small interrupt just to note the time. We may want to close the queues.

John Curran:  Thank you. I was about to do the same.

We are approaching lunch. I'm going to close the queues now, but I'll keep taking questions. Center front.

Matt Petach:  Matt Petach in this case speaking only for myself because, well, I don't hate my company that badly.

I totally support the notion of the triple X small category, Proposal 1. I do note, the previous questioner, I think the bit shift for v6 is well warranted. It's not clear that that's what you're talking about, but I would strongly encourage that.

I will note that including the triple X small category is likely to shift the demographic of the people speaking up and voting at ARIN meetings.

So for people who are concerned about community support and community voice being heard, I think this will be a very good thing.

I do actually also support Question 1 on the quadruple X and quintuple X, which is why I'm not speaking for my employer, sorry.

I do like the fairness. I also will speak somewhat for my employer on the notion of transfers. Quarter-by-quarter billing is actually something that's kind of hard to deal with when things stretch longer. So being able to pay up front and say "I have purchase request approval for this; let me give it to you now" would be very good.

Last piece for it would be that I feel like in all the discussions we're having here there is not a very good sense of transparency in how much does it actually cost to run ARIN.

And when we look at the $16 million and say, well, the committee has decided that that's an adequate number to keep us going forward, we're all very unsatisfied because that's very hand wavy. It may only be costing ARIN $3 million to run and the other $13 million is going into a massive slush fund somewhere.

So could we – not saying that's true at all, but I think it would help people feel a lot better if we actually saw here's the actual costs and then this is the amount that's being put forward into the war chest.

Paul Andersen:  If I may, I would encourage the expense side of this discussion preferably tomorrow during – I'll be presenting as Treasurer, and I would welcome any comments. And I'll double-check to make sure we have it in there, but we generally always put on that presentation a breakdown that we think makes sense of where we're spending the money. We welcome the feedback.

I know the gentlemen earlier said we should be spending less. I think we continually take the input we get from these meetings on the things you ask us to do and we try to do them. And they come with a cost, and we try to do it in the most cost-effective base. This is how do we recover that. We also publish, of course, all those costs on the website.

Just on one last point, because I guess I wasn't clear earlier, I'm not advocating that any of these proposals should increase the amount of revenue that we do today. I think whatever model, if we change the model, we would first look at and adjust the steps accordingly to make sure that it's recovering the current fees.

As time passes on and people, because we can't predict where the numbers will – we can project it will be more in one category and less – we'll have to keep adjusting that.

And as the Fin Com – as my colleagues, Bill Woodcock, who I see lining up, and Aaron Hughes – every year we go over the budget with John, and it's a very thorough analysis. And we will continue to make sure that costs are being spent effectively. But we welcome discussion.

If there's more detail that we're not providing already on the website or in the presentation, I'll be happy to accommodate.

Unidentified speaker:  Thank you, Paul. I actually had one tiny last point, which is as a community and an organization, please, for the love of God, can we get the size categories for allocations and fees in alignment? Because I do feel like we're a rubber band stretching back and forth on fees versus allocations. Please. Thank you.

John Curran:  Regarding the costs, the discussion has been – the fee discussion was intentionally made revenue neutral so we could talk about the merits of various models.

But we have presented ARIN's budget every year. It's on the website. We have talked about cost breakdown, and we can continue to do so.

We've reduced our fees across the Board five times in ARIN's history. If we end up overrecovering, we can keep reducing. So it's not a problem there.

All right. Patrick.

Patrick Gilmore:  Patrick Gilmore speaking for myself. I fully support No. 1. Lots of people have said why. I don't know enough whether to support No. 1.2, I don't know, the second No. 1.

But regarding the transfers and paying up front, I'm going to disagree with some of the people that were here first. I think nuisances can get ridiculous, and I think they will get way out of hand as you've run out and things are going to get bad in the near future.

And even a tiny fee – we saw this in domain names, we saw this in lots of places, even a tiny fee will stop people from automatically putting in literally millions of requests.

So I'm 100 percent in favor of doing something up front. Now it can be a nuisance, it could be 20 bucks, and it could be refundable at the end if you don't get it. I don't care how you do it. But put something in there so people cannot programmatically ask for lots and lots of changes and overwhelm anything you have.

And, finally, for – I'm not going to go over everything everybody else said, but I'd like to put my support behind if I have v4 and it costs me more to go to v6, that's broken and needs to be fixed.

John Curran:  Center back.

Bill Woodcock:  Bill Woodcock, ARIN Board. So I have opinions on all this, and I'm not going to bother you all with them. What I would like to do is talk about the mode of the conversation, because money is something that is very close to everyone's core issues. Close to your wallet.

So everybody cares about it. Everyone has a very personal point of view. And so we tend to wind up in a conversation about many, many, many specific cases. Everyone looks at this from the point of view of their specific case.

But as a community and as an organization it works much better if we go from general principles rather than a zillion specific cases.

So each of these size categories is in effect a specific case. And we keep talking about them as specific cases and should we add a few more specific cases.

In figuring out the fee structure, what we've tried to do is essentially an algorithmic thing, where it's not a completely sliding scale. It creates buckets.

But when we say that there will be nothing smaller than XX small and nothing larger than XX large, what that's doing is it's artificially truncating the outputs of that algorithm such that no matter how small you are, you always get billed more, if you're below a certain threshold, right?

And I think we'd all agree that that's both not fair and not necessary for the organization. Right?

So if somebody is using a microscopic amount, then probably we should be charging them less than someone who is using more.

Now, obviously there are questions about transaction costs and does them coming and showing up at the meeting and eating snacks cost something, of course, all that's true. And we can get into a transaction-based model instead, if you guys like. But that's the conversation that people haven't wanted to have in the past.

So at the other end of the spectrum, if we say nobody, regardless of how much space they have, how many times they show up here, you know, how much they speak at the mic, they never get billed more than a certain amount, that is also truncating the output of this algorithm.

And that's also an unfairness. It's saying that somebody can have as much as they can possibly justify without ever paying more.

So I think rather than arguing over these specific cases, I think if we back off to the general principle that we have a budget, which is a separate conversation, and we need to meet that budget, and we have an algorithm over which the revenue needs are spread across the people using the services, and not go to a zillion special cases, we'll be better off.

Sorry. That took longer than I was intending, but I think I got the point across.

John Curran:  I ask people to be brief because we're in lunchtime. I also note the queues are closed.

Joseph Provo:  Joe Provo, Google, not speaking for Google, speaking for myself. I'll be brief. Categories, not going to rehash. I think good points were made by Mike, Marla, and Brandon.

The only other comment is that something – all the steps towards fee normalization I think also will imply inclusiveness because this is way too complicated for most regular people.

In terms of transfer, Patrick hit on something that was relevant, but I'd like to ask staff. I'm not surprised that there's nuisance filings. Could we have some numbers behind the nuisance filings? And then maybe some opinions will change.

I'd like to see instead of just a small nuisance up front, just call it a filing fee. Shave a tiny piece off the existing fee, call it a filing fee, and be done with it.

John Curran:  Last one.

Matt Pounsett:  Matt Pounsett speaking for myself here. I agree with a lot what has been said recently on transfers; that paying something up front is important, I think, for all that.

On the fee structure, actually Bill's given me a better way to frame the things I was going to talk about. I like the idea that the algorithm should cover the full range. And so expanding to the top and bottom as much as is logical is the way to do it. I don't mind that the very large organizations pay more, as long as that equates to less from the smaller ones.

That said, though, it seems to have always been believed there's a very strong correlation between the size of the resource holdings and operational load on ARIN, which is mostly true for ISPs but not so true for end-users, and particularly not true for some very large end-users.

And so I unfortunately wasn't here for the discussion in Baltimore. Maybe I missed this. But maybe it's actually time for discussion of a transactional-based fee structure.

John Curran:  All right. Hasn't been a lot of support for it. Okay. Thank you. We're now moving. I appreciate all the feedback.

If you look around the room, some folks have a black "Board member" stripe on their badge. I'm seeing some of them peel it off and hide it now. No, no, don't do that. They're the ones who ultimately end up adopting fees. And so you find them, talk to them during breaks. We also have an open mic at the end of the day. Another time to pick this up.

I'd like to move into lunch because we're running late. We're going to resume here at 1:30. Okay? 1:30. And we'll have the election procedures and candidate speeches.

So thank you, everyone. Take your – I know the slide coming that says take your belongings, because your address holdings are safe, your belongings are not. Come on.

Remember to tweet if you want to win a gift certificate, ARIN36 or get6.

Lunch table topics. There are four lunch tables out there:  One on 2015 1 and 4, one out of Zane region use, one on life after IPv4 exhaustion, and one on routability of Section 4.10 micro assignments.

Take your valuables with you. It is not locked. There is no security. 1:30 with candidate speeches. Please come back on time.

 (Lunch break 12:21 p.m.)

ARIN Board, Advisory Council, and NRO NC Election Procedures and Candidate Speeches

John Curran:  We are now going to have a presentation regarding the Council election procedures, and then we're going to follow that up with candidate speeches.

Couple of things. Remember to turn in your ticket, and in the afternoon break to get your T-shirt.

Candidate procedures, election speeches. And then if we have time, we'll do – Nate will give a software development update.

We do have a policy block coming up with just a few policies in there. We'll do that after the software development update.

So the head table is myself, our jabber scribe – no one else is up here because the candidates are coming up to speak – Susan, who will be doing the introduction to the procedures.

Go ahead, Susan.

Susan Hamlin:  Thank you, John. Good afternoon, everybody. I'm Susan Hamlin, and I'm going to walk you all briefly through how to vote in the elections.

And at 3:00 p.m. today elections open for ARIN member organization voting contacts for the Board of Trustees, ARIN Advisory Council, and NRO Number Council election.

So at 3:00 p.m. today – first of all, how many of you all in the room are the voting contact for your organization? Great. And how many of you are sad that you'll never be called a DMR again?

Okay. So we made a few changes, and that was one of them. And from now on you all are going to be called voting contacts. It's much easier to explain.

And also we made a change in the eligibility rules for emails. So no longer does your email have to have the domain name of your organization. And that had a positive impact of making approximately 500 member organizations now eligible to vote due to the voting contact they had on record.

Okay. So you're eligible to vote because you were a member on record as of the cut-off, August 24th; you had the requisite email on record; and your organization was in good standing, meaning it had no outstanding invoices.

So the elections open today, followed by speeches, which will be available online tomorrow. Voting closes Friday, the 16th, at 3:00 p.m. And winners will be announced the following week, no later than the 23rd, but I expect it will be much earlier.

Okay. So how do you vote? There are two ways you will vote. And you will each receive an email explaining how you will vote. If you have an ARIN Online account and a web-user log-in that matches your voting contact email, you will vote through ARIN Online.

The email you receive will direct you to log in to ARIN Online, step one there. And then you will go to the election headquarters page, participating elections, and when you're logged in you'll see a Vote Now button.

You click on that and that will bring you to the ballot. If you are a voting contact without an ARIN Online account, or you are a NANOG and ARIN meeting attendee but not a voting contact, meeting attendees received emails on Monday to vote in just the NRO NC election, and that email provided a URL at the bottom for you to exercise that ballot.

If you're a voting contact for ARIN and you will receive this email this afternoon, if you click on that URL, it will take you to the ballot, and the ballot will look something like this. And you'll vote first for the Board of Trustees and you can select up to two candidates for the Board. Make your submit your vote.

And that will bring you to the page for the ARIN Advisory Council election. Select up to five candidates and submit your vote. And it will bring you to the NRO Number Council election, where you can select one candidate and submit your vote.

Any questions? After you've submitted your vote, you'll come to this confirmation page. You'll see there in blue, if you click there it will show you your vote receipt and you'll also be sent an email.

And the email will look something like this. And you can verify that the system processed your vote correctly. Okay. The other part of this is some voting contacts represent more than one member organization. Thus, your voting weight is more than one.

Every ARIN member organization, regardless of size, has one vote. But if you're representing more, your vote weight will be the total number of organizations you're representing.

So this slide will illustrate when you open the ballot, it will show your total weight up there at the top.

If you wish to vote differently on behalf of some organizations, you can adjust your weight accordingly and go through the process each time until you've utilized your total weight count.

This is the same process we've used last year. And select your candidate. Submit your vote.

Any questions? I think it's pretty straightforward. There's an election help desk out in the hallway. I'll be there at breaks, either at lunch – you should be receiving your email shortly after 3:00 today.

I'm also in the room. If you have a voting issue, you can also send an email to info@arin.net, and myself and my staff will be monitoring that, and we're here to help you.

Any questions? Okay. I'm going to turn it over to John for the candidate speeches.

John Curran:  Thank you, Susan. Okay.

First up the candidates for the Number Resource Organization Council. Louie Lee and Tim McGinnis. We'll have Louie come up. Louie, come on up.

Candidate Speeches

Louie Lee:  Hello, everyone, I'm Louie Lee and this is Louie's hat. The only real update I have from my online profile since I filled it out previously is that I will be starting a new position at Google Fiber. I will be the numbers administrator which will actually bring my employment much closer to the work at ARIN and ICANN than my previous employer at Equinix. My projects at Equinix lately had been more internal-facing than production-facing, customer-facing projects.

So I think this is a very good move for both myself and for serving the community. So please vote, and thank you for your support.

John Curran:  Unfortunately, we do not have Tim McGinnis here. So we have a video from him. And they'll bring it up in a moment.

Tim McGinnis (Via video):  Good morning, everyone. Tim McGinnis here to talk about my candidacy for the NRO NC/ASO AC role. I understand that you have a choice between two clueful candidates, and I put my hand up for the job in case the incumbents didn't run again. I wanted to make sure that the community had at least one person with a clue.

And my clue comes from over a decade of experience in Internet resource distribution, both names and numbers. But the numbers love me. I'm surging with the numbers, as they say.

Anyway, I've worked on three continents in this arena, and I know the ASO role and the policy processes, the people inside ICANN.

So rest assured no matter who you vote for, you'll have someone with good clue doing the job. The only differentiator I can offer you between the incumbent and myself is that I have more international experience, having done this in Africa, North America, and Europe.

So at the moment, Louie, who is Chair of the NRO NC, is doing a great job and is well liked. So I don't really see a reason to change horses in midstream. But if you're in a kick-the-bums-out mood, I would appreciate your support. Thank you.

(Applause.)

John Curran:  Okay. Next up we'll now move on to the ARIN Advisory Council, ARIN AC. And the list of candidates is right here.

So we have Dan Alexander, who is in the room. Dan, if you want to come up and say a few words.

Dan Alexander:  I'll keep this short because we all have our questionnaires out on the website, so you can get a good feel for some of our opinions.

I do want to thank everyone for the years I have been able to serve. I've been doing this for a while. And I absolutely appreciate the opportunity that you all have provided me.

If I were to list some of the top goals, I think one of the things that we've really been pushing at and that I want to continue working on is simplification of the Policy Manual because we all know this has been growing like a weed for many years. I'd like to rewrite this thing from the ground up, and that's going to take a fair amount of work.

But the other thing I want to continue working on is my role currently serving as the Chair, because my hat always goes off to John Sweeting, who came before me and really laid the groundwork for a stable AC operating as a group.

And I kind of – hopefully I'd like to think I continued that tradition. I really want to make sure that a plan is put in place so I can hand that off to the next Chair and keep the machine rolling smooth.

So really appreciate your consideration one last time. Thanks.

(Applause.)

John Curran:  Next up is Joshua David Breeds. I don't believe Joshua's here. Joshua, are you hiding somewhere? He did not pick up his packet.

So he's not here but his qualifications are on the screen:  ARIN member since 2011; founder and manager director of Servedby the Net LLC, a cloud services provider; and the primary POC for a new ISP unique perspective that he would like to share as an AC representative.

Okay. Next we have David Huberman, and he is here.

David Huberman:  I'm David Huberman. I'm serving on my first year on the Advisory Council on a one-year term. This is my tenth month on the AC. I'm very passionate about ARIN and policy. I'm enjoying the work I'm doing on the AC. I feel like I'm part of a very productive, very congenial team that's working very well together, and I would really appreciate your vote so I can continue this work and continue being part of this great team over the next three years.

Thank you.

(Applause.)

John Curran:  Next up we have Adrian Johnson. I also do not believe he's present. His qualifications are on the screen and online:  Senior network engineering role at a vendor and ISP space, both dealing with allocation and management of IPv4 and IPv6 space, from a business user's point of view. A newcomer to the ARIN Policy Process.

Next, we have Amy Beth Potter. I know she's here. Amy.

Amy Potter:  Hi guys. I'm Amy Potter. I'm an IPv4 broker. So I have a really interesting, unique perspective on the IPv4 transfer market and the transfer policies.

I work with a variety of types and sizes of organizations to get space through ARIN and RIPE and APNIC and transfer between the regions.

So I get to see how these policies are playing out, how they're affecting different sizes and types of companies, and how they're affecting the market, pricing, and just the cost of getting a transaction done even apart from the price that you're paying for the asset.

I think that that experience would be really useful to the AC as we're developing new transfer policies. So vote for me. Thanks.

(Applause.)

John Curran:  Next candidate for the ARIN AC, Rob Seastrom. R.S. is right here.

Rob Seastrom:  Hi, I'm Rob Seastrom. I had some prepared stuff to read from, but I'm just going to go without it.

I've been on the AC for 12 years, and I wouldn't be standing up here if I didn't want to be on the AC again.

I work for Time Warner Cable, but that's just my day job. I do other important stuff for the community and for smaller groups of folks.

I'm one of the people who DNSSEC assigns the root. I run little friends and family colocation facility. I'm sensitive to the needs of big players, small players, unusual players.

Used to be a TLD operator. We've worked for a number of years to avoid draining the free pool in any kind of unfair or precipitous sort of way.

We put a lot of policy in there. Now we have a new challenge, which is get rid of the stuff that makes ARIN seem unapproachable, the policy that makes ARIN confusing to deal with.

I would like you to join me in submitting policy proposals wherever you see a need to simplify and streamline the community's interaction with ARIN.

And I would like your vote for another term on the AC. Thank you.

(Applause.)

John Curran:  Next candidate, John Springer. John's coming up.

John Springer:  Good afternoon, everyone. I'm John Springer. I'm just finishing up my first three-year term on the AC. I don't know how many of you were up here three years ago when I volunteered for this. But at the time I expressed admiration for the members of the Advisory Council and the amount of work that they do and volunteered to do that.

Little did I know. So as a rookie completing my first term I thought that you are probably owed a little bit of an account of what I've been up to.

One of the things that the AC does is participate in ARIN's outreach efforts. As a result of that, I've been to several ARIN on the Road events in less-traveled parts of the country – Portland, Oregon; Madison, Wisconsin; Helena, Montana. I spent a very interesting week at CES in Las Vegas this year. Wow.

Members of the AC take a hand at mentoring fellows that come to these events, and I've had the very great privilege of acting as a mentor to a couple of guys from Jamaica, a gal from Vancouver Island, Canada, and a fellow here today from outside of Chicago.

We also do a lot of shepherding work on policy proposals. Over the last three years I've been a secondary shepherd on four proposals, two of which have been adopted, one was abandoned, and one is under discussion today.

I've been the primary shepherd on three proposals – one of which was adopted, one is under discussion, and one, if you've been paying attention, got abandoned to great fanfare.

I'd like to thank you for allowing me to do this work for you. I feel it's very important. I'd like to do it again. If you'd like for me to do that, vote for me. Thanks.

(Applause.)

John Curran:  Now we'll move on to the Board of Trustees candidates. First one is Paul Andersen.

Paul Andersen:  Thank you, John. As most of you know, I am Paul Andersen, but for those of you who are new and might not, by day I run a service provider based in Toronto, Canada, and I've also been very active in the service-provider community for about 20-odd years, including Chairing the Toronto Internet Exchange and the, and the slide has the rest.

And I've been involved in ARIN for many years and have been fortunate to serve both as the Vice Chair and the Treasurer recently, and I'm proud of the accomplishments and progress we've made together.

As Treasurer, in the last bit, I've worked with the team to ensure strong financial position, I hope, for the organization. That includes that we've been able to build reasonably healthy reserves and a steady stream of revenue, and we've done what we can to make sure and keep the expenses in check.

We managed to accomplish that recently while we conducted and implemented the first modernization of ARIN's fees, including fee reductions for many members in the last change.

When it comes to the Board itself, as ARIN is a member-based organization, I believe in transparency in the Board activities, and many have come and spoken to me the importance of that.

In that regard, I think we've made great progress with increased transparency information. The Board now publishes the agendas in advance. The minutes, I hope, are more fulsome and we continue to tweak that. And, where possible, we're now publishing as many documents as we can that we've used for internal deliberations so you can hopefully have some understanding of what made the clock tick.

We've also – and a personal passion of mine has been to see as many operational improvements. And we've been supported at the Board by a great staff, and we've increased wherever possible the way to get feedback from the community and the people who interact with ARIN on a day-to-day basis, from the customer-satisfaction survey – I know Richard's team did – to more forms, the Services Working Group, even to just refined change processes.

We've tried to make sure we listened to the things that are annoying you and not working well and made sure that they're better.

And most importantly what we've done is we've ensured there's sufficient resources to respond to that feedback in a timely manner, and we continue to improve that.

Perhaps one of the best examples of that is the significant increase that the Fin Com led with the staff to increase engineering resources to help clear not only the backlog that's been there and I know has been plaguing for some time, but also to make sure we have enough resources to make sure that we don't create a backlog again.

I'm asking for your support so I can serve on the Board for another term, and I'll be a little nostalgic and get into why.

I look around the room, I see so many people over the years who I've gotten to know very well, good friends, and many of you feel like family. Like all families, we have strong disagreements, and I can think of a few issues where things get a little heated even.

But what I love about this community and the organization that supports it is that once the battle is over, we're able to raise a glass or two together, have a laugh, and move on to the next challenge. And it's through those discussions and disagreements that we can build a stronger organization together.

So I believe we're at a critical time. Two weeks ago, as you all know, after careful planning, preparation and communication and more communication and more communication, we finally depleted IPv4 in the region. And how we move forward in a post IPv4 world will require strong leadership.

When I look at it, I think ARIN will become busier before it becomes quieter as many in the industry deal with new reality. We're going to have new organizations coming in who are not familiar with the change. We have new actors, and ARIN as the organization has to be able to support those, both through education and streamlining, to make sure that we can fulfill those needs of people who are requesting resources, trying to transfer request facilitators, making sure that we can just keep that moving as quickly and as efficiently as possible.

But longer term we are going to be looking at a simpler ARIN, and we need to review where we allocate resources in that reality. As a community and a Board, we're going to have to have discussions about how these meetings work, how the policy process works.

Mike Joseph raised a great item here that we first have to come to agreement on what services we're even providing, and I think that's going to be a great debate we have in the future.

So I think we now more than ever need to carry the knowledge of our past successes and the experiences gained from our mistakes in order to chart that course ahead, and I believe I have that experience.

To be clear, I strongly believe in bringing in new people, new voices, and new perspectives in the community. I see many of you who I have encouraged to join. I'm so grateful for your participation. But right now it's never more important that this Board have a clear vision of the road ahead and be nimble to respond to anything that's thrown our way.

I dearly hope I can play a role in that, shaping the future of our organization. And if given the privilege to serve, I'll continue to work hard, listen, build capacity, and be a strong voice for the values we all share as part of the bottom-up, consensus-based policy.

As many of you know, I'm always happy to discuss. I try to be as accessible as possible. My email and my phone number are right there. Catch me in the hall, catch me offline. I always like to hear your feedback because I hope we can take that feedback, make it a better organization.

With that, it's been a pleasure to serve these years. I'm asking for and I hope I can count on your support. Thank you.

(Applause.)

John Curran:  Next up for the Board of Trustees candidates, Aaron Hughes.

Aaron Hughes:  Hi, good afternoon. That will be hard to follow. My name is Aaron Hughes. For those who don't know me, I'm the president and CEO of 6connect and also a trustee on the Board of ARIN trustees.

I've been an operator for about 20 years and have been participating in ARIN activities for about the past 10. I serve on quite a few boards and quite a few community projects and have a unique position in that my organization works in the space that overlaps with some of what ARIN works in.

I work with people primarily focused on provisioning automation, IP address management, DNS management and integration with lots of other services.

This means that the majority of time I actually fly around the world and attend operator forums, policy forums, peering forums, and I'm constantly in touch with members of the community who face all kinds of challenges.

And a big part of my job is to help solve those challenges. I think that I'm a special case that works really well on the Board, and our existing Board seems to work extremely well together.

One thing that you may not be able to see as a community is that over the past three years we've actually gotten extremely efficient, to the tune of actually probably having meetings cut down by half time, to be able to execute conflict resolution very quickly and to work together very clearly to help inform the community of what we're working on.

I think the only real visible output that you get to see is meeting minutes and strat plans, but I believe that you can probably clearly see that we output a great deal of effort into outreach in this community, and I would like to continue to serve on the ARIN Board.

I would really appreciate your vote. And certainly, just as Paul said, you're more than welcome to grab me and talk to me about anything in the hall. And I try to keep myself accessible as well.

Thank you very much for your time.

(Applause.)

John Curran:  Next candidate for the ARIN Board of Trustees, Sean Kennedy.

Sean Kennedy:  Good afternoon. My name is Sean Kennedy. I'm a candidate up for the Board of Trustees. I am a new candidate. And I read through all the profiles. I think it's great that we have four strong candidates for the Board.

The first statement of support that I saw said:  Now is not the time for change. And I thought about that. And our industry is changing, and it's the job of the Board of Trustees to lead this community through those changes.

Competition is good. So I ask that you look at all four candidates and consider who is the best one, best two to lead this community.

I am a little bit disappointed that just before this meeting the Board of Trustees released or approved the 2016-2017 strategic plan, and the ordering language and priority of that is almost identical to 2015-2016, and to much before. And that's at a time when our industry is changing.

I have been a member of the community for many years. And there's a lot that I don't feel should change. I strongly support and believe in ARIN's mission. The Public Policy process is adaptable to changes in the Internet industry, and I strongly support it, too.

I also support the ARIN staff. They have a wonderful staff, and the Board of Trustees should be up a level and not meddle in the day-to-day operations of the organization.

However, I would challenge the Board of Trustees, and if you elect me I will speak with my trustees, I will speak with the staff, to revisit those priorities for the organization and look at producing a future strategic plan that reflects the changes in the industry and where our priorities should be.

For instance, I think it's time to give more weight to the growth and operation of the Internet and the expansion of IPv6 than the first bullet in the strategic plan, which is conservation of Internet Number Resources.

That was important. We need to do some of that, but we need to move forward and grow this Internet.

I've brought leadership to NANOG on the road over the past two years in my participation in that. And I've brought a lot of energy to that.

I have some ideas about how to engage with the community in different ways, and that community may be growing if new organizations sign the RSA, and I commit myself to participating in that outreach to the community.

I do think that the issue of services is another area where we've been inconsistent. There are cases like RPKI development where the Board, through all of the engineering resources behind RPKI and many other things, fell behind.

There is an increase in engineering staffing right now to support the IRR development, and I think that's better than just weighing down the organization. But I do feel we need a comprehensive approach to services. We need to better engage the community so they deploy those services.

And I think that there could be ways with large projects like the IRR to develop other resources, whether they're contracts, whether it's an open source project that's supported or even things like hack-a-thons to further that project and others.

Likewise, with registration and other things that we need, the individuals that represent the organizations in the community to update Whois, we do have the help desk, but let's set events where there's more resources.

You sit down and you update your Whois. You sit down and go to ARIN on the Road and you get IPv6 addresses. Let's change how we reach out to the community.

So I think to have a strong and relevant ARIN going forward, some change is needed. And I do ask that you vote for me to support you in that change. Thank you.

(Applause.)

John Curran:  Thank you. Next Board of Trustees candidate, Sandy Murphy.

Sandy Murphy:  Hello. My name is Sandra Murphy. I'm a candidate for the Board of Trustees. I forgot that it was a candidacy for the Board of Trustees and I did not arrive in a suit. I notice that all the other gentlemen were aware of that and arrived adequately vested.

I have been a member of ARIN at least since 2006, since that's when I put in a policy proposal. I've been active working in the Internet industry since the 1990s. I started work at the Defense Communications Engineering Center in the ARPANET days in the NCPTPC flag day transition. Anybody under 30 know what that was? No, probably not.

I was very honored to be nominated for this position, because there are some things that I believe are concerns that need to be addressed, and I welcome the opportunity to address those from a position at the Board of Trustees.

The things that I am most concerned about are the dynamic nature of the change of the industry. You've heard that from every one of the other speakers. I looked back through some of the other Board of Trustees' speeches, and as far back as 2009, and as far back as 2009 people were talking about v4 deployment and – I'm sorry, IPv6 deployment and v4 runout. We also have the transfer market now, and these things are going to change the way that the community works and behaves. And we're going to have to adjust our procedures to deal with those.

I'm concerned about the role that ARIN plays in the operation, day-to-day real-time operation, and the Internet.

It's somewhat a culture to say that ARIN should not be involved in that but with the reverse DNS, the IRR, the RPKI. ARIN is in a unique position that only they can play to support that part of the operation of the Internet.

I'm concerned that the Policy Development Process takes a long time. We have been arguing about out of region use for two years. There has to be better ways of settling our process. In a state of change that we're facing, we have to do things quicker than that.

We may need more virtual meetings. We have on-the-road meetings, and I really champion those and the way that the staff has supported those, but those aren't decision meetings.

I believe that the policy consultation and NANOG meetings is very important. That hasn't aided the speed of consensus and decision-making for the Policy Development Process.

I'm concerned about the legacy space. I specifically asked at the last meeting whether there could be an update on the amount of space in ARIN that's legacy space. I had expected that it would change. It had last been presented a couple of years prior. Virtually – very, very small amount of change.

I don't know what we're going to do with approximately 50 percent of the address space and 50 percent of the organizations supported by ARIN that aren't members, that have no agreement and don't have a voice in the process that's supposed to be a bottom-up stakeholder.

And, finally, I'm concerned about communication and the speed of communication and the number of people who actively participate in the process. The PPML list does get rather heated at times. But in as many volunteer organizations I belong to, there are certain people who will speak up all the time. But we're not hearing a widespread voice from the community.

With all the candidates that you're presented with, I'm in no state of illusion that I can point to the fact that I am a better candidate than any of the others. But I ask you, please – I've taken the opportunity to speak to a number of people here about what they want from the Board – consider that carefully and make your decision as to who you vote for with an informed opinion as to what's important to you and what you want the Board to do and who can best bring that about for you.

Thank you very much.

(Applause.)

John Curran:  Thank you. That concludes the presentations of the Number Resource Organization the ARIN Advisory Council and the Board of Trustees nominees. All of these candidates have their bios on the website. You can read their statements of support and their questionnaires they filled out. So I advise you to go to the election center where you can see this information.

We're now going to be right on time. We're going to have Nate Davis come up, our chief operating officer, and give a software development update. Nate, come on up.

SOFTWARE DEVELOPMENT UPDATE

Nate Davis:  Good afternoon. My name is Nate Davis, and I'm Chief Operating Officer for ARIN. And I'm going to be providing a software development update.

The purposes of this update is that, is because of the interest in what engineering works on, we do this report at every meeting to talk about what has been completed and also project what we're planning to do in the future.

So that's the purpose of this update. Topics covered today – I'll talk about the projects that have been completed since the last meeting, the initiatives that we have deployed, influences that occur in the project prioritization process, and lastly talk a little bit about project prioritization itself.

What I reported last meeting, which would be last April, is that the first three bullets that you see there were to be completed or deployed in May.

And I put this up here because I want to confirm that that in fact did take place. The merger and acquisition, 8.2 transfer functionality, RDAP as well as adding links to Whois Query Responses was completed as planned.

Then we have some additional work that we've actually been able to implement since the last meeting. I'm not going to go through these all. But I would point out a couple highlights. The two factor authentication, which was a significant effort for the engineering team to complete, was in fact deployed.

And then also some smaller requests such as showing the abuse contacts by default when you pull up Whois information. And the good news is we even had more things that we were able to complete since the last meeting.

As you can see, we added Whois-RWS RESTful Whois services, and RDAP now being offered over SSL. We've implemented registration services agreement, a new version if you didn't see the announcement yesterday, and some other small enhancements along the way.

So those things have all been completed. As you'll notice, each of them is identified, are associated where appropriate with the ACSP or ARIN Consultation and Suggestion Process number.

ARIN suggestion and consultation process actually captures community input into our organization with regards to nonpolicy-related items.

A lot of those are actually software development suggestions, and those are what we're actually reporting on primarily today so that we can show we're being responsive to those community suggestions.

Some of the upcoming initiatives. During the last report I gave in San Francisco, I mentioned that we had planned to have SWIP Easy done or completed by now.

Actually automating transfers has taken a little bit more time than we expected. And as a result of that, we didn't quite get the SWIP Easy as soon as we wanted to.

We actually aren't quite done with transfers either. So we're looking at doing and focusing on those big efforts before the next meeting. We really need to get transfers completed and automated. It gives us the ability to effectively manage the requests, to report on them, to see trending and to make sure they're being processed correctly within the organization.

SWIP Easy, don't know, we use this term. I don't know how familiar everybody is with SWIP Easy. But it's sort of an ability to report your reassignments into ARIN Whois – excuse me, into ARIN's online functionality, which is a little bit less than scripting but still larger than just the onesies or twosies that you can conduct through ARIN Online.

So it's meant to meet that gap, if you will. And then lastly we're working on the ability to actually deploy software without outages.

And so those are the key things that we're working on between now and the next meeting. So like any organizations, we have a number of things that influence what we work on. And this is a list of those generally in priority order, generally.

Like many organizations, we have many competing priorities and so forth. And we share this with the community to give you some sense of how we determine what we work on from a software engineering perspective.

Again, the Board guidance to staff is that we continue to review and enhance ARIN Online, making significant user interface improvements per user feedback, continuing to automate these functions within ARIN Online that supports policy development and then focus on smaller, community-suggested, customer-facing, high-impact software changes that really they're changes that provide the greatest benefit to the broadest number of users that we have using ARIN Online.

That concludes my presentation, but I'll be happy to take any questions if there are any. Yes, Kevin.

Kevin Blumberg:  Kevin Blumberg, as one of the officers of the AC two factor authentication, thank you, thank you, thank you. I believe I was the second non-staff member to use it. And I'm enjoying it quite well.

It's a great version, 1.0. I'm sure that I'll bring up a version 2.0 at some point. But I have a question – during the election discussion earlier they were talking about logging into ARIN Online.

Is the two factor tied into that for the elections as well?

Nate Davis:  We're using ARIN Online if they elect to use the two factor.

Kevin Blumberg:  If they elect to use two factor then their log-in for the election purposes will also be two factor –

Nate Davis:  Through ARIN Online as opposed to going to big vaults. Any other questions?

(No response.)

Nate Davis:  Thank you very much.

(Applause.)

John Curran:  We find ourselves in an interesting situation now, because I loathe to start policy discussions prior to the agenda, and the agenda says that our policy block begins at 2:40.

So looking briefly ahead to see if there's anything else to be presented, I don't see anything relatively easily unless – Axel, if you're here, Axel, do you want to do the NRO Activities Report a little early?

Axel Pawlik:  A whole day early?

John Curran:  If you would do that, that would be lovely. And I apologize to our staff who has everything queued up in order and now needs to scramble frantically. Need to give them a moment. It's important for us to try to keep the policy block consistent times.

I know people who block off their day just to get on for the policy discussion. Not that they don't want to be with us for the whole day, but if you're remote, you may have other things to do, you may have to talk to your boss or exciting stuff. I try not to start early. No one wants to find out the policy they wanted to comment on was talked about 15 minutes before they started.

We're loading the presentation. Turn it over to Axel.

NRO Activities Report

Axel Pawlik:  Good afternoon. I'm Axel Pawlik. I'm the Managing Director of the RIPE NCC, but that's not why I'm here for. I'm also the Chair of the Number Resource Organization.

I'll talk a little bit about that. The Number Resource Organization wants to be the flagship and global leader for collaborative Internet Number Resource management as a central element of an open, stable, and secure Internet.

If you promised me I couldn't say that aloud without looking at the slide.

So the NRO basically, as you probably know, most of you, is the accumulation of the RIRs working together, and I'm here to report a little bit about what it is that we have been doing over the last couple of months.

So what's the NRO, what's our key focus, some finances, activities.

So like I said, it's the RIRs, a long time ago in 2003 we said, oh, we should get together and organize ourselves a little more consistently. We were I think three at the time, ARIN, APNIC and RIPE NCC. ARIN formed the lightweight not incorporated association with the idea to coordinate among ourselves to look after the Internet number registry system on a more global basis, promote and certainly defend the multi-stakeholder model, the bottom-up industry (indiscernible) policy development process, Internet governance, to coordinate other joint activities and all sorts of terms. Possibly mostly it was outreach and engineering at the time. And to act as a focal point for input into the RIR systems for policies at the time it was the priority there. And of course also within the ICANN framework to fulfill the role of the ASO.

So we started these three RIRs, and of course over time LACNIC and AfriNIC joined us. So ongoing today collaboration among the RIRs, global collaboration, outreach, governance coordination, how do we act together most efficiently in the big wonderful world of Internet governance.

Monitor those discussions, contribute to them and, of course, what work we have been doing quite a bit over the last year is looking at IANA stewardship there as well. Transition of that.

So we have an executive committee in the NRO. I'm the Chair for this year, and those positions all revolve every year. We have Oscar from LACNIC as Secretary, John as the Treasurer. Paul Wilson and Alan Barrett are out there somewhere doing lots of things, but they don't hold any formal position this year.

So we have a Secretariat also that is hosted by LACNIC. And basically that's support for some of the technical facilities there. But also we have an Executive Secretary, German Valdez, and this always confuses me because he's hosted by APNIC, he's working for us but he came from LACNIC.

Vint Cerf:  One big family.

Axel Pawlik:  It is one big family and we have lots of fun. We have couple of coordination groups more topically focused on communications on public affairs, on engineering and on research and services.

So all the major topics the RIRs are doing are covered there.

The finances, we try to keep them relatively contained. Basically we agree to share the joint NRO finances, the cost between the RIRs given to occasionally changing formula. But the costs that we have is travel cost for the ASO AC and for the Executive Secretariat, some communications, conferences, for instance, coordination of the coordinating groups and outreach. Contribution to the IGF. Contribution to ICANN, which is stable for so many years. And now with German on Board as well some staff cost there.

And like I said, the budget is shared, costs are shared proportionally based on registration services revenue within the RIRs. They're all doing slightly different things so we agreed among ourselves to look at registration services as the joint activity that we are doing together, all of us, and base it on that.

Also over the course of the last couple of months we have agreed to set up and fill virtually as a joint RIR stability fund. We think that the global RIR, the global registry is so important and the registry system, that we need to be prepared, in case, like I said, the RIPE NCC gets a little unstable and has sudden need of bit of a cash injection or help in kind that we have something available there.

The NRO has some details about that on the website. We have pledges for slightly over $2 million there. And those are funds that reside in the reserves of the RIRs. They're earmarked but there's no formal commitment to label them anything else in the reserves.

So global information, of course, the NRO organizes itself in a way that it collects information from the RIR, puts them on the website and makes them available so the global statistics there are numbering, updated regularly and in the same old place as they were as last time.

We also – basically for the benefit of people looking at the various policies within the different regions, have this comparative policy overview that also is updated quarterly and tracking what is going on in the regions in terms of number policies.

Also very important, especially around the IANA stewardship transition, is accountability. You might have heard about that. We thought among the RIRs that it probably would not be the dumbest idea if we would look at our own accountability and start to write down what we're doing, how we're doing it.

Also, again, within the various regions, it's done slightly differently. But we have bylaws, regional PDP. Roles of boards in the PDP are not dispute resolution, use of the Whois privacy, budget, activity, obtaining all those things we all need to do, and we do them slightly differently from case to case but we have them documented very nicely there.

I think it's looking rather good. And it's, of course, an ongoing process to keep that up to date to track changes where they are, and to basically present ourselves as well-run, accountable organizations that work for the needs of the members and the wider community.

So more information on this activity. Good. And IANA stewardship transition. John has talked about; I won't go into too much detail. Basically it's all very exciting and we hope to get it done rather quickly now. So it was a very short summary.

There are lots of various different groups there. The CCWG is maybe the most active at this point. All the community groups have the names and numbers, the protocol (indiscernible) have issued their proposals, the CCWG is still laboring on theirs, and our argument has been published there. It's important that this rolls on.

Let's say more traditional Internet governance, that's maybe sort of a funny term. We're doing this for a long time. We're looking forward to go to Brazil, because they have lovely beaches up in the north and it's December and I'll really need a bit of sun then. But also we have a couple of days meeting with the usual suspects in the Internet Governance Forum.

We think by now, after the tenth year of this, it is a very important meeting point for us to go to and to coordinate, not ourselves but with the rest of the world on Internet governance, how we are doing our jobs. How can we contribute to a stable Internet? What are the other participants thinking, just learning about each other?

And that is quite a stable thing and we want it to remain stable. Also for many years we contribute $100,000 every year spread among the RIRs.

We have an NRO booth there. We show ourselves, talk to the people there on Policy Development Process and we host now also a best practice forum on IPv6. Still very important.

Two workshops we have including v6 and RIR open forum, basically things that it's important to keep them flowing, keep them going, because there are new people turning up all the time, and some of the people who have been coming for 10 years, of course, know us a bit better. But it's lots of new people, too. It's good to go, not only because the sun is shining there in December, but it's added benefit.

And that's the end of my little talk here. If you have any questions, I'm –

Vint Cerf:  Axel, this is only related to the Internet Governance Forum, and maybe John will know the answer if you don't and I don't. And that is the decision of the UN, whether to continue the IGF. This was an issue that was supposed to have come up.

Is there a resolution and for what period of time, do you happen to know?

John Curran:  I know it's an open issue that was going to be discussed this week, but as of now I haven't heard of a resolution.

We and many others in the community are recommending its continuance.

Vint Cerf:  Same here.

Axel Pawlik:  Any other discussion?

(No response.)

Axel Pawlik:  Have a lovely afternoon.

(Applause.)

Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

John Curran:  We're still ahead of time, which is amazing. I'm looking for Louie Lee's hat or if Louie Lee's hat isn't here, Louie, one or the other. No, I don't have them. We're actually going to have to start our policy block early. Oh, well, but we're only a few minutes early that's okay. We won't get too far into the discussion.

So we're going to start on our policy track for this afternoon. We're about ten minutes ahead of schedule. And the first policy up is Draft Policy ARIN 2015-3, which is the Remove 30-day Utilization from End-User IPv4 Policy. I will have Dave Farmer of the ARIN AC come up and present.

David Farmer:  So this policy is Remove 30-Day Utilization requirement. The original author was David Huberman, and myself and Leif are the shepherds.

So the policy statement is the end-user policy was intended to provide a year of resources, and there was this 25 percent initial immediate use requirement. That's mostly interpreted as 30 days.

And basically the statement here is that it's unreasonable. I would add maybe that it's even more unreasonable today in light of runout and other changes in the realities of late.

Current policy text is this. Basically we're whacking out that one line. There's a little bit more work to do, minor editorial changes, and then that's what that would be.

Comments. It often takes longer than 30 days to stage equipment and actually do anything in the real world that the numbers are going to be used in.

Growth is not that regimented. It happens in fits and spurts and things like that.

This applies to additional address space requests. This is kind of incompatible with the 80 percent utilization requirement, the two things don't kind of work very well together.

If you are supposed to have – if you're supposed to be getting your addresses when you've used up 80 percent, how are you supposed to immediately use 25 percent of what you've got? That doesn't seem to quite – logic doesn't add up.

In the face of exhaustion, as I mentioned before, there's new realities. ISPs probably aren't giving out addresses as free to their customers as they once were. And so a user can't get the slow-start mechanisms and everything, and the theories behind this originally where you would get your addresses from your ISP at first as an end-user, then maybe as you grew you could then get them from ARIN and then renumber out. But renumbering is an anachronism with runout.

So discussion points. There's been very limited discussion of this. It was presented at the NANOG PPC for the last – in San Francisco. There seems to be general agreement that there's to be an issue to be worked on here. There's been discussion of several possible different solutions. There's disagreement about the right way to go here. Several different ideas have been kicked around.

And there's not enough consensus, there's not enough discussion or support either way, support or opposition to really create a consensus. One option, some highlights from the discussion on PPML at least was, hey, maybe 30 days isn't right. Okay, that probably doesn't make sense, but does 90 days make sense? Do we want to throw out this idea or just make it more realistic.

And then it was some discussion about, hey, do we want to align end-user and ISP policies, might be the better way to go, but then we've got one giant policy and that has never really worked very well. So I would contend that we probably want to do this in bite-sized pieces, and this seems like a reasonable bite.

So staff assessment, basically the staff says, well, particularly with transfers and stuff going out, this is kind of how they interpret things anyway. They're not seeing that it's going to be very applicable. The staff also notes that there's references to RFC 2050 embedded in all this and maybe we should take those out.

Discussion items, that I've just put this to sort of try to get a little discussion going. I need and the AC needs to understand where do we want to go with this? Do we want to remove this? Do we want to do something else? What would that be? And if we do want to do something, do we want to take care of the RFC 2050 thing at the same time, or do we want to just punt and move on and find other things to talk about? And that last part is kind of important. There are a number of other proposals that we're going to do other things, and if we no longer have needs assessments on transfers, then while this is still kind of illogical, it's kind of irrelevant, anyway, so maybe we just don't bother with it.

Paul Andersen:  With that the microphones are open for polite discussion. Hopefully some more on PPML. People are coming. We'll start with the microphone –

Gary Giesen:  I support the policy as written. I agree with all your points – there's no way anyone can deploy 25 percent in 30 days. I haven't done any additional requests, but I've done initial end-user requests and it's almost impossible to meet that threshold. So I support it as written.

Paul Andersen:  Support as written. Thank you, very much. Number two.

Matt Petach:  Matt Petach, Yahoo!. Reading the notes on the problem statement, I support the policy. I think this is a good direction to move in. I question the math, but I think somebody can just fix the math on your problem statements so you aren't trying to have 80 percent utilized and then talk about utilizing the remaining 80 percent, because I wish my IP blocks went to 160 percent. Yes, I support this.

Paul Andersen:  Support. Thank you very much. Microphone No. 1.

Dani Roisman:  Dani Roisman, Softlayer. Just to make sure I understand because I might be missing something, this is a policy that governs how end-users can get on the wait list now. Isn't that the case?

Paul Andersen:  Clarification, please. John.

John Curran:  Because of how the NRPM is written, this applies to how someone's approved for an assignment, which 99.9 percent of the time is going to be on the wait list. It puts them on the wait list until the resources become available. But their assignment is approved, but it also applies to transfers because approval of transfer requires approval of needs assessment per the same criteria.

Dani Roisman:  Ok, so, thank you. Because it seems to remove some of the burden of approval I definitely support this policy.

Paul Andersen:  Support, thank you very much. We got off to a great start there and then we were kind of tiering off in terms of support. Is there anything on the jabber? Seeing none, microphone two.

Matthew Kaufman:  Matthew Kaufman, Microsoft, sure, why not. I support the policy as written. I hope that we remove needs basis and it doesn't matter anymore for transfers.

Paul Andersen:  Thank you for that support. Number one.

Matt Pounsett:  Matt Pounsett, Rightside. I definitely support the goals of the policy. I think we should keep working on this. I'm still trying to piece together a couple of things in my head as to whether it's as written or not. But I absolutely think that the 30-day immediate use is ridiculous. It's unimplementable. That should be at least extended.

Paul Andersen:  So, you're ridiculously in support, yes?

Matt Pounsett:  Yes.

Paul Andersen:  I believe we have a comment from either Kevin or jabber or both.

Kevin Blumberg:  Kevin Blumberg, The Wire. I absolutely support this, I support it as written, and I think that my own view of the history of ARIN is that – and the community, is that the simpler it is, the easier it is just to get it moved and done and I appreciate that. This is going to come up not just with this policy but a number of policies, the concept of, well, we don't need this if this other policy passes.

It's very dangerous, because what we then do is we don't have a good discussion on the policy that's before us, hoping that this other policy will move forward and then we actually get to that other policy later on and find out that nobody likes that policy and stuff that could have really helped the community now get set back six or 12 months.

So I appreciate that the community would like some bigger, omnibus kinds of proposals or more radical proposals. But this could be implemented and done and in place well before some – potentially some of these other policies come along, and I'd like to just keep that in mind.

Paul Andersen:  Thank you, Kevin. Just a reminder that this is Draft Policy and your feedback is important to the AC to be able to decide what they're going to do with the next. I urge you if you have a comment, even if it's just in favor or against, approach the microphone. If you're remote, start typing. Microphone No. 1 please.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. I support the policy as written. What we discovered as we approached runout was that if you couldn't jump-start your assignment process by getting addresses from an upstream you got into this catch-22. This gets rid of the catch-22. We really need to do this, and I support it.

Paul Andersen:  Thank you for support. And Microphone No. 2, at which point we're going to be closing the microphones soon. Did you want to interject?

David Farmer:  Related to the closing, if anybody has any comments on the – whether 2050 should be included, that would be really cool before the mics close.

Paul Andersen:  Yes, please, if you'd like to comment on that, please line up at a microphone.

Paul Andersen:  That got them going again. Number 2 please.

Chris Tacit:  Chris Tacit, ARIN AC. I support it as written. I think we should get rid of extraneous requirements that no longer matter in the face of runout. Hopefully at some point we'll do something a little more wholesale. But until then I think it's important to do what we can a bit at a time as Kevin mentioned. So I support it. Thanks.

Paul Andersen:  Thank you very much. Back to Microphone No. 3.

Gary Giesen:  Gary Giesen, AKN. With regards to the question about RFC 2050, I have to agree with Kevin on doing everything really bite sized because otherwise it's almost impossible to manage. So I would say just remove the 25 percent requirement. We can look at the RFC later.

Paul Andersen:  Thank you for that. We're going to close the microphones at the end of this input. If so, please approach a mic quickly. Number 2.

Matt Petach:  At the end of my input. That's just going to give me an incentive to talk really long so we hit the 2:45 point where we were going to start the discussion for remote people.

Paul Andersen:  That's okay, we've got a bit of time. Take your time.

Matt Petach:  I'll try not to filibuster on this. Matt Petach, Yahoo!. I was going to say there are elements of RFC 2050 that I do think are still relevant in the world today. So wholesale removal of it, I'm not in favor of. I do think that we need to look at taking the relevant portions of it and looking at whether it's worth bringing in. I don't think we should do it as this effort.

I think this is like one of those perfect, like, after-dinner desserts that's just bite sized. You pick it up between two fingers, you pop it in mouth. You don't need utensils, you don't need a plate. There's not a lot to think about, you can end up eating three of them without even thinking about it. This is a perfect, bite-sized policy change. I love it the way it is. 2050? Take it for a separate one.

Paul Andersen:  Next, Vint, and then remote.

Vint Cerf:  I have one question, which is for staff. And the other one with regard to 2050. With regard to staff, putting things into requirements that have to do with tracking when somebody does something feels like a significant burden on the staff to figure out have you done something by X, and what if you didn't, and are we continually polling people to find out whether they've achieved their objectives or not.

It sounds to me like removing this particular time element would make life easier for the staff on top of everything else. John, perhaps you can comment.

John Curran:  So in general we implement the policies that are provided by the community, and when they put something like this in policy, we look at someone and we say:  Please demonstrate – please explain to us how you're going to meet this criteria.

It's sometimes that we don't know, after we've done the assignment 30 days later, we don't go back and get evidence.

But it sets up a circumstance of fraud for Number Resource allocation because it's possible they don't and then someone reports it and then we find ourselves doing a registration review, which is an enormous amount of work. In general, the simpler the policies, the better the registry.

Vint Cerf:  Fair enough. So this falls in the category of if we catch you, there will be consequences.

The other question has to do with 2050. If we do not – I'm not advocating that we should make this more complicated, but if we leave 2050 alone and we leave the reference to it in place, will this particular change contradict 2050 in any way, or are we okay on that score?

Paul Andersen:  Dave, did you want to comment on that?

David Farmer:  Very good question. I'll have to take that back and look. I'll just note, in response to the – a number of the pieces of 2050 have been pulled out and are in, and that was a previous effort. So I do think the current references to 2050 are extraneous. But it's probably best to separate them, and I wouldn't argue with that. But I will take what you're saying here, Vint, into consideration and do a little bit of research and make sure that there's no unintended consequences of leaving it in.

Vint Cerf:  One doesn't want to have a prima facie conflict that someone else could point to say this wasn't fair, et cetera, et cetera.

Paul Andersen:  With that the microphones are cleared and we'll remote queue.

Scott Leibrand:  This is from Marla Azinger. She said:  I don't support removing requirements from end-users if you're not from ISPs. All I keep seeing lately is restrictions removed from end-users.

Paul Andersen:  Okay. David, anything else to add? Otherwise, thank you very much for the presentation. We'll move on to the next proposal.

(Applause.)

John Curran:  Moving right ahead, we now have Draft Policy 2015-8:  Reassignment Records for IPv4 End-Users. I'll invite up Chris Tacit to give the presentation.

DRAFT POLICY ARIN-2015-8: REASSIGNMENT RECORDS FOR IPV4 END-USERS

Chris Tacit:  Hello, everybody. This is a fairly straightforward, simple policy authored by Andrew Dul with me and Owen as shepherds.

So the nexus of this or the reason for this policy being put forward, the proposal, is that end-user organizations presently don't have the ability to create reassignment records in the Number Resource database.

However, a number of uses of such reassignment records have been identified and would increase the overall reliability of the database by allowing them to add relevant details.

Some of the reasons that we might want to do this:  One is geolocation. Another one is to have organizations be able to identify their subsidiaries and affiliates. Another is whether our contractual responsibilities for looking after networks. And another is where organizations are larger and want to break up some of the contact information that they have for their networks into smaller chunks.

So this is the text of the proposal. Would be a new section in the NRPM. And the author's suggesting that implementation could be immediate. The present situation is that there is a distinction between what ISPs and end-users can do. ISPs can create these kinds of records. End-users cannot.

The author correctly identifies that there are a number of implications. There is clearly a service implication for this for enabling this capability for end-users.

There may have to be further policy discussions on how to make sure that actual requirements for reassignment information to be populated are enforced so that, in fact, the database is accurate.

And, of course, the thorny issue of to what extent is this related to the fee structure? Because one of the distinguishing features between ISPs and end-users is this ability. But it has fee implications if you move from one category to the other.

On PPML, there wasn't a lot of discussion. Most of it happened in a few tight days around the end of August.

And basically some of the concerns that were raised were would this be a way for end-users to do an end run around the fee structure, in fact, and so, as a result of that, should it be narrowed so that there would be a requirement for a single common ownership between the address holder and the reassignees.

Another issue is a corollary, or reverse concern, and that is are end-users currently being prevented from switching to ISPs in order to get this capability due to cost implications and how does that affect the accuracy and usefulness of the registry.

If this was to be done, another issue that would have to be addressed is how to make sure that organizations can actually be motivated to keep reassignment records accurate, which isn't addressed specifically here.

So the questions that we have for you today and just to start the discussion is how significant is the demand for end-user reassignment records? What is the cost of not allowing that at the present time? And can this issue even be resolved under the existing fee structure? Now, interestingly, we saw the presentation this morning that puts into play the possibility of a merger of the fee structures for ISPs and end-user. So is the timing right for this now, or should it wait until a new fee structure is in place? With that, I'd invite people to come up.

Paul Andersen:  The microphones are now open. Please approach the microphone.

Number 3 made it first in my estimation. It was close No. 1.

Gary Giesen:  Gary Giesen, AKN. I do not support this policy as written. I think it does an end run around the end-user-versus-ISP distinction.

I would support some limited – for the purposes of geolocation or whatnot, I would support some limited address reassignment information without changing the Org ID. I think if we allow reassignments to just about anyone, then it's going to have an impact either on end-user fees, which I prefer to keep low. Or you're going to start seeing ISPs switching to end-users and reducing ARIN's income to be able to provide services.

Paul Andersen:  So no support. Number one.

Matt Pounsett:  Matt Pounsett, Rightside. I support the goal, but not the policy as written. I like the idea of finding a way to allow end-users to do this sort of thing. I don't think this is the right approach. As was mentioned during the fee policy discussion this morning, part of the reason there's a difference in ISP and end-user fees is the assumed difference in operational load on ARIN. And letting end-users do this white continuing to be treated as end-users from a fee perspective is a bad idea.

I think a better approach, if this is the goal that we want, is just simply allow end-user networks to become ISPs. For the purposes of policy and billing.

And actually having just quickly looked at the NRPM, I may not have had an exhaustive search, but there doesn't seem to be anything preventing that today if an end-user wanted to say I'm going to be an ISP.

Paul Andersen:  So problem statement support. Current implementation as written not support, and you're suggesting this might be an operational issue, which, John, he did raise an interesting question. Is it possible to move from an end-user to an ISP?

I think I know the answer, but I'd like –

John Curran:  We have had organizations move from end-user to ISP to pick up the ability to perform SWIPs. Note, depending on how many resources you're talking about, it can be a substantial fee increase to do so.

Matt Pounsett:  I'm expecting it to be.

John Curran:  The other side of the equation is that the information in the Whois is not just serving the person who is the ARIN customer. It's serving the entire community. So when someone wants to do this, if we force them to move to an ISP fee schedule and they decide not to, we're preventing information that would help everyone, sometimes geolocation information, more accurate law enforcement.

So it's an interesting tradeoff. We have had people make the move. It's only been a handful.

Paul Andersen:  But it does exist today. Thank you. Does that address your questions? Thank you. Number 3.

Michael Joseph:  Mike Joseph, Google. I oppose this policy as written. It is overly broad and it completely blurs the line between ISP and end-user. I also support the concept of limited ability perhaps to SWIP-to-self for end sites. I think there's work that could be done there to add proper geolocation records. Although I'll note that no current geolocation provider uses Whois data for this purpose. But I could see some people want that.

However, there is a difference between ISPs and end sites. We charge different fees. There's different qualifying criteria.

And I keep hearing the argument we should allow end sites to be able to SWIP to whomever because they're already doing it, and I would argue then they're actually an ISP, and whether or not they're SWIPing shouldn't be the determining factor there.

So opposed as written.

Paul Andersen:  Thank you very much. Opposed. Microphone No. 2.

Matt Petach:  Matt Petach, Yahoo!. I actually support this policy even as written because it's so wonderfully overbroad. And I will note that there are indeed people or entities who have made the jump from end-user to ISP, because of that flexibility.

I think this is rather ludicrous that as an entity we've decided to put arbitrary distinction of who can put useful information into a database. I think there's the bigger question of actually merging end-user and ISP and saying this is a little bit of a specious distinction at this point. I think that's beyond the scope of it, but I would say this is a really great first step. So I support it the way it's written.

Paul Andersen:  Thank you, support. Microphone No. 2.

Dani Roisman:  Dani Roisman, Softlayer. I had one technical question. It's been a while since I've run an end-user ORG. Can end-user ORGs specify referral servers, RWhois servers?

Paul Andersen:  David Huberman is nodding yes.

John Curran:  I see David nodding. Okay, Richard, are you here? Do we have end-users doing referral servers?

Paul Andersen:  Let's have an intervention by Richard at Microphone No. 3.

Richard Jimmerson:  End-users can put IN-ADDR on their parent direct assignment block from ARIN. They can't create reassignments and they can't create delegations.

John Curran:  Question is RWhois.

Paul Andersen:  Can they add an RWhois referral?

Richard Jimmerson:  They could put in the comments of the registration –

John Curran:  I don't believe we have parties who are end-users who have RWhois service. David?

David Huberman:  RWhois is an attribute of the Org ID. Org ID is agnostic to resource holdings. So any organization –

John Curran:  I understand in the schema it's supported. I don't know if we have anyone who has asked to do it, and I don't know whether our procedures would allow someone to set it. Meaning, we associate that presently with the ability to SWIP. And if we don't let you SWIP, we wouldn't be putting that tag on even if you asked for it.

Paul Andersen:  Not talking about SWIP. We're talking about being able to specify –

John Curran:  It's possible to put there. The point is we distinguish that when someone says I want to add an RWhois server if you're not an ISP. I don't believe we've ever had someone said it. We'll need to go look.

Richard Jimmerson:  We'll need to go look at that. There's nothing that prevents an organization from setting up an RWhois server. If they went and put that on a comment on their Whois record or something, that might be something we didn't catch. We'll have to look and see.

John Curran:  This is the essential question, folks. We have a situation where even though people have information that serves everyone, we treat end-users different regarding what level of information they can have. That may be the desired output. It may not be, but you really have to tell us one way or the other.

Paul Andersen:  We also charge them significantly differently too. Microphone one.

Dani Roisman:  So my follow-up suggestion, because I disagree with the policy because I believe that one of the additional services you get as an ISP is the ability to continue to add to the size of the ARIN database, and that's part of the fees that we're paying.

So I would recommend actually that as a compromise, if an end-user does want to provide publicly visible, more specific information, the compromise would be to allow them to add an RWhois referral.

Paul Andersen:  Thank you. Did you want to ask a follow-up, Chris?

Chris Tacit:  I would be interested in knowing from the community if the fee equation was taken out – just assume that wasn't an issue – to what extent do people believe this is desirable. After all, we do have an interest in increasing the accuracy of the database and it's utility. And perhaps that's even more important now than it has been in the past. So if people could also comment on that, I think it would be useful guidance.

Paul Andersen:  Chris is asking if people could comment in the abstract, putting aside fees, what do you think of equalizing the two? Microphone 1, you want to comment again?

Dani Roisman:  Yes. So is the question if the fee schedule was the same for end-users versus ISPs?

Paul Andersen:  Yeah.

Dani Roisman:  At that point in time, I would think there would be no differentiation of services that an end-user versus ISP should receive.

However, I don't see a case where end-users would ever agree to pay the same fee schedule as ISPs today.

Paul Andersen:  Putting aside the fee. Understood. I don't think we can ignore the fees, but we're trying to get an idea of the merge there. Microphone No. 3.

Michael Joseph:  I just wanted to respond to the comment that John made about Whois database accuracy. When we say that, we're dancing around an issue, which is people came to ARIN. They applied as an end site. They say I'm an end site. I'm not an ISP. I don't have IP transit customers and therefore I want to qualify not only with end site fees, but under end site policy.

And now we're saying but in fact they have transit customers and we should let them put those records in because it would be more accurate.

I think the fact is they're an ISP. If they have customers that are not part of their organization, that makes them an ISP. And it's not just about fees, it's about qualification criteria. End sites have far laxer qualification criteria than ISPs do.

So whether or not we just decide to merge ISPs and end sites at some point is orthogonal. If we have organizations out there that are in fact ISPs and we find they want to put records into Whois, I think that's a great way to recognize that they're in fact not qualifying as an end site.

Paul Andersen:  Thank you. We have some remote comments, I believe. Just you. Number 1.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. I do not support the policy as written. I would be okay if it was limited to reassignments within the Org ID. But as it's currently written, it's an end run dump policy, and I don't support it.

Paul Andersen:  Thank you. Microphone No. 1.

Before you go, we're going to be closing the microphone soon so approach quickly.

Matt Pounsett:  Just to clarify something quickly for – I think it was Mike a second ago said this isn't – I don't read this as being for organizations that have customers. I read this as being for organizations that have separate business units that may be under separate management, or at least separate operational management, in order to indicate in the database who is actually managing the resource. So, for example, in my own organization, there's a TLD – I shouldn't go into specific organizations. I know, John, you always yell about that.

Hypothetically, if there's an organization that is made up of several different business units that have different network operations groups for those different business units, it makes sense to be able to put information into the database that points to the actual operators who are managing a particular resource.

That said, I do agree that being able to do this does put extra operational load on ARIN, and any end site that wants to do it should be charged accordingly.

Paul Andersen:  Thank you. Kevin Blumberg.

Kevin Blumberg:  I don't support this policy as written, I'll say it now. Kevin Blumberg. I don't believe the premise is accurate. I think it's a little misleading. The problem statement, I believe, is misleading. Even if I take the problem statement at face value, I could see the text saying if you require the ability to SWIP, it is possible to switch from being an end-user to an ISP, and that solves the problem.

I think the problem is it's not documented in the NRPM currently that you're, in fact, allowed to switch from one to the other. I don't know about backwards, but from one to the other.

I'm very concerned about the concept of leasing within the market by questionable – in a questionable way. I.e., I don't want to see potentially huge swaths of space being leased out by a virtual end-user company, SWIPing these downstream to customers and having them get yanked because the ownership is still with the company.

I want to see the transfer market get used. But I don't want to see this gray market of the IPs are registered to me but they look like they're to you but they're really with me and I can yank them at any time I want.

It leads to a bad market. It not only creates an end run, but it actually creates some very interesting companies that can do some very weird things, in a virtual environment, paying nothing to the community or anything. So I don't support that.

Paul Andersen:  Anything in the jabber? No? John Curran.

John Curran:  I'd like to – I understand the point you just made. But from the logic inverted, and so I have to pause and think, to the extent that you have a large end-user and they have a lot of address space that they're not using, it is possible for them to just not use a piece of it and to tell someone you can use it and I'll give you a letter of agency and you can use it, where letter of agencies have been accepted from ISPs for decades.

And so when that happens, that piece of that address block shows up as the end-user. The actual user and the ISP routing it is in the routing tables but not in Whois.

And that means that you can't actually tell who is using the address space. The ISP who is routing it may be able to by looking at his records.

An ability to put in reassignment records would allow the ability to show visibly who that address space has been assigned to.

And so in terms of accuracy, I see – I guess the question – you indicated this leads to a gray market. And I actually see it the other way around. The absence of this will cause end-users to not be able to record who is using the address space and the presence of it will allow them to do so accurately.

So I guess – do you understand what I'm saying, is that I see the exact opposite effect for as a result?

Kevin Blumberg:  I understand where you're coming from. I believe there are, in the current situation, if you are an end-user and you're doing this, if you have an end-user and you're not SWIPing it out to that other company, that company is assuming more significant risk and is going to be looking for more legitimate ways of doing it that protect their company.

We are legitimizing, in doing it, I guess is what I'm saying, John, a model of working that is counter to a more stable environment. The reality is they could just become an ISP with the space, done. That would solve the problem. And if that's what they're doing, if they're off leasing out the space, it's a drop in the bucket in the grand scheme of things.

John Curran:  Just for clarity.

Paul Andersen:  Starting to get into a one-on-one here. Very quickly, please.

John Curran:  In other regions you have a local Internet registry which may not be an ISP. In the ARIN region, when they become an ISP, there's an implication that they meet the definition in NRPM as a service provider.

And so the option you're giving them may not actually be valid if ARIN asks:  Are you a service provider providing Internet services to the customers that you want to SWIP.

Kevin Blumberg:  Last comment and I'm done.

Paul Andersen:  You're between people and cookies.

Kevin Blumberg:  You have LIR in the ISP. It's ISP/LIR, correct?

Paul Andersen:  We're getting a little off here. There's been some people patiently waiting. We're closing the microphones now at the end of microphone number null at the back there.

Scott Leibrand:  And jabber.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. I don't support this policy as written. I think this is an important issue for us to figure out, particularly for v6.

We seem to look at these policies only in the IPv4 market world and all of that kind of stuff. In the v6 world, we've got these big chunks of addresses, and hopefully you're going to get one big chunk of – the ideal world is you get one big chunk of addresses and you use it for your entire end-user organization and there could be some very useful operational details exposed below that, maybe.

Like I'm going to use a specific instance because we're a public institution. We have multiple campuses. It might be useful to some of you to know that this block is over in Duluth, Minnesota, and that block is over in Crookston, Minnesota, and this one is in St. Paul. And those are all operational things that I'm actually willing to disclose; you might all want to know them.

There's other people, like law enforcement, that might want to know them. This is all useful information. We have to remember this.

Now, there's consequences to all of this stuff and we have to weigh these consequences against each other. But let's not get too shortsighted on looking at what are the consequences in v4 and, oh, my gosh, somebody's going to game the system because we let them expose more information. Wow, that's weird. Thank you.

Paul Andersen:  Thank you, Dave. The microphones are now closed. Microphone 3.

Gary Giesen:  Gary Giesen, AKN. Further to Owen and Matt's comments. I would be – I think they should be able to put location information within the same Org ID. I might even be supportive of SWIPing out to a related Org ID. Although I think that puts too much burden on ARIN to determine the relationship between the two. So I think I would still err towards doing it within a single Org ID. I don't think the benefit of opening it up to any Org ID overcomes the potential downsides of it.

I think if that was truly the case, they have two options. They can become an ISP or they can transfer the block to whoever is actually using it.

Paul Andersen:  Microphone No. 1.

Marc Lindsey:  Marc Lindsey, Avenue4. I was unsure about the policy until I heard John talking to Kevin. And, I think, just want to reiterate two points that John made, is that this not having this ability to add reassignment records is having zero impact on the leasing market, leasing happens frequently in all sorts of fashions.

So introducing an opportunity to have the records be more accurate will have zero impact, in my view, on the leasing market. There are commercials about that that are independent of this. I've seen it work to the contrary. I've had companies who have affiliates who want to use address space cannot get reassignment records indicated, and so they use these weird comments in the comment field to try to make it happen. And that's kind of a workaround that is unideal, in my view, or they'll just not say anything about it.

So emphasize that the leasing market is happening. This will just make it easier and more transparent for the registry to reflect that.

Paul Andersen:  Over to the remote participant.

Scott Leibrand:  Marla Azinger says she doesn't support this. She would support it if it turned into one policy for all, which I believe she means the consolidation of end-user and ISP.

Paul Andersen:  Thank you, and our last comment will go to Vint.

Vint Cerf:  This is microphone Vint speaking. Just one observation. It sounds like we're saying something like if you do this you are an X, for some value of X. And it could be that we want our policies to be more close to if you do this, then you can do that. And this one sounds a lot like, hey, gee, it would be good if we knew if you were willing to tell us how you're using the address space because there are benefits all around to that.

So I hope there will be further discussion of the ramifications of this particular proposal.

Paul Andersen:  Thank you.

Chris Tacit:  Thank you, all, for your guidance. We'll take that back.

Paul Andersen:  Thank you for your time. I'll throw it over to John for the break.

John Curran:  Thank you.

(Applause.)

John Curran:  So we're just a wee bit late for our break. But we're going to come back and handle the remaining policies. And we have until 4:45 today, and we still have policies on the docket, so I would recommend we come back and have a brief break. Can everyone be back here at 3:35? 3:35. 21-minute break. Three minutes longer than our prior break, I want you to know.

(Break.)

John Curran:  Okay. We're going to resume and pick up where we are in our policy consideration block, and the next one is Draft Policy ARIN 2015-2, which is Modify 8.4 Inter-RIR Transfers to Specified Recipients.

Cathy Aronson will come up for the AC and give the presentation.

DRAFT POLICY ARIN-2015-2: MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)

Cathy Aronson:  Sorry about the jersey, but I was a little too warm. So here I am again, like a bad penny. Aren't you excited?

(Applause.)

Cathy Aronson:  Like you didn't have enough earlier. Okay. So we have a new policy proposal that we'd love to get your feedback on. It was written by David Huberman and Tina Morris based on experiences where they work, and Chris Tacit. He didn't want to present twice in a row – I don't understand that – so I'm presenting.

So basically right now organizations can get a 24-month supply of IP addresses on the transfer market and they might have an unexpected change in their business plan and the policy prevents them from transferring those resources for 12 months after they receive them.

They've got a 24-month supply of addresses and for 12 months they can't transfer them anywhere else. That's become a problem for some organizations.

So this is what the policy does. So basically it removes the word "transfer."  This is the current policy text, and it removes the word "transfer" from this. So source entities within the ARIN region must not have received a transfer allocation or assignment of IPv4 Number Resources for ARIN for a period of 12 months from the approval of the transfer request. So it changes that to just say allocation or assignment but not a transfer. Does that make sense?

Basically takes the transfer out of it. So this would allow one of these organizations that has a change in business plan to be able to transfer their Number Resources to a different region, if they needed to, based on their business.

There's been a lot of discussion on the Mailing List about this. Let's see, what do I want to say? Oh, no, I thought David was going to the microphone.

So there's some discussion. I guess there's probably some bullets about this. It's hard for me – I should wear my glasses. It's hard for me to read.

But there's some discussion about transferring it to the same organization would be okay but to a different organization wouldn't be okay.

Some folks say it's not ARIN's problem and that you get them and you'll have to wait. So let's see. But global networks operated in multiple regions and they like to go and get their address space from one RIR as opposed to five, like I used to get three.

Let's see. So there's some proposals to insert more language that says, well, you can transfer to the other region but it can't get transferred again, or it needs to be the same organization, like I said.

So we'd really like to get your feedback about what you think about that. We've got – like I said, we've gotten a lot of feedback on the list as well.

Let's see. So, anyway, anybody have any –

John Curran:  Microphones are open.

Paul Andersen:  Microphones are open. In stereo. No microphone wins the race. Far back microphone.

David Huberman:  Hi. Hello. David Huberman, Microsoft. So we do a lot of policy work to be equitable, to help small guys, medium guys, big guys. This is a very focused proposal. In my professional opinion, it has very little impact on most network operators.

Where it has the most impact and where it is critically important is for extremely large multi- – excuse me – for multi-national networks of any size who really wish to use the RIR system and the market to the business's benefit. Bottom line, my friends, if you're buying IP addresses right now, it's often cheapest to do it here in ARIN.

The unit cost is lowest, in my experience. We want to use the ARIN registry for everything that we can, for local language, local support. But there are rules. In China, there are rules. In Brazil, there are rules. In countries that require you to move space to their registries in order to get things like transit, where it's illegal to use space that's not registered in their registry.

We need the flexibility to buy space or have holdings where we have them and move them where they're going to be used on the network to comply with the rules and the laws and basic network operations.

I encourage you to please support this in principle. Thank you.

Paul Andersen:  Thank you, support from that. Microphone No. 2, please.

Matt Petach:  Matt Petach, Yahoo!. I would like to like to ask one clarification on this. This is not making any distinction on where the addresses can be used. This is simply on where they are registered; is that correct?

Cathy Aronson:  I believe so, yeah. I mean, the big issue, like David said, is that to formally transfer them to another RIR, there's this 12-month period.

And in some of these countries they really need to actually transfer them to be able to use them because of the laws in those jurisdictions.

So to actually transfer them out of region to another entity, you can't do that right now.

Matt Petach:  So for 99 percent of the world you can take ARIN space, make use of it in other parts of the world without impediment, and then there's a few, small, measurable-on-one-hand countries where this would be necessary?

Cathy Aronson:  Right. Well, there are some issues with using it in other regions and then justifying, using that as a justification to get more. But that's not the policy.

Matt Petach:  They're separate policies talking about that.

Cathy Aronson:  That's specifically not this policy.

Matt Petach:  Then based on those specifics, I oppose this policy. Thank you.

Paul Andersen:  Thank you. Far Microphone No. 1.

Joe Provo:  Joe Provo, Google. While the issues raised by Mr. Huberman for global networks is important in that market, I have to oppose this policy as written because there are strong concerns of the anti-flip language being not present or actually subverted.

Paul Andersen:  So, sorry, opposed, correct?

Joe Provo:  Correct.

Paul Andersen:  It was hard to hear you. I apologize.

Joe Provo:  I'm sorry. Yes, the monitors in here are pretty weird. Opposed as written.

Paul Andersen:  Opposed as written. Thank you. Center Microphone 2.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. Opposed as written. The anti-flip language was put into the transfer policy for very good reasons. This would literally gut it, without offering any sort of substitution. And while I understand the mostly legitimate needs of the proposers, I think that there are a lot of other people that if we enacted this would use it in a much different manner that would be not so good.

So, again, without having the ability to limit this to transfers to the same organization overseas, and without having some ability to restrict it from subsequent transfer to somebody else once it got overseas to another RIR, it basically just is an end run on the anti-flip language that we put in for good reason, and for that reason I strongly oppose the policy.

Cathy Aronson:  Just curious, would you feel differently if it had to be the same organization in the other region?

Owen DeLong:  Only if it also prevented the same organization in the other region from then subsequently transferring it to someone else in that region, which is virtually impossible.

Cathy Aronson:  Not possible. Okay. Just checking.

Paul Andersen:  Thank you. Microphone No. 1 over there.

Dani Roisman:  Dani Roisman, Softlayer. Much like a couple of the previous speakers, commenters, I do agree. I oppose the policy. I think the anti-flip intentions of the policy are valid and should stay in there.

To David Huberman's point, though, if this creates a hardship, a demonstrable hardship for the organization, I think maybe an exception can be made in those cases. So if the organization says I cannot operate in this other region and use these IP addresses in this specific region because of some kind of legal requirement where I must move to a different RIR, I think that is the only case where this should be allowed within 12 months of transfer.

Paul Andersen:  Is there any remote participation that we should be aware of? Okay, just checking in. Thank you. Over to microphone number two, please.

Matthew Kaufman:  Matthew Kaufman, Microsoft. Not because I work for Microsoft, however. I share Owen's concerns strongly, and that is why I wholeheartedly support the proposal.

Cathy Aronson:  Okay. Help us with that.

Matthew Kaufman:  I believe that anti-flipping and needs assessment and all sorts of policies like that that restrict transfers are simply attempting to control a horse by holding on to its tail.

Paul Andersen:  Analogy we'll have to consider.

Cathy Aronson:  Awesome analogy.

Michael Joseph:  Mike Joseph, Google. I oppose this policy as written and probably in every rewrite. I sympathize with the network that decided to acquire space and put it in the wrong spot under the wrong ORG and wrong RIR. But this carves out an exception where they did so and want to transfer it to another region.

But what about a network that acquired space in ARIN region under one ORG and decided they don't need that much space and want to sell it off? Policy doesn't allow for that.

But if they acquired space for one subsidiary and they spun that out, well, the policy allows for that under 8.2, but what if they acquired space for an entity here and decided that they needed to move it to an unrelated entity that they may have some kind of deal with.

The fact is we created anti-flip language to protect against flipping of address space. And although there are a number of circumstances which a large entity can make a mistake, I would hope that the large entities that are acquiring significant amount of address space have the resources to forecast their utilization for at least 12 months and therefore aren't making this kind of mistake. So I oppose this policy as written.

Paul Andersen:  Opposed, understood.

Cathy Aronson:  Thanks.

Paul Andersen:  Thank you for that. Back to Microphone No. 2.

David Huberman:  David Huberman from Microsoft. Let's flip the discussion for a second. Did you catch that pun? I'm going to stand here and I'm going to be honest with everybody here. In this region, and in RIPE, which has a similar policy set, anti-flip language is nonoperative.

People are getting up to the microphones and saying, well, we put this anti-flip language to prevent this. And my friend from Google, Mr. Joseph, just said it prevents people from doing these run-arounds.

When people have unused addresses, they sell it. And it doesn't matter what the rules are at ARIN. It doesn't matter what the rules are at RIPE. It doesn't matter what the rules are at LACNIC or anywhere else. The addresses are being sold. They are being bought. They are being used.

And the question for this community and the others is do we want Whois to reflect who is using the addresses, or do we want to stick to some rules that are nonoperative and completely ignored?

Paul Andersen:  So you support?

David Huberman:  Yes.

Paul Andersen:  Thank you. I'm going to – Chair's choice to go back to No. 2 because Owen popped up so violently there.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. I really love this argument of everybody speeds so we should remove the speed limit.

We have rules for a reason. Yes, we have people who choose not to follow the rules. Every society has people who choose not to follow the rules. The solution to that isn't to eliminate the rules. The solution to that is to keep the rules and keep as many people in society cooperating with the society as you can and recognize that a certain amount of loss occurs.

There are people that are playing by the rules, and there are people that are not playing by the rules. Hopefully most people will continue to play by the rules, but I don't think that because crime occurs we should eliminate the law.

Paul Andersen:  Thank you for that. Number 1 again. Sorry to keep you waiting.

Richard Laager:  Richard Laager, Wickstrom Telephone Company. I'm tiny and have and no particular stance on this, I'm neutral, but one thing I think I would like the AC to consider in this, a number of people have brought up the idea that it should maybe limited to the same Org ID in another region.

And I don't know much about multi-nationals, but in some of these countries where they have these restrictions, do they also have restrictions where they have to have local operating subsidiaries, Microsoft Brazil or Google China or I have no idea what, but that might be something to consider, that adding such a restriction might not meet their needs.

Paul Andersen:  Thank you for that comment. Okay. If you could approach the microphone now if you have a comment that you'd like to make on any discussion or any item. Is there anything you haven't heard yet, CJ, that you would like them to discuss?

Cathy Aronson:  Just the thought on whether the other subsidiaries, the same companies, the country, but some folks are already commenting on that.

Paul Andersen:  If you would like to comment on this, especially if you would like to comment on the subsidiary issue. To Microphone No. 2, please.

Matt Petach:  Matt Petach, Yahoo!. While I think adding the clause for same organization or subsidiary would be interesting, to comment on my esteemed colleague from Microsoft's perspective that these transfers are happening anyway and this would just legitimize them. There is an important and crucial distinction between an underground transfer into a country that has put forth terms that essentially say to use this address in this country legitimately you must transfer it into our registry. And, by the way, once it's in our registry, it's not coming back out.

Using that space under the table in the gray market does not give that registry a legitimate claw on to the space. This would allow and open up the door for legitimate transfers which would say you legitimately now control this space in your registry. And if your rules don't allow it to come back out, I foresee a one-way funnel that worries me greatly.

So I would just urge the AC to also consider the difference between underground utilization that doesn't provide legitimacy and actually legitimizing a one-way funnel transfer. Thank you.

Paul Andersen:  Thank you. If you'd like to discuss this issue, I urge you to approach the mic in the next ten seconds, A, and then we have – while we're listening to this comment, we will close the mics.

Scott Leibrand:  Remote comment from Marla Azinger who proposes a revision to the rewrite. She suggests it read:  Source entities within the ARIN region will be restricted from transferring address space within 12 months of its most recent transfer allocation or assignment barring reasonable business requirements. She suggests that we let ARIN staff decide.

Cathy Aronson:  That's interesting.

Paul Andersen:  If there's no one else approaching the mics, we'll go to Kevin. You've got the floor.

Kevin Blumberg:  Kevin Blumberg, The Wire. I know this point sounds a little surprising, but I'm a little confused. We allow 8.4 transfers to entities out of the region currently today. So we're in a situation where if it's the first punt of the resource, that's not a problem. I can go to company XYZ, buy it, and it disappears off into the nether regions of whichever country the inter-RIR transfer happens with.

Unidentified:  Logic.

Kevin Blumberg:  I know. Logic is a little weird here.

But here's the bigger issue. So I want to buy in one transaction enough space to handle my needs all over, whatever that may be. Hey, that need could be I need a /10 and I need a /24 to go to London, England, because I like London for some reason. Let's penalize a legitimate make-it-simple kind of way with anti-flip, because it's now viewed as two transactions.

Maybe a suggestion to this would be that during the major transaction portion we can combine 8.3 and 8.4 and let that buyer actually submit, we will be taking the space in this one transaction, having it go here, here, and here. It sort of deals with the anti-flip because we know what's going on and they're not just turning around and selling them off all over the place, but at the same time it gives organizations the ability to do single transactions for their needs without complicating it.

So just a suggestion.

Paul Andersen:  Thank you for the presentation, and toss it over to John for the last proposal of the day.

(Applause.)

John Curran:  We find ourselves well ahead of schedule. I'm not sure how this happened, but it does occasionally happen.

Paul Andersen:  Teamwork.

John Curran:  So at this point I'd like to – I guess we have –

Paul Andersen:  The block.

John Curran:  We still have policies. We can bring one of tomorrow's policies up today. And so looking at these, which one would you recommend?

Paul Andersen:  We don't want to do 2015-10? We have one more left today.

John Curran:  Oh, you're right.

Paul Andersen:  John Springer is going to come up and do 2015-10.

John Curran:  Wow, I'm living in the future. In a few minutes we'll be well ahead of schedule and I'll be moving on. But we're not there yet.

Paul Andersen:  You know you've completely jinxed us. It's going to be a 45-minute bloodbath.

Draft Policy ARIN-2015-10: Minimum IPv6 Assignments

John Curran:  2015-10, John Springer, if you could come up.

John Springer:  So this is done in a fairly simple way. We accept this as a Draft Policy based on the clarity of the problem statements. So that's included. It's in your guide. Essentially so I'm the primary on this, David Farmer is the secondary, and the author is Matthew Kaufman.

It seemed clear to us that the author wanted to codify practices that had been widely discussed on the net for quite some time in such a way that anybody that used a less of a block size than a /48 in subnetting an IPv6 assignment would not have those be counted.

He's got two policy statements. I'm usually averse to reading these aloud. They're in your guide. We've not requested staff and legal on this because it's just a Draft Policy.

ARIN does not usually dictate what might be done with resources after they're allocated or assigned. It was pointed out to me that there are exceptions to this.

What we do more often is to condition any further allocations or assignment based on what is done with resources presently – previously.

So where we're at with this is:  What do we do? There are well-developed best common operational practices that essentially lay this all out that there have been just numerous discussions over the years about using a 48 as kind of the de facto guide on subnetting v6.

We have the ability to do this. And we have three criteria that are going to come up in the AC meeting tomorrow. We need to move this forward to recommended status. We need to ask ourselves:  Is it technically sound, does it enable fair and impartial number policy, and does it have the support in the community?

So the first two are kind of a slam dunk. Technically sound. Well, if it's already got written Becops, that's probably the case. Fair and impartial, same, same. So the first thing I would want from this group is:  Should we do it?

Paul Andersen:  Should we do it? The microphones are open. Give them a moment to assemble. We'll start from tallest – all right. Number 2.

David Huberman:  Very fast. As a member of the Advisory Council, I voted against putting this policy on our docket. This is out of scope for ARIN as a registry, in my opinion. We do not – IPv6 is still pretty greenfield, by the way.

I agree with you there are well-worn Becops on this, but I don't think they're what we're going to have for the next 20 years. It's an evolving thing as we get more and more experience.

This didn't belong in the NRPM, and I don't support it at all. I'd like us to abandon it.

Paul Andersen:  Okay. Thank you. Number 3, please.

Gary Giesen:  Gary Giesen, AKN. I support the policy as written. I think there's a lot of people who might take shortcuts with v6, which I think would be detrimental to the end-users, and I think ARIN needs to show some leadership on this. And I don't think it's harmful at all. Every end-user getting a proper assignment.

So I support it as written.

Paul Andersen:  Thank you. Microphone No. 1.

Michael Joseph:  Mike Joseph, Google. I oppose this policy as written. I think this unnecessarily gets into the specifics of ISP operations. But more to the point, it's not necessary and the wording is a bit misguided.

The original IPv6 calculations that Owen put forth couple years back already take into account this circumstance, because the provider allocation unit is in fact the finest smallest block that an ISP assigns to its customers. So ISPs are already incentivized to assign larger prefixes to their customers.

But this goes beyond incentivizing; it goes to mandating. And I think that's a bit too heavy handed here. And on top of that, the language would need quite a bit of wordsmithing because it introduces a great deal of ambiguity.

I oppose the way it's written, and I oppose the idea of mandating this particular assignment.

By the way, I'm all for making large assignments to customers, but I don't think this is the way to incentivize that.

Paul Andersen:  Thank you very much. Rear microphone in the center. See, I go around the microphone. If you want to get quicker, you find an empty microphone as opposed to getting in the big line.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. That wasn't my intent, but that's okay. I didn't want to jump lines. I just was the closer mic.

Paul Andersen:  That's okay. Go to the comment, though.

David Farmer:  As has been said already, this is trying to push something that I don't think we should be doing.

One way to say this, this is an innovation. What happens when somebody has a brilliant idea and rethinks all this stuff and we've got all this stuff codified in our policies? I also think this sounds an awful lot like trying to regulate from the wrong end of the tail, as was mentioned in this thing, a metaphor that was used before, the wrong end of the horse. Let's just leave this alone. I think we're good enough. I don't support the policy as written.

Paul Andersen:  Thank you. Microphone 2.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. For the few people in the room that may not be familiar with any of my postings over the last six years, I'm a big proponent of large allocations by ISPs to end-users. I'm a big proponent of 48s for every house and two chickens in every pot, et cetera, et cetera.

I don't support this policy. It is a bridge too far, as many have said. It steps beyond the encouragement that, as was noted, I penciled into the current policy when I wrote it and goes to a level of mandate that is not good. It also sets the bar at /56, which is also not good. We should be sticking to /48s as much as possible.

Paul Andersen:  Thank you for that comment.

Please approach the microphone if you would like to make a comment. We will be potentially doing a poll on this question. So I would ask you to approach so you can give your input to the discussion, please.

Matt Petach:  Matt Petach. Hell no. I don't know anywhere else in the NRPM where we use such strong language as "in no case."  We give the staff no leeway, no discretion, no ability for unique engineering constraints or anything like that. It simply says, bluntly, "in no case."  I don't think language to this degree is appropriate. I actually don't even know which end of the tail that my esteemed colleague Mr. Farmer was referring to is the good end of the tail. I was scratching my head and thinking either end is bad news.

But I strongly support his stance of this is not the way we should be writing policy.

Paul Andersen:  Okay. So opposed. Over to – was it Kevin, or remote?

Kevin Blumberg:  It was me.

Paul Andersen:  Kevin, and then we'll go to two. You have the floor. Go ahead.

Kevin Blumberg:  So 10 years ago, if we were all sitting in this room, what would we say is the perfect size to be giving out for our residential or business 10 years ago? 10 years from now what will we be saying? It could be bigger, smaller? But let me ask you a question.

I want to have autonomous grains of sand as my end site. And I'm going to wave a magic wand over this autonomous grain of sand, and the sand is so small that it can't hold a /48 or /56 in it, but it really works well with a /64.

And I have – my business plan is to use that. I don't need ARIN or any RIR telling me that I can't make a business out of my autonomous sand. That's the problem with putting technical specifications into a registry document. And this is where I actually disagree with John. I don't believe this is technically sound from a technical point, and I do oppose it.

Paul Andersen:  Okay. Microphone No. 2. And I urge those that would like to comment to approach a microphone. Or if you're in remote participation, please start typing now.

Matthew Kaufman:  Matthew Kaufman speaking for myself as the original author of this policy. I am opposed to this policy.

(Laughter.)

(Applause.)

Vint Cerf:  Only at ARIN would we hear this.

Matthew Kaufman:  I do believe that ARIN should not condition further allocations on what have been done with resources in this case or many other cases that we will be discussing later, including how addresses are assigned to equipment and need and things like that.

I don't believe it's any of ARIN's business to control what you do with the space after it's been allocated, even through such an indirect mechanism. I'm glad we've gotten so many people on the record saying exactly that. Thank you.

Paul Andersen:  Thank you. So I will put my – since it's baseball season, our counters on deck and ask if there's anybody else who would like to speak.

John, did you want to add any thoughts or prod any questions or discussion?

John Springer:  We had private communications about possibly doing a show of hands –

Paul Andersen:  I've got the counters on deck.

John Springer:  That was kind of conditioned on not receiving a strong signal. Unless some other AC members –

Paul Andersen:  Dan, what would you like to do? You'd like to withdraw the question?

John Springer:  Unless some other AC member needs additional information, I'm good with the signal.

Paul Andersen:  The input is clear. Crystal? Okay. With that we'll close the mics, and that ends this policy. Thank you. Thanks to John and thanks to all your input today.

(Applause.)

John Curran:  Okay. Now we're ahead of schedule. And I want to make sure we have plenty of time, but at the same time it's hard to predict how long policy discussions will go. We're still in the policy block. I believe we'll take one of tomorrow's policies and bring it forth to today. That would be 2015-7, Simplified Requirements for Demonstrated Needs for IPv4 Transfer.

Paul Andersen:  Rob Seastrom, come on down.

John Curran:  I'd ask Rob Seastrom to come on down.

Paul Andersen:  You're the next presenter on the Policy is Right.

Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers

Rob Seastrom:  Okay. 2015-7, Simplified Requirements for Demonstrated Needs for IPv4 Transfers.

So this is another one of those cleanup proposals. Remember we were talking about the cleanup proposal earlier. I've got a second one.

ARIN transfer policy currently inherits all of its demonstrated need requirements for IPv4 from NRPM Section 4, which, by the way, talks mostly about the free pool. And we're out.

So in practice ARIN is more lenient with Section 8 than with free pool requests. We have a 24-month needs horizon, and it's hard to be quite as certain with that as it is with three. And so we think that the proposal originators think maybe it would be a good idea to simplify the whole thing.

So here's the policy statement. We're inserting a section in policy, which is 8.1.x, and what number exactly it gets is an administrative issue, simplified requirements for demonstrated need for IPv4 transfers. IPv4 transfer recipients must demonstrate and an officer of the requesting organization must attest that they will use at least 50 percent of their aggregate IPv4 addresses, including the requested resources, on an operational network within 24 months. Organizations that do not meet the simplified criteria above may instead demonstrate the need for Number Resources using the criteria in Section 4 of the NRPM. So it makes Section 4 compliance optional.

Staff and legal. Staff says they would apply this policy language to 24-month needs assessment for 8.3 transfers 8.4 transfers and preapproval requests.

In order for staff to verify the demonstrated need of 50 percent of the total aggregate, the policy criteria in Section 4 would continue to be utilized.

More feedback from staff. This policy would allow organizations to potentially qualify for a larger amount of IPv4 space than they currently can.

This policy can be implemented as written.

And the staff includes the administrative observations about where they would put it.

Lawyer says no legal issue, but has a comment that says that if the policy is adopted, it would significantly lower the degree of utilization required and permit significantly larger transfers of resources. That's in effect a bridge maintaining a lighter needs based structure that permits substantially greater transfers.

So an issue that doesn't have to be resolved, but it may be of importance to us, is the acquiring – whether an acquiring party is taking advantage of such a policy change ought to have a corollary duty to fully disclose to ARIN whether they have use of any other Number Resources by agreement that effectively reduces their overall Number Resource needs.

That would be, for example, stuff in drawing attention to other Org ID mentioning if they have leased or unSWIPed stuff that's delegated to them, et cetera.

So microphones, please do you support this policy as written?

Paul Andersen:  Microphones are now open.

Rob Seastrom:  Do you want to suggest –

Paul Andersen:  You're being so Canadian. No, you first; no, you first.

Rob Seastrom:  What do you think of that duty to disclose?

Paul Andersen:  Go ahead, No. 2.

Matthew Kaufman:  I fully support the policy as written. I support any policies that reduce the amount of justification that needs to be provided for transfers.

Matthew Kaufman, in case that wasn't clear, speaking for myself as always.

And on the duty to disclose, I could see that going too far. I could also see it being perfectly reasonable. I guess it depends on what the exact language was about what you did and did not have to disclose.

Paul Andersen:  Thank you. So in favor. Now, moving to null microphone.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. Oppose the policy as written. I do like the idea that the suggestion of a duty to disclose more generally than just related to this policy.

However, if we go back and we look at staff's comments, we see that staff says we're going to apply the 8.4 criteria to assessing half of what you need anyway. So we haven't actually simplified anything as the policy claims to be doing.

We're just putting you through the same ringer and you can get twice as much for the same justification. That doesn't make sense to me.

Paul Andersen:  Thank you. So one in favor, one opposed; problem solved, right?

Please approach the microphones if you would like to comment on this proposal. Microphone No. 1.

Joe Provo:  Joe Provo Google. Oppose, strong. This opens the door for abuse, reducing justification. I know there are many people that are opposed to needs-based, but many of us in the community are still strongly in support of needs-based, and reducing it to an officer attestation is simply too weak, in my opinion.

Paul Andersen:  Thank you very much. Please approach the microphone if you would like to discuss this policy. In favor or opposed. The AC is looking for some direction. Do you support the policy and the suggestion about the duty to disclose?

Go ahead. First the picture opportunity; now No. 2.

Matt Petach:  Matt Petach, Yahoo!. I would say I weakly oppose this. I think there is a lot of gray area and uncertainty, and I think the staff assessment is very telling in that we're really just going to apply the same thing that's already in the policy; this is going to be a no op other than to allow us to allocate twice as much.

I think if that's the end result, then we should have policy language that more accurately reflects what they're going to do, having policy language – sorry, I didn't rush to the microphone like I usually do because I was squinting at this trying to actually make heads or tails of it and realizing why the staff assessment is the way it is.

I think there may be some merit to the idea. But the way it's written and implemented seemed to be at cross purposes. So I oppose it the way it's written.

Paul Andersen:  Thank you very much. Rear microphone.

Sandra Brown:  Sandra Brown, IPv4 Market Group. I think I weakly support it. I don't think it's optimal. I'm kind of along the same train of thought as Matthew, that 50 percent reduction is kind of a step in the right direction in terms of lessening the barriers to transfers, and I do support the idea of less governance, if you will, because I think the governance rules now are much too strong.

But this point that 50 percent will still require the same amount of scrutiny for the staff so there's not much reduction in terms of what the staff does is a very valid point.

I think, regardless of what happens, you're going to see that the cheaters are going to cheat and the people who are going to do their justifications honestly are going to be honest. And that's going to continue no matter what happens.

So I like the idea of lessening the barrier. I think the only thing that this really lessens, that's why my support is very weak, is it just kind of lessens in terms of 50 percent from 80 percent. It's very weak support on my part.

Paul Andersen:  Thank you. Weak support on that one.

And over to Microphone 1. And, again, though, please approach a microphone because we're running out of queue entries.

Michael Joseph:  Mike Joseph, Google. I oppose this policy. Actually my colleague and I put together a policy proposal last year to try to achieve goals to simplify justification requirements for entrance into the transfer market.

But ultimately I think the problem with this policy is that it does two things. First off, it throws out all the existing needs basis justification that we've crafted into the NRPM over the years. I know there's a number of folks in this room who might have that as their goal. But I think the community hasn't come to a consensus on getting rid of those forms of justification.

And it also lowers the bar dramatically, reduces from 80 percent down to 50 percent. I think that does it in a fairly underhanded way here and under the flag of simplification.

So I oppose this policy. I don't think there's a problem to be solved here, honestly. I think transfers seem to be flowing reasonably well. I'm not sure we need to so quickly erode the policy basis under which we justify those transfers.

Paul Andersen:  Thank you. Kevin is in queue.

Scott Leibrand:  Marla Azinger says:  No support. I've done several, and I don't see the need. It would also just deplete the market faster unnecessarily.

Paul Andersen:  Okay. That's the only one then. Kevin.

Kevin Blumberg:  Kevin Blumberg, The Wire. We could just as easily change 80 percent to 50 percent in the rest of the text and not create an entire new section.

To me, I weakly object to it rather than weakly support it or heavily support. This seems like a compromise that creates the worst of both worlds. When you have people who are heavily interested in making the transfer market easier, saying they barely support it, and you have people who are heavily in the needs-based camp saying they heavily don't support it, like it just doesn't – it doesn't sit right with me.

So I think either come up with something that really both sides agree on based on where we are at a point in time, but adding an entire new section to do effectively a change of a word in one place doesn't make sense to me.

Paul Andersen:  Thank you for that. So we do have a remote participant, but at the end of the remote participant the mics will be closed. Either start typing or running.

Scott Leibrand:  This is actually Scott speaking for myself as proposal author. I do that sometimes. I hear a lot of – I kind of like what this was trying to do, but I don't like the way that staff interpreted it in the staff assessment.

And I would entirely wholeheartedly share that assessment. The intent behind the policy language here was that if you have a certain amount of need and you have an officer attesting that you're going to use an operational network and an officer attesting to that need, that you would be able to bypass all justification procedures dictated by Section 4. That's the whole purpose of this being a different section and not part of Section 4.

What it sounds like is to go back and work with staff to figure out what magic words would cause them to not simply do business as usual justification needs assessment, all the stuff that they're doing, but instead do something different.

So the feedback I'd like from the community, maybe it's a little late in the discussion to get this on the floor, as we go into further PPML discussion, think about do you actually want the large edifice of needs justification of Section 4 to continue to be the hoop that everyone needs to jump through in addition to getting business approval to justify your transfer, or is there something simpler we could do that would allow you to verify that you are an actual operational network with an actual need for addresses? Not some speculator trying to just buy them and get them solely on that basis.

That was the goal of this proposal. And given it's a draft policy, I'm going to attempt to go back and figure out a way to get the staff assessment in line with the original goal of the proposal, and this might come back if that is successful.

So that's where I'm thinking. It sounds like everyone agrees that as it is interpreted today this exact text wouldn't be good, but if we end up doing any more requests for feedback, I'd like you to think about whether we should be continuing to work on trying to get the goal of this proposal into something that the staff would interpret the way we intended.

Paul Andersen:  R.S., any other questions you wanted to get, or can we close the microphones?

Rob Seastrom:  If I may, if anyone has ideas for specific language, the shepherds welcome that.

Paul Andersen:  If you have specific language, either approach the microphone now or approach R.S. off the podium at the social, which is coming up.

But we'll go to Microphone 1, then, for the last comment.

Mike Joseph:  Mike Joseph, Google. In response to Scott, just to make it abundantly clear, I don't think there is community consensus to reduce the staff questioning of requests coming in and making it as simple as officer attestation.

At least that's the point I've tried to convey. Hopefully I'm successful.

I think that we do, at least I think it's reasonable for requests to go through whatever the policy review is, whatever the gauntlet is, for justifying basic needs basis for a transfer. And if we think we should change that, let's go work in Section 4. Let's go tweak Section 4 how we wish to simplify justification.

But I don't think that we should put a bypass in and allow simple officer signoff to be able that we need to put the transfer through. That essentially eliminates needs basis. Not only does it have the required utilization, but it essentially makes it a meaningless number anyway.

To answer your question, Scott, I don't think it's a matter of reworking to get staff assessment more in line with this. I disagree with your intent.

Paul Andersen:  Thank you for your comment. R.S. closing comment? No. If not, this ends the policy block for now. I'll throw it back to John.

Open Microphone

John Curran:  Okay. We are now approaching the end of the policy block. And we have Open Mic and adjourn. Wow. So Open Microphone is what we have now. The floor is open for anyone who wishes to discuss any topics that have come up before us any additional topics.

David Huberman:  One of the things in general I want to discuss is debates over ISP and end-user and what that means. To foster some of that discussion, I'm going to try and open up some Mailing List topics or a topic on the Mailing List, and I encourage people to participate.

This is something that is very difficult because it's policy that's based on fees that's based on policy but also based on the organization, and it's a difficult discussion. But when we start – if you see discussions on the Mailing List, and we're talking about the ISP versus the end-user and just the whole concept of it and maybe conflating it, let's try and work towards the ideal.

That's all I wanted to say.

John Curran:  A data point. We actually did find we have some end-users who have RWhois entries on their organization. We're finding out how many. It's a small number.

In general, if we don't have a specific prohibition, we try to accommodate someone particularly when they're trying to provide information. But we do have a number who have asked and received that.

Microphone 3.

Matt Petach:  Matt Petach, Yahoo!. Over the break there was a discussion we had off to the side with respect to what Mr. Huberman was just saying but in a bigger context, which is we seem to be running into a problem where as an organization we're trying to guide behaviors or dictate what we think is the right way for members of ARIN to behave.

While, at the same time, we have incentive programs that are nudging them in the opposite direction.

Then we go to the microphones and we talk back and forth and scratch our heads about why is it we don't seem to see the community acting in the way we want.

And I think as a bigger meta question, we do need to think very carefully about are we providing the incentives to nudge people's behavior in the right direction? If people are behaving badly in our eyes, is it because we are actually giving them financial incentives to behave badly, even while we're telling them do this other thing, be the bigger person, do the right thing, even though it's going to hurt you more in the pocketbook?

And rather than trying to get people to act against their financial better interests, perhaps we really should put our heads together and say how do we structure the community and our policies in a way where the incentives drive people and organizations towards the behaviors that we really want. Thank you.

Paul Andersen:  Far Microphone No. 1.

Kevin Blumberg:  Kevin Blumberg, The Wire. At the end of today everybody will be sent a poll, sent out to all members, registered members in this room. Remote participants, anybody who registered for this event, will be allowed to – I think vote is a wrong word, but make some selections – for all of the policies that were discussed today.

I implore you to please log in and use it. The AC has spent a lot of time over the years dealing with consensus. And one of the concerns is that just the way things in North America have shaped up over the years, that there are some people in this room who can't raise their hand publicly but could potentially do it anongueymously.

Correct me if I'm wrong, staff, this is anonymous data that the AC will see. All we'll know is a registered member who voted or submitted their check box, but we have no idea who anybody is. And it would really help us if you could spend the – I'm hoping one minute, at the end of the day, take your gut reaction to these policies, submit your thing so we can see what the electronic show of hands is versus when we are doing the actual show of hands.

And offline, if there's any feedback you'd like to give in regards to that issue of being able to show your support or nonsupport one way or the other, a pigeonhole or an electronic poll or anything in order to improve the amount of information we have would be great.

John Curran:  Just to comment on that. The AC asked if they could do a post-session poll via electronic means just to see whether that's different than what we're seeing in the room. And so this isn't a new method. This is a tool that they're going to look at and see whether it produces anything different or anything of value.

And so we figure it's worthwhile. At the end of the day, the AC has an obligation to show the Board that the policies that are recommended have support.

And so we're not yet saying we're changing what we're using for that. The show of support for recommended draft policies that took place today is, as far as I know, what the Board is still looking at. If the AC wants to experiment with other means, we're happy to let them look at it.

Center front.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC, speaking primarily for myself and for a couple of Org IDs, DELONG and DELONG-Z. We had a great discussion about fees earlier. And it seemed to me like there was pretty strong consensus around the IPv6 step-down.

Seemed like there was pretty strong consensus in favor of the triple X small category and it seemed like there was maybe weak support but no real consensus around the larger categories. How long before the Board can implement any of that?

John Curran:  So the process – actually want to take that.

Paul Andersen:  How long could we or would we likely?

Owen DeLong:  When can I pay a better bill?

Paul Andersen:  I believe we would probably be looking at that – we'll have to look at our budgeting cycle. We're obviously going to have to come back, take all the feedback we get from this meeting but I would assume we'd probably try to line it up with the fiscal, which is calendar.

John Curran:  Calendar year. The hope – note, there's an implementation issue. We have a billing system that actually generates that stuff and we need to see the timeline for that. But we would intend to be pretty prompt.

So I'm hoping that if the ARIN Board approves a new fee schedule it would be something that we would see in place somewhere between now and our next meeting. Should not go beyond our next meeting.

Paul Andersen:  The Fin Com is myself, Aaron Hughes, and Bill Woodcock. If you see us later at the social, give some comments. Because I know, myself, I could use more feedback on some of the issues we heard.

John Curran:  Microphones remain open. Microphone No. 1.

Dani Roisman:  Dani Roisman, Softlayer. I just wanted to pass an idea here at the Open Mic. There's been talk in the hallways and multiple Mailing Lists about looking back at the NRPM, which is over 15-plus years old, and there's different places we identified where this is obsolete, this is suboptimal. It's become quite a large document.

And I've heard quite a few people, and definitely my interest, to maybe take a step back and maybe refresh it, simplify and reduce. I'm at a loss as to how to go about that. There's talk about taking on one large omnibus project, but there was very little confidence that that would ever get passed or approved, versus chopping it up section by section, subsection by subsection. Looking for input and discussion on that.

John Curran:  I know the AC has discussed this extensively. I guess the Chair would be the best one to answer that.

Dan Alexander:  I wholeheartedly agree with you, and we're very interested in your feedback regarding this topic, because we've had many, many conversations within the Advisory Council of whether or not the super-ultra-mega proposal would actually take hold and would be anything that people could wrap their head around, whether we need to do this as 20 different proposals or 10 doing it in multiple phases to consolidate sections over a longer period of time.

So, everybody, please grab an AC member and give them your opinion on that.

Kevin Blumberg:  Dani, to go towards that, maybe the question is for you:  Would you like to be run over by the omnibus?

(Laughter.)

Kevin Blumberg:  Or slowly or fast?

John Curran:  I will say the AC in the past, a year or two ago, attempted some fairly large, significant section rewrites, which survival rate before the community was pretty low.

So now instead we see an abundance of small flowers dying or so policy proposals or so at this meeting. I don't think there's a right way, but recognize the more you try to accomplish, the more challenging a sign-off will be.

And so I honestly don't know if anyone's brave enough to do an omnibus, omnibus NRPM rewrite from one end to the other and get it successfully through the community. I just don't know if it's actually possible.

Center front.

David Huberman:  David Huberman, Microsoft. So the RIPE working group on policy is doing an omnibus right now on transfers.

And watching this, it's a very enlightening process, because it's extremely – it seems very difficult to write a proposal that doesn't accidentally introduce new policy.

With that said, Dani, I have full intention of introducing an omnibus and learning the lessons from past attempts here, and I've been watching very closely what's going on in RIPE. But NRPM needs to be simplified. It needs to be able to be readable by a much broader audience and modernized for the future and I don't see a way around the big omnibus.

John Curran:  Brave souls seek out this man. Line up behind him. The tip of the spear. Okay. Right microphone, go ahead.

John Springer:  John Springer, Inland Telephone, speaking for myself only. This group is some of the most intelligent people on the planet, they run gigantic networks and hold concepts in their head that beg or believe in many cases, and so the idea that you can't wrap your head around a couple of pages of text is just laughable.

And joking about it in pejorative terms doesn't do anybody a service. We've seen what happens to these larger, more complex proposals, and I think it's a matter of laziness to attack such a thing on the basis of its structure rather than on its content.

And I very much am in favor of a policy process that solves a bunch of problems at once. And we ought to be able to meet the objections – meet objections that are just purely structural and recognize them as they are.

John Curran:  Excellent. That's a call to align yourself and get yourself involved in what David is going to propose, an omnibus change. Center front.

Chris Tacit:  Chris Tacit, speaking for myself. I want to approach this from the perspective of somebody who wordsmiths for a living. I'm a lawyer by trade. So when clients come to me for changes in text or for new text for anything, the first question I ask is:  What is the problem you're trying to solve and what are the parameters of that? What do you want to talk about; what don't you want to talk about?

So I think before even anyone proposes an omnibus of any kind, we should as a community take a step back and have some sort of consultation process about what are the objectives of the simplification.

Are we out to reduce the dependency on needs-based assignments and allocations? Is that an objective, as Dan has suggested to improve the accuracy of the registry in conversations we've had? Are there other objectives we want to pursue?

But I think it's important to have us step back so – I'm not sure how we'd do it, but I think it would be useful for perhaps the Board and staff to give some thought to a prior consultation process, perhaps online, and then perhaps to set up a working group to try and come up with something to present to the community that meets those agreed objectives.

Because, without that, whoever proposes an omnibus solution, it's going to be based on their own divination of what community preferences are.

That's the reason it's going to fail. Not because it's an omnibus, but because it's an omnibus not targeted to the priorities of the community as a whole.

I don't think there's a way to do this as a piecemeal exercise, quite frankly, because anytime you tinker with one thing you're creating something that's long and laborious and has unintended consequences.

So I do believe a wholesale review is required. But just to sum up, again, I think we need to step back, find a way, what are the priorities we want introduced into that before we go ahead and do it.

John Curran:  To note, any omnibus proposal would have to contain, just like any other policy proposal, a problem statement. The call that says there needs to be a problem statement is wise.

I don't know whether or not it's possible to get the whole community collectively to agree on a problem statement. But if someone is going to lead an initiative to do an omnibus proposal, it has to be the community.

Staff actually can't jump in, as you suggested. The Board can. They have the freedom to do so. But it's going to be important. Different people will have different views on what the problem statement of an omnibus rewrite is, what problems should we be solving. We have multiple ones submitted.

Chris Tacit:  My comment was directed to process, not contact. When I said staff and the Board get together, it wasn't to determine the priorities, it was to set out perhaps a larger consultation process that somehow is time limited where perhaps it would lead to a bunch of surveys that would follow each other depending on prior feedback.

I'm not sure what it would look like, but it's more about the process of trying to hone down the objectives to a manageable set of objectives that we as a general community can agree on.

And some of that may also have a bit of a background. Perhaps there's a background paper that could be done as part of that about what other regions have been doing to simplify their processes who are also engaged or have been engaged in this process.

So I think with that sort of informed process, we can take the fear – because I think it's a fear-based thing. The reason people are afraid to take on a big chunk is because of unintended consequences and unknown objectives. The more we can reduce that up front, the more I think we could succeed in doing that.

John Curran:  I'd like to hear more of this type of thing that, if has support, the AC could lead with staff support.

But this is a slight departure from our normal policy development; that you're asking for more guided, shaped approach. So it really needs to be something that you folks feel is important for it to be undertaken.

Rear microphone.

David Farmer:  David Farmer, University of Minnesota, ARIN AC. What he said, just to start with. And adding on top of it, what I would add is I think the problem here is we need a consensus out of the community where to go. And I think we need to have some conversations around that are. And if we have conversations around where we want to go, we might be able to come up with some text and might be able to have a conversation about does the text say what we want and does it describe where the consensus that we want it to go is.

So I think we need to maybe – we can't – we can't do it individual pieces, but we can't also do it in one giant frenzy of a conversation either.

I think we need to figure out how to break it up into pieces to talk about each of those pieces and figure out how you bring those pieces back together again to make a whole that we can all go, yeah, that's what we want. So I'll leave it at that.

John Curran:  Far microphone, 3. Sandra.

Sandy Murphy:  Sandra Murphy, PARSONS. I apologize to David. I am responding to something that was done the last time and I'm asking about the status. David Huberman stepped up to the mic to ask about the Relying Party Agreement, and the answer from the table was that the Board had a plan. Part of that involved in new Resource Services Agreement, and coordinating legacy and non-legacy, and that has happened.

I was wondering about the status of whether that's going to have any impact about the presence or the content or the need for Relying Party Agreement.

John Curran:  Yes. In the next two months, over the next two months I will be bringing a set of proposed changes regarding how we handle the agreements, the terms and conditions and agreements for RPKI to the Board.

There were actually two prerequisites required before I could do that. The first one was an RSA,/LRSA that was explicit in its indemnification clause, because if it's explicit in its indemnification clause, that's sufficient not to be necessarily repeated in a terms and conditions, a second agreement.

And the new item – that's the case with RSA and LRSA. The second item we need to look at the liability that was incurred and how exactly that would apply to our insurance. And that review has been done and has been conducted, and we're happy with the results.

So those two things have been taken care of I can now pick up the RPKI issue and move ahead. I don't know when the Board will have a chance to look at it and when it will be done, but it's back in play as of today.

Sandy Murphy:  I'll take that as good news. And so how will the results of the review be made known? Will it be meetings from the next Board meeting or –

John Curran:  We'll do an announcement – if we change the terms and conditions that are applicable to RPKI, we'll announce it on ARIN Announce, make sure everyone's aware of it.

UNIDENTIFIED:  These aren't the terms with respect to the RPKI; they're terms and conditions related to the party agreement.

John Curran:  Actually both items are actually effective.

Sandra Murphy:  Thank you.

John Curran:  Center microphone.

Milton Mueller:  Milton Mueller, Georgia Tech, also AC. So I want to go back to this issue of the omnibus or the general sort of reform. I'm very much in favor of that, but, frankly, in my recent experience with being on the Advisory Council and seeing proposals go through the meat grinder of the ARIN process, which is not necessarily to say there's something wrong with the process, but I'm a student of public policy and politics and what I see is a very general phenomenon, which is you have a general interest, which everybody collectively would be better off if we all agreed to do something, but then you have a narrow special interests who look at the situation very strategically, in a very short-term way, and it's extremely difficult in this kind of process to have these general interests override the special interests.

Particularly when the process is extended over time, it involves a lot of complex interactions and interdependencies.

I would urge us, first of all, not to be naive. We talk about the community here a lot. Again, being a political scientist, I view the community as a congress of different interest, which sometimes agrees, rarely, but particularly when I look at the way the needs assessment debate has been going, I get pessimistic about our ability to do a broader omnibus post exhaustion pool.

Because I understand the ideological debates and agreements, and I think those can be resolved based on facts and experience. But it's the strategic interventions that are kind of hidden-agenda driven that give me trouble. So when we have very large corporations talking about the way the absence of need assessments might affect the small guy, you know, my alarms go off and I'm wondering what exactly is going on there.

I think the community, if we're aware of this phenomenon, that we can in fact discount certain interventions and certain kinds of positions as saying we know why you're saying that. We as a community are going to look at the broader interest and move on.

Thank you.

John Curran:  Thank you. Two important points. One, we are T-minus seven minutes to ending for the day. The queues for the microphones will be closed very shortly. So if you wish to speak on Open Mic, find a queue.

We actually have 610 organizations that have our RWhois servers listed. Turns out that 42 of them are end-users.

So we do allow end-users to have – I was mistaken there. When I'm mistaken, I'm really mistaken. We do allow end-users to have RWhois records, pointers to the RWhois server, and it's 42 out of 610. The rest are ISPs. Obviously if folks don't think we should be doing that or if that's not applicable going forward as we move to things like RDAP, we need guidance from you folks. We generally are accommodating, though, if someone seeks that out.

Queues are still open right now. Microphone one, go ahead.

Matt Petach:  Matt Petach, speaking this time for myself.

I think one of the hidden agendas that Mr. Muller was pointing out briefly earlier – I'm just going to drag right out in the open because we've been talking around it – we have a dichotomy in our community. We have the end-users. We have the ISPs. The two terms have come up repeatedly.

Marla Azinger remotely has mentioned the concern about we're making concessions for one group versus the other.

I think coming to a consensus as a community is going to be fundamentally challenged by the fact that we really are at the moment two different communities. Now, when you talk about doing an omnibus rewrite to a simplified proposal, you're looking at a two-party system trying to agree on something that inherently has pull in two different directions.

I would say that the other challenge to this is the people in the room and the people that speak up at the moment as voting members of ARIN are largely skewed towards the ISP side versus the end-user because our model doesn't incent end-users to become full members of ARIN.

I would be very, very interested to see as we're working on an omnibus rewrite, if we could bring in more of the end-user voice and get a truer representation of both sides of this house so that what we end up with as a result isn't necessarily skewed one side versus the other.

That would be my main caution. Thank you.

John Curran:  I want one little comment. I'll also note that 10 or 20 years from now, while ISPs and end-users may be different because of what they do for a business, they fall along one spectrum of address space that's very clear. You don't have end-user assignments that are comparable to the largest ISP assignments.

So it might be worth thinking about what does itself look like 20 years from now when a v6 world and then go back figure out how do we have to deal with today's reality.

Center rear first.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC. So you mentioned that the relying party agreement and RPKI improvements depend on the release of this new RSA. Some of us have LRSAs that offer terms that are such that we don't want to give them up in order to get RPKI. Would we still need to be use the RPKI relying party agreement without having to sign the new RSA.

John Curran:  You can sign the existing agreements today, or you can wait for what comes out, but it will be dependent upon going to a new RSA. You have at two choices. Your third choice is not to use RPKI.

Center front, please.

Chris Tacit:  So just to follow up on the discussion we were having about how to sort of revise policy, there's an interesting phenomenon taking place, and it's kind of unique to ARIN, I think, right now because of the bottom-up nature of our policy process.

But we're at an interesting place where our strategic planning from the top down is going to intersect with the bottom-up policy making. And what I mean by that, specifically, is this dichotomy between ISPs and end-users is driven largely, for example, by our fee structure.

So it may actually be useful to stabilize and figure that out before we do some of this other consultation. Because I think that will perhaps take a whole bunch of problems off the table if we figure that part out. And that is something that's coming from the top-down.

John Curran:  I'm going to slightly note that the fee discussion is coming after a very long community-based process.

Chris Tacit:  I understand.

John Curran:  I don't quite buy coming from the top-down. But I agree the fee changes are relevant to what the composition of the community is over time.

Chris Tacit:  Fair enough.

John Curran:  I'm closing the microphones. I've got one, two, three – and I've got Scott. So go ahead.

Chris Spears:  Chris Spears, OARnet, legacy holder and ISP. So judging on the dichotomy of end-user versus ISP, I think the last number I saw said under 15 percent of the ORGs that ARIN serves are actually ISPs. That's a very large number of end-users and legacy holders in this region, and there isn't representation – I assume if we did a straw poll here the number of end-users in this room would be very small, and I'd be interested to know if ARIN has stats on how many people have not a poll tax but the poll tax to become ARIN members.

John Curran:  How many end-users are actually ARIN members who can vote?

Chris Spears:  Specifically that paid the fee –

John Curran:  Very small. I'll have to get the information.

Chris Spears:  The representation in this community and people on the Mailing List, everything is open –

John Curran:  Be clear. To be very clear. That decides who can vote for the AC and the Board. This policy process is actually open to everyone. And you might claim that if you've got 10,000 end-users, and a very small percentage of them got involved, they would outnumber the rest of you in this room and they don't have to pay to participate in the policy development.

So I agree with your representation argument, particularly when it comes to things like fees. It's not clear it applies to the policy process.

Chris Spears:  Absolutely, but I think we all understand that if there's a small number of people that end up participating, for whatever reason, it's still a very small number, and encouraging that group to participate is one way to do it. Making sure that they know they can before bringing them into the fold in another way is another way to do it.

John Curran:  Excellent. I've got literally most of the table up here in the queue. Remote?

Scott Leibrand:  Marla's comment was actually right on that topic. She says that there are far more end-users involved in the process than ISPs, and mentioned also that you have very large entities that are still end-users. There's a very small number of voting and active ISP members.

John Curran:  Kevin? Press the slow button.

Kevin Blumberg:  Thank you. That's the first time I used it.

There has been a lot of discussion on how we do this omnibus. The one thing that ARIN has taught me:  The larger the document, the more words it is, the more it will fail.

In other organizations where we've done ground-up rewrites, moving from one type of corporation to another with bylaws, et cetera, we've had a small teamwork on it with a very, very common goal. And as that team grew, it became more difficult and more difficult the bigger the document was.

I would say that a Section 20.0, complete rewrite, starting fresh with a whole new concept, would have more chance than a let's clean up Section 4. Because everybody remembers Section 4. Everybody has time invested in their aspects of Section 4 and feel that there is either legitimate aspects that will benefit their own business, legitimate aspects that will benefit the community, et cetera.

My only suggestion is, and why I was joking about the omnibus, because it's so real to me, is I would rather see 40 proposals that say omnibus Part 1 to 40, where each person says I believe this is something that can be simplified. I believe this is something and let the community decide if that person's idea of something that can be removed is valid.

To try to get us to change everything is I think going to be very difficult. More than happy to do something completely new. If we decide to get rid of need, as an example, and Section 4 is too complicated to change, we can start a whole new section or we can do a big addendum to something else.

But I think 4.0, the ship has sailed, the deck chairs have moved. Any bad example you want to use. I don't know that we can reinvest 15 years of our time and do it in six months or a year.

John Curran:  Paul, were you in queue.

Final remark is to our Chair.

Vint Cerf:  Thank you very much. Vint Cerf, Google. Two comments. The first one is can you say "CCWG"? Because that is an example of an attempt to do a very major revision of a very already complex operation, complex organization.

So even though that's awfully attractive to say let's start over, actually achieving that can be quite difficult. If a design team went off and said "This is what we think would work and here are the reasons why we think it would work," it might be interesting to look at that.

I would suggest that you not try to do it within the normal Policy Development Process as much as an exercise to see what it would look like. So that's one point.

The second thing is that as I listen more and more to our discussions and debates about the various policy proposals – I think I said this earlier today – I have this funny feeling that we have decided to put a stamp on this organization is an X. It's an ISP, it's an end-user. I don't know if we have any other categories in this taxonomy. I'm beginning to wonder whether taxonomy is exactly right and whether the actions that the organization does should dictate which policy applies to that action.

I'm not sure that I'm saying anything that's useful, to be quite honest with you, but feels like not stamping a organization with a particular category but simply saying if you do these things, then these rules apply. Might be a different way of trying to express what the policies are and how they apply.

Closing Announcements

John Curran:  Excellent. Okay. Thank you.

That concludes our open microphone session. Congratulations, everyone, for surviving the day. I'm now going to move to the close.

So, first, voting is open. Voting is open. If you're a voting contact, you may go and either follow the instructions on the election website. There's a help desk we have. Please reach out to any of us if you have help. Time to vote for the leadership, thank you.

I'd like to thank our sponsors, network sponsors Telus and Service Affaires.

(Applause.)

John Curran:  Webcast sponsor, Google.

(Applause.)

John Curran:  And our break sponsors, CIK Telecom, Bel Air, ColbaNet and ServerHub.

(Applause.)

Okay. Tonight's social. Cirque Eloize. Buses leave from The Fairmont side entrance, and make sure you have your social badge. It's in your badge here somewhere. And you just - yeah, looks like that. And return shuttles start at 8:30. Remember to be there ten minutes in advance so we can help you board.

Meeting survey. You'll get an email with the link. Or go now. Fill out the survey, let us know how we do. That's how we address anything that might be improved in these meetings.

We will enter all the responses in a lottery for an Apple iPad Air 2. For non-staff. Staff, I don't even fill out the meeting survey, because I'd filled that out a few times entered. But enter the staff and enter the survey and let's get feedback.

Reminders. Breakfast tomorrow 8:00 a.m. We'll continue our Public Policy and Members Meeting at 9:00. We have a number of policies on the schedule. Lunch at noon. And then Members Meeting where we get updates from the department, the Board, the financial report. Should be very good.

All the meeting materials are online. Look forward to seeing everyone here tomorrow. If you didn't pick up your tee shirt, good time to do it before you go back to your room.

Thank you, everyone. I'll see you at the social tonight or tomorrow.

(Applause.)

(Proceedings adjourned at 5:06 p.m.)