Table of Contents
- Members Meeting - Opening Announcements
- ARIN Reports: Engineering
- ARIN Reports: Registration Services
- Advisory Council Report
- ARIN Financial Report
- Board of Trustees Report
- Open Microphone - Members Meeting
- Members Meeting - Closing Announcements and Adjournment
Members Meeting - Opening Announcements
John Curran: If people will come in and be seated, we'll get started.
I'd like to welcome everyone to the ARIN Members Meeting. We're going to go through Registration and Engineering Department Reports, our AC Report, Financial Report, Board of Trustees Report, and an Open Microphone session.
So at the head table we have the ARIN Board of Trustees -- I should know these people -- Paul Andersen, Bill Woodcock, Bill Sandiford, Patrick Gilmore, Merike Kaeo, Aaron Hughes, and we have the Chair of the ARIN Advisory Council, Dan Alexander.
Okay. So, first presentation we have is the departmental update, and it's going to be Mark coming up to give the Engineering Report.
ARIN Reports: Engineering
Mark Kosters: Thank you, John. So let's go ahead and get into the Engineering Report. So, first of all, a summary of the people we have on Board.
In Operations, we have 15 people. In Development, we have 15 people as well. In Systems Integration, we have 11. Project Manager, we have one and a half. And actually with the half a person, I really want to show everybody here that she's actually a whole person, but she's only working part time.
So, Sherrie, if you could please stand so we can all get a proven experience that you are a full person. Thank you.
So back to the Operations staff. We actually have one opening. So if you do know someone who is fairly eager to get in the door on ARIN, we'd love to hear from you.
Okay. So accomplishments since ARIN 39. Every ARIN Online release that we put out, we have made changes to our user interface. And one of the things that we're doing is we're using a bootstrap framework. So we're moving things around and making it more user friendly as we go through it.
And I think many of you have talked to the User Experience people out there in the hallway, both Jesse and Jan, and they are focused on making the user experience better.
So we've had many improvements to our customer service internally to make our operations more efficient as well. And you've already heard about 0/0 for RPKI, as well as we've done transfer logs. And both of those are NRO initiatives that we've all coordinated between the regional registries.
Finally, we were forced to move to Java 7. We were running Java 6. I'm glad to say we've moved to Java 7, which is also out of support. But we have moved to Java 7 based on some payment vendor requirements that we had to put in. We're in the process of moving to Java 8, but Java 9 was just announced. We'll see.
Okay. ACSPs. You see here that we've done four ACSPs and one policy-related pieces of software that we had to go ahead and change.
Operational achievements. I'm happy to say that we had a security audit. There was no penetration. The guys tried and tried and tried, they tried for like six months, actually trying to break into our network, and were not able to. And it wasn't until we actually put a box inside our network, were they able to get any sort of exposure whatsoever.
And it was only when they put that box on the protected network, as well. So when we moved into our new building, we did a network redesign internally and segmented the network much in a better fashion, and actually came shown through pretty well. So we were all very pleasantly pleased with that.
We're still working on technical debt. We had three monitoring systems. We're down to one now. So that's great. We've had three configuration management systems, and we're down as one as well, and that's in progress. So we have lots and lots of work to do both on the development side as well as operations side.
Here you can see our ARIN Online usage. It's pretty consistent in terms of number of additional users that we see on a yearly basis.
Here's our active usage of ARIN Online. And what's interesting about this, is again, you see a lot of people do the one and done, and they are done. But we have a lot of people that come in, and actually what's interesting is there's a number of power users.
At some point I should probably show this on the graph, the number of people that have come in, looks like on a daily basis, which is pretty interesting.
But you can see that there's quite a few users, just north of 20,000 users, that have come in and are looking at ARIN Online on a pretty frequent basis. So I think that's a great thing.
Here's our Reg-RWS transactions. So we support both templates as well as RESTful API for doing reassignments.
This is a cumulative report. You can see that there's growth on both sides, both on templates as well as Reg-RWS stuff, but of course the Reg-RWS stuff is growing at a greater rate than the templates. But I'd love to certainly see at some point that templates would actually start to like even out and so that people actually move away from templates.
So I encourage you who are still using templates -- Owen -- to actually start looking at this, because it's actually a more secure way of actually doing business.
Here's our DNSSEC report. We've had seven additional Orgs come in to use DNSSEC since the last meeting. And out of 622,155 delegations we have, we have 861 that are secured with DNSSEC.
So, the percentage-wise isn't all that great. But then again, if you look at com and net, that percentage is also not so great. But you can see people are starting to play with this more, and that's great.
RPKI usage. Again, you can see that we have a certain linear growth going on here. It's not huge. One of the things that's flatlined is the number of up/down delegated. Most people decided to use hosted, which means they use our certificate authority, they use our UI; we do all the heavy work behind the scenes to make sure that RPKI works.
And I think this is fairly true with the other regional registries as well. The hosted process is a much easier to use and reflects by the usage as well.
And Whois-RWS queries per second. You can see that we had a spike a number of years ago now. I think it was right after I started. That was quite amazing. And it actually bottomed out, but one of the things that's kind of interesting, is it's starting to grow again.
Why? I'm going to have a slide about that in a little bit.
Here is Whois-RWS and RDAP queries over v6. You can see that percentage-wise we're in like the 5 percent range, and that seems to not change very much.
RDAP. You can see here again that it doesn't have a huge amount of usage yet. But there are times where people just say, oh, this is great, I'm going to use this for a while, and then it comes back down again. That happened a couple of years ago. And, again, you can see that it has a linear amount of usage.
So here's the question I wanted to get to, and that is -- we still see abuse. We still see abuse against our directory services. It occurs. Occasionally we get alarms. We go on the system, see that someone actually really pummeled this, and then moments later it goes away.
Then we start looking at the logs because it's like: What happened here? What's going on? We need to figure this out.
And we noticed that, well, okay there was an offender who came in, maybe he had a broken script, maybe he did something kind of wrong.
But as we start looking through the data, there's a lot of people working below the line, right, on scraping ARIN's directory service for information.
And there are interesting queries. There are queries for all the organizations they see within ARIN. There's queries for all the POCs that you see within ARIN. And of course there's network queries and autonomous system queries as well.
So there's just very interesting things to do. So the question that we continually think about is: What should we do about this? Should we just leave the status quo? Right now, frankly, we don't have a rate limit. So if it hurts us, we'll basically kind of hurt you back by turning you off.
But we don't have any real sort of rate limiting put in. We don't have any sort of behavioral learning that we're looking at in terms of what are you doing with these queries.
And if we did, if people really did want this, should we allow bulk access and should the AUP for the bulk access be sort of loosened for those people who want to be a part of this?
So these are questions that we have, that sort of impact us operationally.
Getting back to it, here's our IRR stuff that we're going to be starting to do next year. You can see that the number of maintainers keeps on growing. Again, it's linear growth. Route and Route6 objects keeps on growing as well, and InetNum and Inet6Num keeps on growing as well. Not by as great a degree.
Here's an interesting slide that I like to bring up, is the number of organizations that actually use IRR. There's a couple of really heavy hitters that use the IRR. And there's a lot of people who sort of play with it sort of below the line, especially when you get down to the people who have one to four objects in it. But -- this system does have some use.
So what are we working on through 2018? We're working on CKN23 POC restoration. We're working on automated software coupled with fully redundant services so that we can go through the process of doing updates and not letting you know that, hey, we've got to take the system down for about eight hours as we do our upgrades.
We're working on our OAuth integration within RDAP, so people can get unlimited query responses based on if they've been authenticated. We're also putting this in ARIN Online as well to remove a timeout issue. Right now, if you log in to ARIN Online, the timeouts are based on your particular session on the server. What we like to do is we like to move that to the client, and we're going to use OAuth to make that happen.
And, of course, the UX engineering. Hopefully many of you test drove, experienced a test drive with both Jan and Jesse in the back. And I hear that Jesse is pretty good with dealing with things with balloons as well. So he was working on balloon things last night at the social.
Don't ask me what those things were.
So, IRR work. We'll start that in Q2 of 2018 as well. We have an accounting system upgrade we have to do that doesn't involve you too much, but it's just internal infrastructure stuff we have to do.
And, of course, we have technical backlog. As Nate mentioned, this is stuff that's behind the scenes that we haven't spent a lot of time and attention that we need to actually work on now. From Java 7 to Java 8, maybe Java 9. Moving to a stateless application service, as I mentioned before. Moving to OAuth, using with ARIN Online. Using automated build systems using Ansible, which we're very much underway, and that's working out quite well. And replacing end-of-life boxes. We have like a bazillion end-of-life boxes, boxes that are getting up there in years that we need to replace.
We've also done a lot of coordination work over the past year with the other regional registries. As I mentioned, transfer logs is something that we all agreed between the regional registries on the format and the way the placement of such and how these things are to be handled.
And that's been very useful. The transfer logs, along with our -- what's called extended stats, gives you an idea of each regional registry's inventory, the space that they have, and the movement between the regional registries as well.
And, of course, we had the trust anchor alignment for using 0/0. And the thing that impelled this was not only the technical reasons that we heard a little bit earlier from John, but also it gets us a better alignment, because we had three different ways of describing the trust anchor before we aligned on 0/0 here.
So, with that, I am done. Any comments?
David Huberman: Hi, good afternoon, Mark. If you go back to Slide 18 or 19, please, which was the IRR slide, the number of users. That one. No, one more. Forward. 18. The other way.
Mark Kosters: Maintainers? Which one are you looking for?
David Huberman: Go forward three slides, please. Thank you.
Mark Kosters: Okay. Got it.
David Huberman: You made a comment, which is why I'm here. You were talking about the power users up at the top.
From my perspective as an operator, it's those three categories at the bottom that are the most critical users of the IRR. Without those 1-4 entries, or from a little bigger, the 5-9 or 10-49 entries, I can't get my route announcement accepted by a transit provider or a peer because so many require an IRR registration.
And many people choose to use ARIN, since it's free and it's somebody they know and somebody they trust.
So, while there is certainly some interesting things about those folks, those 52 organizations up in the top, I would submit to the ARIN Engineering team and Management that it's actually all those users at the bottom who are the real critical users of the IRR services and get a real community benefit from it.
Mark Kosters: Thank you very much, David.
Kevin Blumberg: Kevin Blumberg, The Wire. In regards to the CKN23 restoration, first question is if somebody is intentionally being asked to have their record removed because they have nothing to do with it and you move it to CKN23, how is the restoration going to work? What will you restore the --
John Curran: I'm sorry. They asked to have their record removed?
Kevin Blumberg: I'll give you the example. I was flying through an airport, legacy space, so it was all CKN23 because it showed me as an unknown location. Took a look, and it said updated 2017. I'm like: It's all unknown; how could it be updated recently?
And the answer back was it was updated recently because the last valid POC was -- asked to remove because they had nothing to do with the organization.
On a restoration, how is that dealt with?
John Curran: Okay. The text that we're on -- and then the record will be --.
Kevin Blumberg: But this person has specifically asked to have their personal --
John Curran: If they've specifically asked, then, no, they will not be restored. We have about 30 blocks that that qualifies for.
Kevin Blumberg: Okay. Thank you. So that's the first question.
The second question is: When was the last time ARIN reached out to try to get POCs updated in legacy from all CKN23s? Is this something -- it hasn't been done in many, many years.
John Curran: We have not done it because -- well, right now they're not associated with the blocks because we've removed them from the block and put CKN23. It's something we're quite capable of doing once we get to the other end of this update, when we restore the contact information.
Kevin Blumberg: I understand. But in this particular case, the Org information looked very valid, and getting that Org to update is -- to create POCs -- is
John Curran: Right, is the priority.
Kevin Blumberg: Is the priority. And I'm just wondering if that's something that you're looking at doing at some point.
John Curran: Once we get to the other end of CKN23, that's one of a number of things we might want to do.
Kevin Blumberg: Thank you.
John Curran: Any questions for Mark on the Engineering Report? Yes, go ahead.
Jason Schiller: Jason Schiller. As a follow-up to what Kevin was just talking about, it occurs to me that there are people that research this information as their day job. Could we not hire someone and put them on retainer and have them start going through the Whois and pulling records and trying to build the chain of authority?
Because I think there are a bunch of organizations here that if you reached out to them and said, look, your record says you're organization A, we know that you're organization B and we've pulled all these records and it looks like there's a chain of custody here, if you tell us this is right, you can click this button, and your records will be updated.
John Curran: Well, so there's actually a number of companies --
Jason Schiller: I would pay for that, by the way.
John Curran: There's a number of companies doing that activity right now. There's a whole list of companies who are doing that work and then calling them up and saying you look to be the successor or rightful rights owner to this address block. I can help you with making something useful out of that.
And so we already have -- why would we pay for something that already has a dozen organizations out there doing it?
If you look at the transfer facilitators list, many of them have whole shops of people on the phone doing that thing.
Anything else for Mark?
Okay, thank you, Mark.
Okay. So next up, we have the Registration Services Report with John Sweeting.
ARIN Reports: Registration Services
John Sweeting: Okay, good afternoon, everyone. I'm John Sweeting, the Senior Director of Registration Services, and I'm going to give an update on the Registration Services Department.
First off, I'd like to recognize the team. The only other one in the room right now is Lisa back there. If you can stand up real quick, Lisa. But Lisa is the heart and soul of the Registration Services Team, along with Cathy Clements, who is back actually taking care of the office and getting the work done.
The names that are bold there, Misuk and Eddie, I hope everybody has had a chance to go by the help desk outside and talk to them, at least say hi. I know some of you are shaking your head because you've been there a lot. And others, if you haven't had a chance, just tell them how much you appreciate them, because they do a lot of work for you.
Okay. The core responsibilities for the Registration Services Team, of course, is Internet Number Resources -- IPv6 requests, autonomous systems and IPv4 requests.
That is the core responsibilities along with now we have this new thing -- well, I guess it's not that new, but it's actually taken over as the most time-consuming task that we concentrate on, and that is the change of authority transactions, which are, of course, better known as transfers.
And in ARIN speak, there are 8.2s, 8.3s, and 8.4s, but the full-blown names are mergers, acquisitions and reorgs; specified transfer within the region; and then the inter-RIR specified transfers. And we also spend a little bit of time maintaining the Specified Transfer Listing Service.
Other things is the Internet Number Resource Inventory Management, which takes up a lot of time. We have basically one full body that spends almost all of his time looking through the inventory, making sure that we're taking care of all the inventory resources, finding some of the things that kind of get lost in the mix and making sure that we bring them back out into the light of day.
And he manages the wait list, everybody that goes on the wait list. We have people that come off the wait list, just some because they have gone out and found a transfer and fulfilled what they needed; others that say they've waited too long and they don't want to wait any longer, so they just get off. And it's a lot of work, taking care of the inventory. It's a very large inventory.
And then customer support. We have our telephone help desk that's open 12 hours weekdays, 7.00 a.m. to 7:00 p.m. Eastern Time, and we also have Ask ARIN by submitting an ARIN Online ticket.
One thing on the telephone help desk, we did recently look at possibly shifting hours, changing hours, adding hours, and believe at this time we're going to stay steady with what we're doing.
So if anybody does have any input on that, you can let us know through the Feedback button on the ARIN website or stopping by the help desk or just finding me and saying you have some concerns with the hours of our coverage, and we'll be glad to look at that again.
Some of the support functions that Registration Services performs is policy development and implementation. We do all the staff assessments and the implementation plans.
Software development support. We spend a lot of time with the Engineering Team providing requirements, doing testing, feedback, providing information that we get from the help desk on the calls there and providing that to the Engineering Team, writing up stories. And we spend a lot of time with the Engineering Team to make sure that we meet the requirements of you, the community.
Outreach -- ARIN on the Road, trade shows, presentations. We usually have -- we always have at least one person at an ARIN on the Road. Jon Worley is usually that person, although Eddie Diego has been participating in some of them this year. And that duty will probably be split between the two of them next year going forward.
Let's see. Statistics and database analysis. We collect and provide monthly statistics that get put up on the website and that I then also present to you here at the meetings every six months or so.
And we also respond to the community or the Advisory Council or anybody that really wants to know something about the numbers, they can put in a request, and we are glad to perform that, if it's possible.
Okay. So first that is organizations served by ARIN. You can see we have 43 percent of the organizations we support are not under any kind of agreement with ARIN, and therefore there's no fee associated with those organizations.
And then the other 57 percent of the -- the other 57 percent, 42 percent of them are end users, and the other 15 percent are under Registration Services plan, with the majority of that being your ISPs. There are some users that have opted to purchase a Registration Services Plan, and basically what that does, it turns them into ISPs. They have all the services available. They get their assignments turned to allocations, and they're automatically a member. And any of the other services that are associated with the ISP, we now call it RSP.
Resource requests per month. This is -- basically just shows from just prior to depletion, where we were with the IPv4 requests, IPv6 and the AS requests. And as you can see, IPv4 has taken a dip after that but then has remained steady across time at approximately 100 requests a month.
And ASNs and IPv6 have basically stayed pretty flat across the months. I'll get to another slide and talk about the IPv4 requests.
So the IPv4 requests results, to date we've had -- well, until August 31st, we've had 668 completed IPv4 requests.
186 of those went on the wait list, 387 of them were closed, and 95 were filled. The ones that were filled were mostly under NRPM 4.4 and 4.10, which is your reserve for critical infrastructure pool and your reserve for IPv6 deployment transition pool.
The closed are basically people that came in, requested IPv4, and when it got to the end and they were told they needed to go on a wait list, they weren't interested in going on the wait list.
So I'm really looking at an initiative right now to, when somebody comes in for an IPv4 request -- believe it or not, there's people out there that don't know that we don't have IPv4 addresses available to give to them.
So we're looking at an initiative right now to make sure when someone comes in for an IPv4 request, the first thing we go back to them with is: You do realize that we're going to go through all this, and then we're going to ask you to go on a wait -- we're going to ask them up front if they're willing to go on the wait list instead of waiting until the end of the process to ask them that.
So maybe requests will stay at 100 a month, maybe it will drop down to 50 a month. I don't know yet, but we'll see.
Waiting list status. This is from the beginning of the wait list. There's been 799 waiting list requests. I know there was people that asked for IPv4 and that accepted to go on the wait list. 187 have been closed, either through transfer or they just took themselves off; 342 have been filled, which is 43 percent; and still waiting is 270, or 34 percent.
Registration Services Plans. So these are your ISPs or end users that have decided to pay for the privilege of having all those services associated with being an ISP.
This is their IPv4/IPv6 holdings. 46 percent of them have IPv4 and IPv6, 9 percent have IPv6 only, and 45 percent have IPv4 only.
And the answer -- somebody asked the question yesterday about legacy being contained in the numbers that I put up from all the RIRs on the NRO Report. There is no legacy included in that. It's actually members, which was the title, and members, these are our members. So this is where the 55 percent come that have IPv6.
When you go to end users, it's a much different story. IPv4 only is 76 percent, IPv4 and IPv6 is 17 percent, and IPv6 only is 7 percent. So of our end users, only 24 percent have IPv6 addresses.
This slide just kind of shows the shift to transfers. If you see back there at the very start, the IPv4 requests were filling most of the requirements and requests for IPv4, and today it has kind of turned upside down to where they're almost all -- all the IPv4 is being transferred or it's being gained through the transfer process.
Transfers completed per quarter has really gone up dramatically. And I actually have numbers for third quarter of this year. I just got them, like about ten minutes ago.
There were 636 filled requests. And of those, the merger and acquisitions were 141, the specified within ARIN region was 461, and inter-RIR was 34, for a total 636.
So we're pretty -- I'm not sure. My theory is that we're going to see that we're going to stay around that 6- to 700 number, because I think we're at the point where we have reached capacity of the system's ability and the department's ability to get it through, and that's why we're looking at the transfer log and some other good areas to automate this process.
But right -- now some fly right through. I can tell you, those are the ones where it's been a direct allocation or direct assignment from ARIN, and we can see the chain of custody very easily, and it's real easy to get that paperwork in and approve it.
However, most of the transfers are not those addresses. It's actually the legacy addresses that take quite a bit of time to get the legal documentation. They've changed hands. The rules were a lot different back then.
So in order to make sure that we're actually doing the right thing, it takes a lot of time to get the proper documentation in place to know we're doing the right thing.
Customer support. As you can see, Ask ARIN requests are pretty flat throughout the months. We get around 200 a month.
Hostmaster emails. There's a glitch there, and the glitch is we just weren't counting them right up until April when we found out that the number we were reporting on was the number that one person was actually -- that was putting the numbers together was only putting the numbers together for the requests they were supporting.
But he did most of the support on them, so -- but there were other people answering them, so we had to make a slight correction. Full transparency there.
And then the help desk phone calls. Telephone help desk. I've already told you we're from 7:00 to 7:00 Monday through Friday. Average wait time is 17 seconds, and the most common topics are POC validations. Whenever the POC validation emails go out, phone calls increase.
Ticket status is pretty steady on those questions. ARIN Online use is pretty steady. Transfer-related questions, pretty steady. We do get -- when invoices go out, we'll get an influx of calls, of course, asking about that, as well as FSD gets the same thing.
Then I have one more slide. I was asked about information yesterday on the -- I think, Jason, you asked it -- SWIPs that were requiring reviews.
These are your numbers for /20. There was a total of 494, of which 389 of those were self SWIPs; and /19, 272 self SWIPs and /22 to customers; /18s, 136 -- so I guess the gist of this is if you -- I think your point in the question was, well, if we changed the boundaries there, what would it do to the workload.
And I think you can see shifting the boundaries a little bit would drastically reduce the workload.
Let me just say a few more things. So I'm just finding out that we have a slight -- I'm new, I've only been there for a year. I'm just finding out that we require the self SWIPs. There's a policy that says that people, cable companies, anybody providing access to residential customers and they use pools of addresses have to self SWIP those pools of addresses to themselves.
Basically they come in, they ask for the addresses, and they use their residential customers as the reason for getting the addresses, and we approve it and give them the addresses; then they need to move those addresses to where they already told us they needed them. And we make them do a SWIP to do that, and we make it come in, and we have to look at it and approve it.
So, anyway, just wanted to throw that out there along with the numbers. And this isn't a policy discussion here. We won't talk about policy. But that is some good information to go back and look at.
And that's it.
John Curran: Owen.
Owen DeLong: Owen DeLong, ARIN AC, Akamai. If you go back one slide, as we look at solving this problem, it seems to me that we could probably accomplish more by -- in terms of ridiculous workload reduction -- by, instead of moving bit boundaries around, exempting self SWIPs from the review policy.
Would that be a more effective solution, do you think, or is there some reason the AC should consider preserving your idea of bit boundary manipulation?
John Curran: You should be answering that question for us; not the other way around. To the extent that --
Owen DeLong: I am asking for staff input on which of the two solutions would achieve the best outcome for staff in terms of removing what is superfluous workload.
John Curran: Obviously, if you remove customer self SWIPs, you can see what that would do by dropping workload. If you move the bit boundary, you can cut off columns and see the same things. That doesn't answer what's a good policy outcome.
Owen DeLong: Sure.
John Sweeting: Yeah. And just -- the real thing about that on the Policy Experience Report was a lot of it was -- part of it was that the actual categories of ISPs, they don't exist any longer. And the other thing was that is -- was that is it necessary to even have this anymore. So that's a policy discussion: Needs to go away until the next policy or take it to PPML.
John Curran: Next mic over here.
Matt Petach: Matt Petach, Yahoo!. You were talking about the transfer rate kind of capping off around the 600s, basically being the carrying rate that the staff could accommodate.
One piece of information that's missing from that is when your throughput on a link starts to flatline, usually what happens is the buffer starts to fill. Do you have stats on the latency for how long it takes to process -- the average latency for processing those transfer requests?
John Sweeting: Yeah, so it isn't just the capacity, it's the capacity of the whole system; meaning the brokers that work on the transfers and put them in, as well as staff. And the buffer is still -- we're still maintaining our SLA of at least less than 48 hours turnaround on replies back to it.
Matt Petach: Is that SLA something you report on percentage within SLA?
John Sweeting: That I report to my boss, yes.
Matt Petach: Is that something we could have included on the transfer slides in the future?
John Sweeting: Absolutely.
John Curran: Front microphone.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. To Matt's comment, I'm guessing what that means is that the world needs more IPv4 workers. That's a comment.
You mentioned that the phones get busy when the POC validation emails go out. Was that a statement of an issue, or merely an observation?
John Sweeting: It's a statement of fact. Because people are wanting to know why they are getting emails from ARIN when they don't have any relationship with us.
Chris Woodfield: Am I correct in assuming this means these emails go out in a semi-regular bulk blast, like a monthly? Or how often do they go out?
John Sweeting: Monthly. And I don't know what the exact number is monthly, but it's quite a few.
Chris Woodfield: My suggestion would be -- an obvious solution to that to me would be: Try to send them out in a far more steady trickle, possibly.
John Sweeting: Yeah, I think I showed numbers yesterday where we have -- it's over 500,000 POCs that need validating, so divide that by 12.
Chris Woodfield: Thank you.
John Curran: Okay. Center front.
Cathy Aronson: Cathy Aronson. Two things. One, the self SWIPing thing is an artifact of like the original cable policy, and it was never intended to cause a second review. I mean, it was basically so that we could justify our blocks because we weren't SWIPing them to customers; we were using them in our own infrastructure. So this seems like kind of an unintended consequence, perhaps, of the original cable policy.
John Curran: As I said, we can talk about what (indiscernible) would be dropped by. It's not an answer of what's desirable or useful policy outfit. You should find a member of the AC and ask if this serves any purpose.
Cathy Aronson: That's fine. And then the second thing, if you go back to the transfer types per quarter, or whatever that was, can you talk about how many of the inter-RIR transfers were into the region versus out of the region?
John Curran: I can tell you they are 90-plus percent out of the region. I can do a quick look online. The transfer stats are all --
Cathy Aronson: It would just be interesting to have that because of the policy discussions that are going on about -- one-way transfers.
John Sweeting: You're absolutely right, and that will be -- we will put that in the next report for sure.
Cathy Aronson: Thanks.
John Sweeting: I do know, it is extremely low.
John Curran: Center front.
John O'Brien: John O'Brien, University of Pennsylvania. You wondered: Who are these people who don't know we're out of IPv4 addresses? Well, clearly they're the same people who are operating validating DNS resolvers and don't realize we're trying to roll over the key.
John Curran: Center front.
David Huberman: David Huberman. In June, we implemented a -- you implemented a policy that we passed to begin removing needs testing from certain transfers, specified transfers. And the statistics that informed that discussion showed that almost all of the specified transfers would fit into this policy.
So, I'm not going to put you on the spot now, but I'd really like to start seeing some data out of ARIN that talks about the impact of that policy into the transfer workflow and the extent to which it is easing it for both transferrers, transferors, and ARIN as the registry. You know what I mean?
John Curran: Yep. So if you look at this chart, that shows the transfers completed, but it doesn't show the work to approve those transfers. The team handling that workload is flat over this period. Okay? So the good news is that we have been able to handle that increase.
We were significantly loaded in the first quarter of 2017. We were at a situation where it was unsure whether our SLAs would be meetable because of the large number.
At this point, I'm not sure we're seeing that now, John?
John Sweeting: What's that?
John Curran: Our ability to keep up with the transfer workload under the current policies.
John Sweeting: Yeah, we're able to keep up. But it's the whole system. Realize there's two parts to every one of those. There's a source and there's a recipient.
David Huberman: Okay, so. But I'm not talking about that. I'm talking about the fact that we now have a policy that allows the staff to do a whole lot less work during the transfer than was done previously for all of the years previously.
John Sweeting: Because? --
David Huberman: You can now qualify for up to a -- you can double the amount of space that you have up to a /16 with no needs test.
John Sweeting: But you still -- you still have to open the ticket. You still have to go through the ticket. It did take some of the work away. I'm sure -- I refer -- I prefer to have Lisa answer exactly how much. But realize that it still has to go through all the same steps.
So it did reduce some, and that's why we're able to keep growing how many we're completing and staying within the SLA, as John said.
John Curran: So, if we could qualify the transfer requests into two categories, all those transfer requests where the source is unequivocal, and the recipient is qualified, versus all the others, I think you'd find the turnaround time for that first category and the staff effort for that first category is remarkably low. However, very few qualify there.
So there's a lot of handoff back and forth. If you were in Registration Services, you'd know we spend a lot of time going back -- oh, you actually were. We spent a lot of time, David, going back and forth with people who have incomplete requests. That hasn't changed. But the staff component of actual work qualification in that whole dialogue back and forth is much slower.
So we really have most tickets in wait state, waiting for someone to come back to us for the next request. We don't spend a lot of time -- there's less loops because we're not asking for more information, but that doesn't solve chain of custody, who is the authority for the resource. That still has to go through.
So all of these transfers, many of which are legacy, we're still spending a lot of time making sure the person who's trying to transfer it has legitimate rights.
David Huberman: Okay. I want to make one more comment. I apologize. So going to the SWIP review stuff, twice during this meeting, John, you've pretty -- you've been pretty clear that you're trying to tell us that you think this might be a bit of a waste of the staff's time, but you haven't told us -- I mean, that's what I'm hearing, and you sort of haven't told us why you think that might be the case.
If the staff experience in reviewing SWIPs that aren't to the self, that are reviewing large SWIPs to other organizations is not actually useful in the proper management and stewardship of the IP address space, there's a staff experience that would be nice to have reported on that.
John Curran: So, be clear, you have to -- at the end of the day, there's a sort of give and take here. If you ask us to go look for this information on utilization and then, it's not there because people haven't been doing SWIPs and we haven't been reviewing SWIPs, then when these address blocks come back in for some other purpose, to be validated or because there's resources coming, and we do have to validate all this, there will be a surge.
But we don't know now, there's not a lot of cases where we're looking at the usage of address blocks anymore. So it's, do you want this information to be reviewed by us, you the community. If you do, it's not a waste of time. But we don't need it to fulfill the policy.
We're doing it now because it says we have to do this for policy. We don't need it to do any other part of NRPM. The only reason we're doing these is because you've asked us to do it per that section of NRPM. It's not required for good management, if that's what you're asking.
David Huberman: Okay, so just to be crystal clear. This policy -- the policies that govern this -- predate NRPM; they've been around since the beginning.
John Curran: Right.
David Huberman: And if I'm understanding you clearly, and I just want to make sure I am, you're saying that the evolution of the NRPM has made -- potentially made this extraneous.
John Curran: No. What I'm saying is we don't have any way of assessing its value; you have to tell us its value.
John Sweeting: We're providing the point of information.
John Curran: We're providing this data because -- we're doing these records of updates for you. We're working with the policy and asking people to do these changes. But we don't have to do these if you don't want to. Do you want this information in the database? Is that valuable to the community?
On this same topic?
Cathy Aronson: Yes. This is Cathy Aronson. Part of this, as I said before, is from a policy that Kim Hubbard and I wrote with Jon Postel that precedes ARIN, the NRPM and all that stuff. And it was how we justified cable blocks for cable providers because we didn't have policy.
So some of this like was never intended to be this. And if the AC wanted to make it go away, that would be amazing, because it doesn't need to be there.
And that's the light green part, most of it.
John Curran: We're doing this because apparently it's something we're supposed to be doing. It serves a function, we should be doing it; if it doesn't, we shouldn't. But the only people who can ask whether this is a valuable function is you.
Cathy Aronson: Right. And I'm saying that this was a valuable function in 1997, but maybe not so much now.
John Curran: Okay. And David Farmer, last question.
David Farmer: David Farmer, University of Minnesota, ARIN AC. Can you back up several slides to the members and v6 holdings. One more, I think.
That's the one. So you have the v6 only, and that makes sense at one level -- for like there's going to be -- I know an organization that is a legacy holder and has only a RS, Registration Services Plan for IPv6. But it's a little disingenuous to say we don't have IPv4, as well.
John Curran: This is done by organization, and you do have to realize, there are some parties that have multiple Org IDs for whatever reason.
David Farmer: And what I'm asking is: You force us to have multiple organizations, a legacy and a non-legacy --
John Sweeting: This is for our RSP organization --
John Curran: You can consolidate them all up if you want. I don't -- certainly I encourage you to consolidate, David.
John Sweeting: There's no legacy holder without an LRSA that has an RSP.
Paul Andersen: But I think this topic is getting out of this.
David Farmer: Never mind.
Paul Andersen: And we should move it to the Open Mic if it's still a topic.
John Curran: Let's hold this for the Open Mic. That was the last question. Okay? Thank you, John.
Okay. Now, we're now moving into the final few reports. Next one, Dan Alexander, the Advisory Council Report.
Advisory Council Report
Dan Alexander: Hello again. Hopefully at some point this week everyone has had a conversation with one of your AC members here and let them know what you thought about all the proposals being discussed this week.
Our main purpose, of course, is here to get your feedback on how to move forward with some of these ideas.
We do this monthly on our calls, and we work on our Mailing List and we work on the Public Policy Mailing List, but there's definitely an efficiency to have everybody in the room talking at a social or in the hall. So hopefully you've had a conversation with them.
The whole point is for us to take these ideas, advance them -- or develop them into draft proposals, take those draft proposals and evolve those ideas into real policy language that we would recommend, eventually get to Last Call and recommend to the Board for adoption.
We've actually recommended two proposals to the Board of Trustees for adoption since the last meeting in April.
There's been four proposals that have been abandoned since April. Not only because they lacked community support, but some of those proposals that were abandoned were actually evolved into other policy proposals that are currently on our docket as the wording or the approach evolved.
There's four new proposals that are currently on the docket that came into the AC since April. Those were all discussed here this week.
One other thing I was going to mention that has happened since April for the AC that was a little different than our normal routine was the AC has a number of ways to collect feedback from the community. And this is being one of the main ones. This is a rather large production being a Public Policy Meeting.
We have a scaled-down approach, which is called the Public Policy Consultation, or a PPC, that we can have at NANOG which is actually incorporated into the Policy Development Process where we can get official feedback from the community.
But even that can be overwhelming in some cases when we want just simply to get specific information about maybe a particular proposal.
So what some of the shepherds did in regards to 2017-3, the POC validation, they were curious about the approach where the original text actually suggested rather than just disabling the online account, the original draft of the proposal suggested removing DNS records for unvalidated blocks.
But they wanted some additional feedback, so they actually went to the NANOG meeting with this idea. And the AC worked with staff and the NANOG PPC and actually got a presentation slot on the ARIN agenda -- or, not ARIN, on the NANOG agenda -- in June, did the presentation and got really valuable feedback from the NANOG community, which in turn impacted the wording and changed the proposals.
It was just a really good example of everybody working together to get some valuable feedback.
Overall, the workload within the AC is around medium. It's not too bad, but it actually seems quite manageable, mainly because the AC has been working well, really well together. And they're all putting in the time.
So you made really good selections in your choice of AC members, and I really just want to thank them for all the work that they do and thank you for letting us serve.
John Curran: Any questions for Dan?
Thank you. I remember 2007. What a year.
Next presentation will be by Bill Sandiford. It will be the ARIN Financial Report.
ARIN Financial Report
Bill Sandiford: Good afternoon, everybody. The Financial Report this time will be relatively brief, but we'll go through some of the highlights of what's been done since the last meeting in April, some updated financial numbers for the year-to-date, and then we had some people who asked some questions about how our investment policies worked on the reserves. We had a couple of slides on that, too.
So since April, couple of key filings have been done. The IRS 990 Forms were prepared, reviewed, and filed on time, as per our obligations. And we've been continuing to monitor all our investments with the investment policies. And as of the end of August, our investment balances were just a little over $30 million.
Our financial results year-to-date are kind of right where the Board expected them to be: Registration revenue just shy of $12 million, expenses just a little over 13 million, tracking at a current deficit of $1.3 million. But when you take our investment results into account, there's a net to reserves of a little over a million dollars.
That will likely not still be the case by the time the end of the year rolls around when the books close and we present to you next April, but it is the current picture as of the end of August.
Quick chart here gives you a rough idea of our registration revenue year-to-date versus prior years. This is typical. Still several months ago. But as you can see, the ISP revenue still continues to take up a large portion of our registration revenue.
Our financial reserves, as most of you know, we have various different reserve funds. We have legal defense fund, the operating reserve fund, and the long-term reserve fund, all of which have different purposes, and they also have different investment policies and procedures. But this slide here gives you a rough idea of the balances of those three funds as of August 31st.
As per the note there, $2.5 million was withdrawn from the account in January to cover the projected deficit that the organization has been running for the last couple of years, actually, while we've been having an engineering surge amongst some other things.
This gives an overall view of where our investment financial reserve balances are compared to prior years.
And this one here talks about some of the reserves and the investment guidelines. Again, this was prepared because there were some questions. Basically the legal defense fund, the objectives of this fund is we need to be fairly liquid with the fund. We always want to take care of preserving capital.
I'm having a hard time reading these slides. I think it's time for glasses. Let me try them, to tell you the truth. Yeah, that's not happening.
Paul Andersen: So, Bill, I would note, just because I also looked this up recently, the actual policies are also on our website if people want to have some nighttime snooze reading.
Bill Sandiford: There you go. As Paul said, it is on the website, but we did prepare from slides, because we did have some questions last time. The guidelines are there. Admittedly, I'm having a hard time reading them from here.
But, in a nutshell, we have certain types of funds and investments that we'll do for each of our funds depending on what the state of the objectives are of that particular fund.
This slide depicts the legal defense fund, which I'm only able to read because it's in bold.
This one is a little bit better. The operating reserve fund. Similar types of objectives for the fund. Obviously we need to be liquid and preserve capital, but we have a little bit of a different mix in the type of allowed investments we have in this fund.
And then the long-term reserve fund is also an eye-buster for me that I can't read, but, once again, this gives you a rough idea of the breakdowns of the types of investments we make that go into long-term reserve fund, and those are the numbers.
That's it for me, unless anybody has any questions.
John Curran: Jason.
Jason Schiller: Jason Schiller, Google. I'm very happy with the IT surge. I'd like to see that continued and to become more permanent IT work done at ARIN. I notice that there was a deficit because of that.
If you have to increase fees, and even if that's only on the largest ISPs, I would happily support that to continue getting the IT support that we need.
Also, if we can make this messiness with regard to community networks go away by reducing the fees for the triple extra small ISPs, if that has to be offset by some of the largest ISPs and fees, I would be happy to support that as well.
It seems like the only reason why we have a carve-out right now for community networks is to give them appropriate fee structures, and I think if we can get the fee structure for the triple extra small ISP and allow them to fall into that bucket with some policy changes, maybe that might be a good solution. I'd be willing to offset those fees as well.
John Curran: Good input. Thank you very much.
Kevin Blumberg: Kevin Blumberg, The Wire. One comment to start, which is we have policy on end user and ISP, mostly because of the fee structure. One of the talks we've had over the years is coming to equalization over time, long term, set the expectations a little more for end users to get things in line and eventually things will converge.
And our policy, because of that, will converge significantly similar to what some of the other regions have done.
So I hope that over time the end user fees will go up not only over time, more than inflation, but not zero increase, so that we can deal with that once and for all. Everybody should be able to SWIP, and it shouldn't be because of financial. That's the first thing.
The second was more of a question. You have 30-plus million in your reserve, and I suspect that that might not be enough or it's just right but it's close based on the size of the organization.
If -- and you're going to laugh at this -- ARIN were to wind down tomorrow, what is its obligations and anticipated obligations to be able to do that? Because having that number there of your reserve fund and things like that doesn't really paint a picture of, oh, we'd have $10 million that we need to give to employees as a thank you for their 20 years of service, or whatever the case may be. I don't know.
Not just one employee. Sorry, John.
Paul Andersen: It is certainly something we keep and we worry about that, liabilities and the rainy days. That's been agreed, but --
Kevin Blumberg: So just for future --
Paul Anderson: There is -- the bylaws specifies as to the articles on how we do do a wind-down, but we're not there yet and we're not planning for one on the --
Kevin Blumberg: No, what I was just saying was as a normal person, not the Board or anything like that, just an idea of where the target should be gives me a sense of where you are.
Right now the one metric, the other metric of where you think you should be is useful information.
John Curran: So a wind-down is an interesting event. And I'm not sure it's something you realistically know because it's not -- you don't have a circumstance where as of tomorrow you have a year's expenses and zero revenue and you suddenly have to offset that.
If we did have that, we'd be fine. We have a year's expenses even to operate in no revenue.
What we have done is we have looked at the position of the organization over long term, five years out, how the expenses trend, how the revenues trend, and what the reserve will be.
When our reserve was approaching 1.2, 1.3 percent of annual revenue, we had people come up to the microphone and say: Spend more money on engineering; get rid of the backlog.
We are now at the point where the revenue is about one year's expense approximately equals the reserve. We're in about that same category.
We have a little bit more, because if you -- even after you take out the legal and other, our reserves are still pretty high. But they're going to trend down over the next few years. We're slightly over operating expense to current revenue.
So the reserves are going to come down. The Board's talked about whether or not we want the reserves to be at one-year operating expense, a year and a half's operating expense. I don't think we want to go too high. But I also don't think we want to go too low.
But there's no scenario we could realistically plan for. The wind-down one doesn't make sense. What makes sense is a sudden drop or a sudden precipitous change where we have to go a number of years with much less revenue, and we're set for that.
Paul Andersen: To answer the question, the current policy is one year. That is in the document itself.
Kevin Blumberg: Thank you.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. Has there been any work to track changes in revenue as a result of legacy space coming under a new RSA agreement via transfers?
Bill Sandiford: John can speak to that.
John Curran: There's an interesting bimodal thing going on. I could tell you that what was 54 percent of the address space was legacy and now it's down to 40 something because a lot of it has come under RSA. But that's actually not the right math, because at the same time a lot of it has left to another region because of transfers into RIR, which means the denominator is changing at the same time.
So we have some dual-action factors that we've tried to model and look at.
We do have resources coming into RSA, which ends up generating revenue, they end up being registration services providers, but we also have resources leaving at the same time.
As I said, we did a five-year revenue model and did an outlook of those. There is some compression of revenue. ARIN can probably expect under the current model 10 percent compression of revenue. That brings us down under operating costs. And if you take the difference and compound it over five years, you begin to take down the reserves.
We tend to be break-even. So one of the things we're looking at, based on the five-year model, is fine tweaking so that our costs and our revenues match. But because we have revenues increasing with things coming, legacy to RSA, but also leaving as resources both under RSA are transferring out, it's a net-neutral effect.
Bill Sandiford: Owen.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I'm responding to Kevin's comment about SWIPing being related to finance.
I thought we discussed in New Orleans that end users are perfectly capable of submitting SWIPs, and ARIN will process them. And am I remembering that wrong, or is there actually no barrier to SWIPing whatsoever as things currently stand, and so that is kind of --
John Curran: So one of the things that we did is we drafted a set of harmonized service terms, because when we did the fee schedule, we got the fees very close. There's a fairly linear scale all the way down. Particularly if you go and look, the bottom fees for ISPs begin to resemble the end-user fee categories for about the same amount.
We thought about trying to do a harmonized service plan. We have not yet actually come out and gone to the community and said: What do you want to have happen here with respect to redelegation of services?
So we do have a number of organizations that are doing redelegation and are not ISPs.
We tell people that we're going to come up with a common plan for this and get it signed off by the community. Some people believe that all of our redelegation services, SWIP and RWhois, should only be available to ISPs or people under a Registration Services plan. Some people believe it should be available to everyone.
There are some implications to this financially that we need to work through, and we need to put a plan in front of the community.
Right now, there are some smaller number of users who have historically been doing SWIP who continue to do so. We tell everyone redelegation is a function of the Registration Services plan.
Does that answer your question?
Owen DeLong: Not entirely --
John Curran: If you are doing SWIP and you have been doing SWIP, you can continue to do so. If you ask us, we will tell you services of redelegation of ISPs under Registration Services plan.
Owen DeLong: So if an end user that hasn't previously done SWIP submits one, you'll reject it?
John Curran: I believe we will process it, but I'll check for you. How is that?
Owen DeLong: Thank you.
Bill Sandiford: Any other questions?
John Curran: Any other questions for Bill?
Bill Sandiford: Thank you.
Board of Trustees Report
Paul Andersen: Hi. I'm Paul Andersen. I am the Chair of the ARIN Board, and I'm giving you the Board report. No slides. It will be very short. I want to give a bit of a snapshot of what's been happening since we last saw you in April.
Mostly dealing with routine issues. We've adopted two policies that Dan referred to earlier. We've been discussing a lot about and getting the election rolling. That was including getting the NomCom formed and getting the various voting lists and vote counters and all that established.
We also had good discussion with staff on the system itself and what the future versions and what are some of the restrictions and policies we want to see that. Financially we dealt with the 990. We recently passed a code of conduct for the Board.
We had a very lengthy discussion, much like the community, on Board expansion. And we've adopted our strategic plan for next year, which is online, and I would encourage you all to read it and find your local Board member if you had questions.
And that's all I want to bring because I'd like to take a little bit of time, if that's all right, to thank some unfortunately departing Board members.
We will be -- I see that all the Advisory Council incumbents have put their name in, and that's great, but we have three Board members that will not be returning.
The first is Tim Denton, who served the Board for several years, including in Chair. He stepped down from the Board earlier this year and could not make it, but I did want to thank him for his many years of service and contributions to the Board.
This year we appointed Merike Kaeo for a one-year term, and her term will be expiring at the end of this year. And she is unable to continue on after this year, so I just thought we'd take a moment to thank her for her service to the Board. She's been a valuable asset. So if I could ask you all to give her a round of applause.
And I would just offer her the opportunity if she wants to take a second, either there or here, to say a few words.
Merike Kaeo: I wanted to just express my gratefulness, because I was quite honored to be appointed to be a Board member for the year of 2017.
I found it to be an extremely positive and inclusive experience, and also I think that the new members of the Board will also find it to be a very positive experience. Thank you.
Paul Andersen: Thank you. And that brings us to our final departing Board member. We've heard all kinds of stuff about nostalgia this year. AOL Instant Messenger, many of you heard today it's shutting down after many years. We heard about Archie, blast from the past.
And we are also losing Bill Woodcock, who we could measure the number of years he's served on the Board, which has been many, and we have thanked him; I like to think of it more that I think he's flown probably easily 3 million miles on behalf of ARIN over almost two decades.
He has been a valuable asset to all, a mentor to me. He has always kept us very honest at the Board for the many years, and I'd just like us to give a very warm welcome to Bill Woodcock who is leaving us after 15 years on the Board.
With that, I would invite him if he had any "less words" that he would like to say, as he so always famously says.
Bill, the stage is yours.
Bill Woodcock: So I know you guys are very used to seeing me speak extemporaneously and briefly, and I'm going to make two exceptions. Because I wanted to get a few things across, and I wanted to make sure I didn't miss anything.
So, first of all, I'm immensely honored that for the past 15 years you've chosen me to represent your interests in little meeting rooms around the world where people were endangering the Internet, the thing that we love and work for.
There are parts of this that I'm going to miss. But the most rewarding part of it by far I don't have to give up, and that's spending time with you guys.
I think the other thing is that the part that I enjoyed most before coming onto the Board was working on policy, and I get to return to that. So I'm looking forward to that.
I know that as members, policy is what you guys see first and foremost. And by contrast, what the Board does is sometimes kind of opaque.
But while I've been on the Board, among other things, we replaced the DoD NIC-era ASCII forms with a nice web interface. We weathered some lawsuits that could have bankrupted us and challenged our authority to steward resources. We went through a really difficult change of CEO, and we came out the other side of that with John, who has done an admirable job for us.
We worked with our Latin American members to get LACNIC formed and with our African members to get AFRINIC formed, and we got out of their way so they could get on with their work. We propped up NANOG while it went through some difficult times, and we got CaribNOG up and running.
We created the Advisory Council. We started allocating IPv6 addresses and finished allocating IPv4 addresses, more or less. We switched from 16-bit ASNs to 32-bit ASNs. We DNSSEC signed the IN-ADDR, and then for some reason we also did RPKI. You guys can explain that one to me. And we finally got the IANA oversight transition done, albeit 17 years late.
And now we're entering a bit of a quiet period. And that's the best time to take stock of where we are and address some of the internal things that we've let slide while we were fighting external fires.
And to me that means two things. First, the composition of the Board. I just this morning realized that those five times you've elected me are more times than you've elected anybody else. And that came as a surprise to me, because I'm not one of the popular kids.
But that reflects the best of you. When you, the members, are at your best, you don't treat the Board as a popularity contest.
I want you to think really carefully about the election, this election, and the ones that follow it.
The Board isn't a trophy to give to buddies that you've gotten drunk with. When it's done right, it's a lot of work, and it's work that's being done for you. Elect the people you'd want working for you, not the ones you'd want to go drinking with, the people you want working for you in those little meeting rooms around the world when you can't be there to defend the Internet yourself.
Most of you know this already, but the reason I'm leaving the Board is because in ARIN's 20-year history, we've not once elected someone to the Board who wasn't a white guy. And the members made it really clear that it's high time that that problem got solved. And that's not a problem I can help solve by remaining on the Board myself.
For the first time in ARIN's history, at this meeting, we're going to elect at least one Board member from the full pool of the best possible candidates rather than the subset of the candidates who happen to be popular white guys.
The numbers show that in the many countries that do mandated representative membership on corporate boards, the result is quantifiably better decision-making. And they all wind up why they didn't -- they all wind up wondering why they didn't do it much earlier. And I think we'll look back at this moment in the same way.
The second internal issue I think we can clean up is the complexity of policy. We have policies that have never been used or never will be. We have policies that are too vague and contradictory to be actionable. And we have some that aren't quite in English. And we have a ton of policy related to IPv4, which just won't be as much of a priority moving forward.
So I look forward to being on the floor in the next meeting in Miami advancing policies that reduce the number of words in NRPM than rather than adding to them.
Thank you all very much for 15 years of your trust.
Paul Andersen: Alright, thank you very much for that, Bill.
And that ends my report, so now it's stump the Board time. Bring your questions. Open Microphone.
Open Microphone - Members Meeting
John Curran: Final Open Microphone for the Members Meeting.
Paul Andersen: Center microphone can go as soon as he gets there. There we go.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. David stood up and said do you force us to maintain multiple Org IDs, and you, of course, retorted with: No, we'd love you to consolidate them.
But it's a little bit disingenuous in that you can't consolidate them without consolidating your RSAs into the current RSA.
Paul Andersen: That would be correct.
John Curran: There are benefits and disadvantages to the current RSA. I do agree. I would not tell you I think the benefits outweigh the disadvantages if I did not believe that. But to each person it's their own circumstance, obviously.
Cathy Aronson: Hi. Cathy Aronson. It just occurred to me a few minutes ago, and then I looked. So CaribNOG meets in April and November, and maybe that's not the best timing, but have we ever considered having a PPC at a CaribNOG?
Paul Andersen: I believe we have. The answer to your question, considered? Yes.
Cathy Aronson: Because it seems like that would be another way to do outreach to the Caribbean and get feedback on policies that maybe we don't get feedback from -- about. I don't know. Just occurred.
John Curran: We certainly have done a briefing at CaribNOG about address policy, I gave it. And I have absolutely no problem if the AC wants to bring policies to CaribNOG. I'm happy to work with CaribNOG to get a PPC set up; as long as the Board believes it's sufficiently open and transparent, it's allowed by the policy process.
It's really the AC would need to say, hey, we want to be down there, or we need a group from the Caribbean who says we want you here, and we can work on making that happen.
Cathy Aronson: Just a thought. Thanks.
Paul Andersen: Thank you.
Rudi Daniel: Rudi Daniel, Caribbean. On the same point, I wondered if it would be advantageous to have a regional meeting. So we could have policy regional meeting in the Caribbean, which would then pull together all the islands of ARIN and you could still do the fellowship with, and they're all very close together. And you could incorporate CaribNOG at the same time.
And it will help us to pull together what we now have, which you didn't have a few years ago, when you were trying to engage us, is that we have quite a few Internet Societies, and we also have a few IGFs floating around since then.
So it's a great opportunity now to move to the next level.
Paul Andersen: So it's not without precedent, but not common. We have twice held sector meetings, as I look to Susan? Once in the African region predating AFRINIC and once in the Caribbean itself.
I think it's certainly saying we're always open to discussing the balance that we've always had to trade, was just if there is actual policies being discussed that could possibly advance, there's been concerns always expressed just making sure it's accessible to the entire community.
So I think we've deferred sometimes to doing outreach events where we can discuss the policies in more informal and AC members are available to take feedback. But it's certainly something we can look at in the future.
I don't know if there's anything, John, you think to add?
John Curran: Logistically, so we have -- ARIN's good at ARIN meetings. ARIN's good at doing PPC at other people's meetings, Public Policy Consultation. We excel at doing ARIN on the Road. All of those are structures we know how to do in the Caribbean and, in fact, can extend to that area.
We haven't done a regional meeting. We've done an ARIN meeting held in the Caribbean, and I think we should do more of those.
Paul Andersen: We did do the one sector meeting in Barbados many years ago.
John Curran: But it is important to make sure expectations are set. When it comes to policy, in particular, we have some sensitivities. We've had people stand up at the microphone and say: If you're going to discuss policies, I want to be at that meeting.
So if you have a Public Policy Consultation at a NANOG meeting, I suddenly have to be at that NANOG meeting, because you're discussing my -- you're discussing policies that affect my organization.
So we just need to be careful because if we have a meeting and it's not an ARIN meeting in the Caribbean, it's just a regional meeting, we have to be very clear about what policies we're discussing to be fair to everyone who wants to be on the floor when those policies are discussed.
It has come up before with other Public Policy Consultations.
Paul Andersen: Perhaps I'll just add that Susan -- Susan, can you stand for a second for those who may not know you -- is happy to hold an ARIN on the Road, where we can always discuss policies in more informal. We have that available today. And if you have an area that is willing to help host one, let her know, and she'll be in your inbox very quickly.
Rudi Daniel: Just to respond to that, in relation to the regional meeting, I think RIPE NCC have done quite a few regionals. So perhaps we can look there and see how they did it, because they've been doing it for quite a few years now.
Paul Andersen: Understood. Thank you. Center microphone. I told you my system.
Kevin Blumberg: Kevin Blumberg, The Wire. I've been volunteering my time with ARIN for many years. You all have been volunteering your time for many years.
And I want to say as a volunteer, having volunteered with a number of different organizations, the staff are wonderful. And I'm saying this to the Board as a message that, without the help of the staff, I would have turned over many years ago. Many people would have turned over many years ago. And please, thank you for this job.
Paul Andersen: Let us thank the staff now.
Paul Andersen: Thank you, Kevin, too, for reminding me, because I did mean to thank them in my report, but in my rush I forgot. So thank you for that.
We are rapidly running out of speakers, so we will close the mic shortly. So if you did want to speak at Open Microphone, please approach a microphone or start type remotely.
Stephen Lee: Stephen Lee, ArkiTechs, Inc., and CaribNOG. Just to jump back to the previous point, just to reaffirm, I think John said it, want to note that there are these -- somebody in the Caribbean is invited, just want to go on record to say that CaribNOG is. So as a CTU and many other Caribbean institutions, that we would definitely want to have more policy consultations inside of the region.
I was at one in Kingston, I think it was a Caribbean sector meeting in '08, I believe. I think it went very well. We also have our CaribNOG back to back with ARIN in Miami next year. So that might actually provide a good opportunity to have some policy discussion more aligned with CaribNOG at that time. So thanks.
And I'd also like to second just that commendation of the staff, the whole ARIN team, tremendously great outreach and relationship with the Caribbean, Caribbean organizations, really appreciate everyone. Thanks.
Paul Andersen: Thank you very much. Thank you for those words.
Okay. My eyes -- I suspect -- yes, I thought you might be doing that. We certainly have nobody at a microphone. So going once, twice, three times. The microphones are closed, and that ends Open Microphone.
Members Meeting - Closing Announcements and Adjournment
John Curran: I'd like to thank everyone. We are now in our wrap-up, our final close of the meeting.
So one more time, if you have not voted, this is a great time to vote. There's lots of people who can help you. You've got good connectivity. Right now, before you leave, just fire it up and get that vote done. Otherwise, one of us will call you next week. So, if you're an ARIN member organization, take a chance, go online, vote.
Would like to thank our sponsors for the final time of the day, Zayo and Google.
Okay. Our Avenue4 refreshment break sponsor.
We have a survey, as you said, as I said before, you'll qualify to win potentially an Apple iPad Air 2. We're looking forward to seeing everyone.
ARIN on the Road meetings. You can find the schedule online.
And ARIN 41, as people noted, taking place in Miami in April.
That concludes our meeting. Thank you for coming.
(Meeting concluded at 2:00 p.m.)