ARIN 34 Members Meeting Transcript - Friday, 10 October 2014

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

Table of Contents

Members Meeting - Call to Order and Announcements

John Curran: Good morning. If people would come in and be settled down, we'll get started. Welcome. I'm John Curran, President and CEO of ARIN. I'd like to kick off our ARIN Member Meeting this morning. I'd like to take a moment to thank our sponsors - network, webcast, and break sponsor Comcast, Google, and ServerHub. I'd like to remind everyone we're in the middle of an election. If you're a designated member, please go vote now. Go to arin.net/public/election. If you have questions, find Jud out at the Election Desk for voting assistance. Voting closes Sunday, October 19th.

Rules and reminders. Approach the microphone, state your name and affiliation each time you're recognized, and please comply with the rules and courtesies outlined in the program. Today's agenda. Lots of reports and updates. NRO Activities Report, NRO Number Council report, ARIN departmental reports, our customer survey report, the ARIN Advisory Council report, ARIN financial report, a fee structure discussion, and a Board of Trustees report followed by Open Microphone. We have all of this and be done by noon.

I'll start right in at the head table. I have John Sweeting, Chair of the ARIN AC; Vint Cerf, Chair of the ARIN Board; and Paul Andersen, Vice Chair and Treasurer; Bill Woodcock, Board member; and I have Aaron Hughes. I know these guys and I can't remember their name.

Let's start right out. NRO Activities Report, which I will give.

NRO Activities Report

John Curran: The NRO is the organization we use to coordinate the RIRs, and the five RIR CEOs participate in the Executive Council. So I'm going to bring up the NRO Activities Report and update you folks on what we've been doing.

Mission: To be the flagship and global leader for collaborative Internet Number Resource management as a central element of an open, stable, and secure Internet. I guess we declared ourselves a mission so people know what we do.

And we're giving a quick introduction. Talk about our focus areas and then talk about our activities. We're incorporated in 2003 - sorry, not incorporated. We were formed in 2003. We're a lightweight unincorporated association, i.e., it's just really a coordination function. We meet together. We share activities, but everything we do is generally done back in the individual regional organizations.

Our goal is to encourage coordinated Internet number registry system, promote the multi stakeholder model and bottom up policy development, coordinate support joint activities, act as a focal point for input to the RIR system, and the NRO fulfills the role of the ICANN Address Supporting Organization.

Role within ICANN. That is a body that ICANN has for purposes of coordination of policy among names and numbers and in the ICANN structure. Our key focus area is obviously supporting the RIR coordination, global collaboration, and governance coordination, proper branding and positioning of the NRO, and we can monitor and contribute to the global Internet governance discussions.

Executive committee is made up of all five RIR CEOs. Adiel is our chair and Axel Pawlik from RIPE is secretary this year. Ernesto from LACNIC is the treasurer. Paul Wilson and myself are also on the executive committee. The secretariat is hosted by the RIPE NCC. And the executive secretary is German - is German here this week? No. I think German is out.

And we have coordination groups. So we sort of take each RIR and we go horizontally and we take the communications teams, the political team, the engineering group, the registration services group, and we have a - groups within the NRO which coordinate, for example, our communications. So when we're working on something for presentation at ICANN or the ITU, the coordination, the communication department managers, the five RIRs will work together so we only have to develop one document that we can all use.

Expenses. NRO does have some expense for the executive director in Ernesto - sorry, in German - and we also have travel. We also contribute to ICANN. The contribution is 823K annual. It's been that way for about a decade. And those expenses are divided up among the RIRs based on a formula, based on the size of each one, based on the registration services revenue.

We have a representative in the Internet Governance Forum, a multi stakeholder group that coordinates the agendas of the IGF, Paul Wilson and Paul Rendek. We actually just came from the ninth IGF, Internet Governance Forum, in Istanbul. We did a contribution to make the IGF happen, and then we did a booth to explain the RIR system.

It's very helpful. A lot of governments, a lot of organizations that may not make it to an RIR meeting can go attend the Internet Governance Forum. There's a wide range of topics there, and they get to hear about the registry system, so very useful outreach we do.

We've been active on this Internet governance and IANA stewardship transition activity, including responses regarding ICANN's accountability, responses indicating that we would participate in the planning function for the transition of NTIA stewardship. We've been active in the WTPF, the ITU World Telecommunications Policy Forum.

All the documents and communications we have are on the website and the NRO website. We're in the - in regard to IANA oversight transition, Adiel and Paul Wilson are members of the ICG, the IANA transition planning coordination group. And we've also been involved among the Internet organizations. So not just ICANN and RIRs, but also the IETF, ISOC. There's an organization called the i* collaboration. We get together periodically to help coordinate issues across our organizations.

And that actually led to statement, a statement regarding NETmundial. It's been instrumental in getting initiatives off the ground. NETmundial was a significant meeting earlier this year. We were an active participant in it, and we actually participated in the executive multi stakeholder committee which was involved in making it happen. We had contributions and we actually helped with the final NETmundial statement.

We have a nice new ASO website that we worked on this year. We have an RIR governance matrix that covers the governance mechanisms of each of the RIRs in a comparative way. So if you want to see - for example, you want to see what each RIR has in terms of how its budget is set or Board is elected or how - what law it operates under, what it has for appeal processes, there's a matrix on the NRO website that compares the RIRs not just in terms of policy - we've always had a policy matrix comparison - but now in terms of our governance structures. And we've been adding a lot of content regarding the IANA oversight onto the NRO website. We will get more up there as soon as it gets settled.

That's the report. And I'd like to thank everyone and open it up for questions.

Okay. Thank you. I'm now going to call up Jason Schiller to give the NRO Number Council report.

NRO NC Report

Jason Schiller: Good morning. My name is Jason Schiller, and I'm on the ASO AC and the NRO NC. I'm going to give the NRO NC report. I'm going to talk a little bit about what the NRO NC is, our recent activities.

What is the NRO? Unfortunately, there's an alphabet soup of acronyms - ICANN, which performs the IANA function; the NRO NC, which performs the ASO AC function - it's all rather complicated. So I'm going to talk about these a little bit. The NRO is the Number Resource Organization. It was formed by the NRO MoU. And it has the purpose of coordinating the five RIRs so they can act collectively speak with one voice.

It also spends the RIR's money and protects the bottom up policy development process. And it consists of the NRO EC, which is the Executive Council, which you just heard that report from John; the NRO NC, which is the body I sit on; and we have a secretariat.

So the Executive Council, which you just heard about, is the five RIRs, and it basically speaks on behalf of the RIRs. The Number Council speaks on behalf of the community. We have three members elected or appointed from each of the five regions. So we're a 15 member group. We perform the function of the ASO AC, which was established under the NRO and ICANN signed ASO MoU.

And what this does is this establishes the fact that the NRO NC will perform the ASO AC function, it defines how we process global policy development, and defines how we provide recommendation to the ICANN Board on number issues and also the creation of new RIRs.

So what is the ASO AC. It's an ICANN supporting organization, the Address Supporting Organization. And there is an Address Council as well, which is basically the function that the NRO NC serves. And basically what we do is we oversee global number policy work. We make sure that the policy proposal process has been followed and shepherd that. We also appoint two directors, Seats 9 and 10, to the ICANN Board. And we also appoint or serve on various other ICANN bodies and advise ICANN when needed.

These are the members in this region. We have myself; Ron da Silva; and Louie Lee, who is the chair. He's been the chair for quite a few years now. Currently there are no global policy proposals on our docket. If there were a global policy proposal, that would go through the standard policy development.

The way that works is it goes through the regional policy development in each of the five regions. Hopefully the same text is agreed upon. That gets sent up to the NRO. If the text is not identical, there can be some wordsmithing and rewriting to make them identical. That gets sent to the NRO EC for review to make sure that the intent of the policy has not changed from what was discussed in the individual five regions.

We make sure that the Policy Development Process was followed, that all interested concerns have been discussed and addressed, and we send it up to the ICANN Board, who can then ratify it, sit on it, or if they have significant questions that haven't been addressed, send it back down for further discussion. So this is really the meat of the presentation. What have we done for you lately?

We had our ASO AC face to face meeting at ICANN 50 in London. We discussed the revamp of the NRO website. We discussed the potential need for a global or global coordinated policy on IPv4 address transfers. We updated our operating procedures. We now have better procedures for appointments that are not the ICANN Board. And we also discussed a need to expedite the ASO member selection. So there's been a little bit of a shakeup in terms of the timelines in terms of when ICANN Board members get selected and placed on the ICANN Board. So all of our timelines have shifted. And a lot of this work is now going to be starting in October. I'll give you a timeline at the end.

So there was some discussion of, gee, wouldn't it be great if in October we knew who was going to be sitting on the council next year when this process is already started in October. We also held a two hour ASO AC workshop. We discussed LACNIC v4 runout. We discussed the various soft landing policies in the different communities, the current status of transfer policies, and also where we are in terms of IPv6 adoption and what the impact of World IPv6 Launch Day was, and we also discussed the IANA redistribution policy. So our focus really was winding down IPv4. Sadly, our workshop was not heavily attended by members of the traditional ICANN attendees. We did see a lot of faces from this community and the other RIRs, though.

Recent appointments. We have a new ASO AC member from APNIC who will be starting in January, Dr. Ajay Kumar. We also appointed Hans Petter Holen, who used to be on the ASO AC, to the ICANN Nom Com. And Hartmut Glaser is serving on the Oversight Transition Coordination Group.

At the last ARIN meeting, there was a bit of a scurry. LACNIC was about to run out of ASNs, and they were going to go back for more. And we suddenly realized that there were less 2-byte ASNs in the pool than LACNIC could potentially take out in one go. And there was a little bit of a panic, a little bit of excitement. It kicked off this discussion in this region about what is the right thing to do with regard to 2-byte and 4-byte ASNs.

And in this region we noted that we are primarily using 2-byte ASNs and very few 4-byte ASNs. So what's going to happen in this region likely is we're going to run out of 2-byte ASNs and we'll be sitting on 4-byte ASNs. And if those are underutilized enough, we'll not qualify to get more ASNs from the IANA. So the question was: Can we sort of set aside the 4-byte ASN utilization and the 2-byte ASN utilization and look at them separately? We had discussions in this community at Open Mic. We had an emergency ASO AC meeting. We had a breakout table at breakfast. And what we heard from this community is there's no reason why anybody shouldn't be able to use 4-byte ASNs. And if we give out too many 2-byte ASNs and not enough 4-byte ASNs, then people will start using 4-byte ASNs and this is not a technical problem. So this conversation actually spurred off questions from the IANA, and they asked for some advice regarding the Internet assigned authority policy for allocation of ASN blocks to the Regional Internet Registries.

This is the policy here. It basically says after December 31st, 2010, there will be no distinction between 16 bit and 32 bit ASNs. This is the policy under which they're given out. You have to show you're 80 percent used before you can come back and get more. So the RIRs raised this question. It went up to the IANA. The IANA asked for advice directly from us, and what we basically responded with was we said when judging if an RIR is eligible to receive one or more additional blocks from IANA per Section Three, the IANA must consider the utilization of the total undifferentiated pool. Meaning you can't just set the 2-byte ASN usage aside and look only at the 4-byte ASN usage; and you can't just set the 4-byte ASN usage aside and only look at the 2-byte usage.

They also asked a question about it seems like the RIRs are managing them in two separate pools but the global policy says they have to be undifferentiated. We commented on that as well. We said how an RIR manages their undifferentiated pool is within each RIR's consideration per their operating procedures and policies. We further stated that there's no requirement in the policy to form the block of 1024 AS numbers out of a single, contiguous set. This is consistent with advice that we had previously given to the IANA. So per that advice and per the past practice of RIRs having the option of requesting a block of 1024 addresses that consist of a noncontiguous block of a specific amount of 16 byte and 32-byte only ASNs, this process can continue.

We then also turned around and sent formal response to the NRO EC and we suggested to them that they certainly could decide that they're going to take only 99 2-byte ASNs out of the pool which would roughly carve it up into one fifth each. And we asked if such an agreement was reached that it be done so transparently and openly and that the RIR communities are informed about such an arrangement. So what's happened? Well, LACNIC came back. They ran out of ASNs. They asked for more. And APNIC did as well. And both of them chose to take only 99 2-byte ASNs.

Last thing I want to talk to you about is work that we're just about to embark on. We'll be filling seat nine for the ICANN Board. This is a seat that's currently held by Ray Plzak. Seat 10, which is the other seat we appoint to, is held by Kuo Wei Wu, which means that Seat 9 can be filled from anyone that's not from the APNIC region. We've got the timeline here. We'll be starting the nomination phase the 24th of October, and this should run all the way through the selection through mid April. If you have some recommendations for who you would like to see on the ICANN Board, find myself or Louie or Ron and let us know who you like and why you like them. And definitely, once the nominations start getting published, please do comment, if you have comments to share. Questions?

Cathy Aronson: Cathy Aronson. You were talking about the globally coordinated policy on one of those slides. I just wanted - maybe you could speak for just a second - because I had a whole discussion last night about why there isn't a global policy for IPv6, which there once of course was. But a global policy from this perspective is a policy that is developed for a specific instruction to the IANA, but there is no global address policy, so to speak. Do you know what I mean? It's the age old problem. And I think a lot of people may not be up to speed on that.

Jason Schiller: I'm not sure what you're asking. Sounds like you're making a comment.

Cathy Aronson: My point is that under the umbrella of all this, you can't actually have a global address policy, for example, because a global policy from the position of the ASO AC is specific policy that tells the IANA what to do or what not to do. And that's the only global policy that exists, right? Or has that changed?

Jason Schiller: There's a global policy on ASN distribution. There's I think -

Cathy Aronson: Right, but that's an instruction for the IANA.

Jason Schiller: Yes.

Cathy Aronson: What I'm saying is we had a globally coordinated IPv6 policy for like five minutes and then individual RIRs changed it, which they can do, but there isn't a mechanism for there to be a global policy that does not tell the IANA what to do. And I think that the community may not - everybody might not understand that.

Jason Schiller: Let me take a minute to explain what global policy is and what global coordinated policy is, and let me also address the concern about it changing. So a global policy is one that has in its definition some action that the IANA must take. So these policies can also have regional pieces to them as well. They can have requirements on the individual RIRs. So, for example, a policy that says the IANA will give out ASNs in a certain size block and the RIRs must manage them to 80 percent full before they can come back and get more and the RIRs must manage them as an undifferentiated pool. So this policy has requirements both on the IANA and the RIRs as well.

This is a global policy by definition because it requires the IANA to do something. A global coordinated policy is a policy that does not have any impact on the IANA. So, for example, we might have a policy that says when any RIR runs out of business as usual IPv4 space from the free pool, the four other RIRs should immediately empty their pools as well.

And what's important here is the action that a particular individual RIR is doing only makes sense in the context of all the other RIRs also doing that behavior. So that would be what we call a global coordinated policy.

The problem is we have no mechanism to lock down in the Number Resource Policy Manual that this set of text is globally coordinated and as soon as we touch it and it differs from another region, that that breaks. I mean, we have an implementation timeline that says we'll implement this when it passes in the four other regions. But we have no de-implementation plan or de-implementation timeline if the text falls out of sync.

And we also have a very sophisticated global Policy Development Process with specific roles that the NRO NC has to undertake in terms of tracking and notification. We don't have that formal process set up for globally coordinated policies, although we do tend to follow it. Yes, there are certainly some challenges with respect to globally coordinated policies. Did that cover your questions and concerns?

Cathy Aronson: Yeah, I think so. It's just that like we had - like I said, we had the globally coordinated v6 policy but there's no mechanism to keep it in sync.

Jason Schiller: I'm closing the mics. Thank you everyone.

(applause)

John Curran: Very good. We're now going to proceed with the ARIN departmental reports. First one up is going to be Mark Kosters doing the engineering report.

ARIN Reports: Engineering

Mark Kosters: So good morning, everybody. This talk is going to have a bunch of uppers and downers. So depending on your drug of choice, it's all here.

(laughter)

Mark Kosters: Let's go ahead and get started.

The first one is a downer, and that is Tim Christensen, who has been employed here at ARIN for 14 years, he passed away suddenly on August 5th. This is a big loss for ARIN in that he was our DBA for many years. He knew how everything was from the way back machine. This is a big loss. We were able to shore up our staffing. But I want you to all know you'll not see Tim here anymore. Okay. Now for more of the uppers. So let's go on to our staffing. We have six operations engineers and two managers, and in development we have eight programmers and a manager.

And Software Integration, which was formerly known as Quality Assurance, we've had a leadership change, of course, with Tim passing. We now have Garth Dubin, in the back of the room. Garth, could you stand for everybody? Taking over Software Integration.

Also, if the whole engineering team - since everyone's really close, we decided to bring up the engineering team so that those who hadn't been to an ARIN meeting could see what it's all about. If you could all stand. I know this is a lot of work for you guys.

(applause)

So in project management we have Deb, who is a development person before. And of course me. So accomplishments since ARIN 33. So DNS and now DNSSEC have now real time updates. We've added TTLs for both name service and DS records. You can change yours at leisure through ARIN Online and through the restful API. We also hardened our signing infrastructure. We now have secure 64 boxes which is essentially HSM and also does the signing.

We've also enabled our - with DNSSEC our forward zones and our individual reverse through the same box. We've implemented shared tickets, as Nate talked about, displaying agreements associated with organizations related to RSAs; user interface improvements for payment processing; transfers, we've done 8.3, so that's through ARIN Online, and 8.2 and 8.4 are underway. We're currently working to move away from ARIN HQ with our provisioning production hardware. And I'm going to be talking about some of those reasons why here shortly. And we're also moving away from EMC, which is a very ancient box to a NetApp which we use for our SAN.

We've made fault tolerance improvements over the past year. The big thing I'll mention here is we use a virtualized environment big time within ARIN mainly to save money, but there's been a few cases where we've had to pull some of that stuff away, mainly Microsoft Exchange. Is anyone from Microsoft here? Okay. Good. So it's just - it's a huge resource hog. And so we basically had to move it to physical hardware to make it behave appropriately. We do a lot of corporate help desk support and IT support. Of course here at the Member Meeting if you have wireless issues, we're here to help, and so on and so forth.

So let's talk about OT&E here a little bit. This is the environment for you guys to test your code, to test processes. And we've now set up a sub domain so all the resources that you have under the replicate core services are all named basically very similarly to what's in production, it's just under the subdomain ote.arin.net. The reason it's all here is for you guys to test. We have lots and lots of APIs for you to use, both on the provisioning side in terms of sending us your SWIPs but also - well, SWIPs in terms of using the RESTful provisioning service, but also from the directory services side. And also with RPKI.

So for those who want to test RPKI but don't want to muck with production, we have a way to do so. And just - and this is somewhat new, but from a participation perspective, we've had 30 new requests since the last ARIN meeting, and we have right now 152 networks that are now playing in this environment. So some of these networks may be more than - may have one or more ORGs associated with it. But it's the best way we can actually show you now in that this environment is being used by you. And I thank you very much. And for people wanting to go ahead and test new software, it's to rely on our API.

And IETF. Andy and I are very much involved in IETF, both in SIDR and with WEIRDS. We'll talk more about RDAP shortly. And ICANN, I'm involved with Security and Stability Committee, Root Server Committee, and Technical Advisory Group that just started out. Now we had a couple of uppers; now I'll go back to a downer, being even keeled. So I'm going to talk about an outage incident. We had some DOS attacks and ISP availability that we're currently challenged with.

So ARIN HQ, for you who don't know, is actually in a fairly cheap location. It's cheap -

Vint Cerf: There's a reason why it's cheap.

Mark Kosters: There's a reason why it's cheap. For those who have come to our office, it's right next to the police academy. So when you come to work, it's not uncommon to hear sirens, screeching tires, small arms and large caliber arms going off.

(laughter)

Mark Kosters: It's not also uncommon to hear planes taking off and landing because we're right next to the Dulles Airport. And to add on to this, we have a major road being under construction, Route 50. You have guns. You have ambulances. You have all kinds of sirens. You have construction gear. And you have plane noises. So if you're allergic to noises, this is not the place to be. We also have major lack of power resources. We have one major line coming in from Virginia Power. And we also have lack of connectivity options within ARIN. So we only have two providers who currently provide us service, that we could potentially get service from, from an Internet perspective.

And as we've gone through this evolution, we've moved out our directory services to the edge. We call that PFS - public facing services. But the provisioning side we've kept in house until recently. Mail, Web and Reg RWS are all internal. And we've had this long running project to move it out. While this is going on, our UPS decide to go up and die on us. When it died, it was a major event. We actually had to cut out part of our wall structure to get to the insides of the box. They replaced much of the innards of boxes, almost all the CPU cards in it, and it turned out to be a single wire that turned out to be an issue with it that caused the UPS to go crazy.

And this is a long running sort of issue. Took about three weeks to fix. And during that time we were on pins and needles. What we did learn is that we could recover. Since I've been at ARIN - I've been there now for seven years - we've never had a power outage where the power in our computer room went out until this particular instance. And there were pieces of gear in there that had never been power cycled. So you know how things go when you have power cycled really old gear. It's under a lot of stress when it first comes up, and that's the time where it's going to fail.

And we only had a few minor failures, but we were able to come up. And since we had a couple of times where our UPS decided to go and die on us, we were able to get better and better at this opportunity to recover our systems. And what this really did - to be honest. I hated this. I absolutely hated this. And it really renewed the emphasis to us moving to our colo, which has its own issues, but that's a separate thing. We also suffer from periodic DOS attacks. And this is something that's fairly new for us in the sense that they're hitting our provisioning network. They've been hitting our public facing side for some time, but that's not really a big deal. But hitting our provisioning network is something that I don't really like.

We have some DOS mitigation, but we don't have enough. And this is something that we need to look at better. We need to cleanse the data so people who are rightfully trying to send us transactions can get in. ISP availability. We've had multiple connectivity issues with our upstreams from ARIN HQ. Planned maintenance or not planned maintenance continually surprised. This irritates me to no end. Especially 2:00 in the morning, getting a phone call, having to go into the office and find out a guy down Route 50, which is having the major construction, is doing some fiber splicing. So we actually saw that about three weeks ago.

We've also had issues with our West Coast PFS with announced and unannounced outages as well. But we're working with that. Operational highlights - now we're on the upper again - is that on our publicly facing sites we've been up 100 percent over the last six years. Services for this: Whois, Whois RWS, DNS, Mailing List, and FTP, all those things are on PFS. Now, you should ask yourself: Why isn't our website on this public facing services? The reason that's true is the public facing website is integrated with our provisioning system. All that is actually pulled into our ARIN HQ.

And that is something that we're going to work on in terms of separating the content, static versus dynamic, hopefully, so that we can have at least the static side out and separated from provisioning. Also I want to stress when RPKI becomes real in the sense that people are using this in an operational sense, people are testing it now, that we're also going to be going with the same dedication with RPKI.

So the repository is out on PFS right now. Here's our ARIN Online usage. You can see there's lots and lots of accounts activated. So a huge number. We average about 15,000 a year, new accounts, which is pretty amazing. Here is the number of log ins since inception. What's interesting on this is that the people who have logged in over 16 times. So ARIN Online is being used. Here's the interesting thing. There's some discussion yesterday about APIs and why don't the registries all get together on API. ARIN has an API for its provisioning side that's well documented that anyone can pull down, they can play in the test environment and actually set up a system to actually interact with us, and you can see that people are taking advantage of this.

If you look at that, the bar in red, those are all RESTful transactions. Those are reassignments going over REST. You can see on the blue bar is being templates, they're also increasing. You can see they're increasing at a much lesser scale. So people are taking advantage of this. And this is great. Other regional registries are in various states of deployment in doing things. RIPE also has a system where you can actually do provisioning through their REST interface, too. Here you can see reports through REST. One of the things you may notice is association's reports have gone up quite a bit.

And the reason for that is we deployed, recently, right before ARIN 33, the ability to actually get association reports through the API. But you can see, for example, WhoWas is a very popular service. DNSSEC, you can see it's a fraction of a percent that's actually signed with DNSSEC. COM is in the same category. RPKI usage, you can see that there's 153 organizations currently using RPKI, playing with it in our production environment. You can see the covered resources, 332. The thing I'll mention here: No one's actually asked for up/down yet. So we've not had one single person ask us.

Whois queries per second. The thing I'll mention here is you look at the red line, those are the RESTful, using the RESTful API. The queries per second is much higher over the RESTful API than it is over the traditional Port 43 service, which is in blue. They both total a thousand queries per second. Here's Whois over v6. And I did this as a percentage. And you can see that six percent now is actually over v6. IRR maintainers keeps going up. And IRR route and Route 6 objects keep going up at a lesser degree. InetNum and Inet6Nums go up as well.

Systems on the forefront. RPKI. As I mentioned, up/down is available. No one has taken it. We've upgraded HSMs to 4765s since the 4764s that we were on previously have been decommissioned by IBM. We need to keep up to date on being able to get new hardware if we needed to. RDAP is soon to be an RFC. We have a public testbed that's available for anyone who wants to test with it. The other regional registries are also playing in this space as well as domain registries. I want to mention that we're a small engineering shop. I think you all pretty much know this. And we're trying to - we're attempting to provide and we are providing exceptional service and we're creating APIs for you to actually create code on your behalf. Because everybody has their own specialized views on how they want to do this. And you have the ability to do this.

One thing I'll mention. We've had one taker so far on creating a tool they put in the public domain that actually takes advantage of our API, which is a .NET service, arinwhois.net. Here is again what we've accomplished since ARIN 33. We finished up a bunch of ACSPs, DNSSEC for the forward zones, moved the RPKI to a new HSM, made DNS changes to near real time, started automation on transfers, moving core production from ARIN HQ to the colo, and moving a SAN from EMC to NetApp. Here's what we're planning on doing for next year, which is somewhat provisional because we have to go through the process of getting approval for next year's plan.

What has the asterisk here is what we're currently working on: Moving RDAP pilot into production, further automation of transfers, the production move, the migration of the SAN. And here's what we hope to do for next year: Add links to Whois query responses, which is ACSP; change Whois output for certain /8s, which is also ACSP; start SWIP Easy, which is a way for those currently doing hand templates, which we see a lot of, allowing them to do this over the Web instead, using ARIN Online; and deploy two factor authentication.

So any comments?

Martin Hannigan: I'll put my Open IX hat on for a minute just to talk about your infrastructure problems. You may or may not be aware that Open IX has a datacenter standard called OAX 2, open, freely available use of the standard to the general public. There's also some checklists that we have on the website that you can use to kind of validate the types of Web services or datacenter services that you're going to get from your providers. I would highly recommend that you at least require OAX 2 compliance in sighting of your services. Should be a little bit helpful. And that's it. Looks good. Thank you very much. I feel your pain on the UPS stuff. It's been a lot of years since I worked on small stuff, but I remember it well. I'm really sympathetic.

Mark Kosters: Thank you.

Kevin Blumberg: Mark, I want to say thank you for the depth of the information that you've given us here, which is why I actually have a couple of things on here for you. But I really appreciate this kind of information. With the colo power, it's the gift - sorry, the UPS power, it's the gift that keeps on giving, unfortunately. If you took a lot of knocks, and we don't really see that in a lot of your outage reports, so that's the one thing I would ask, is just even a brief, hey, we had an issue with our UPS on this time, we got it resolved; would really help when I then come to the mic the next year to say, well, you notified us of eight things. And I can see there's a pattern here, Mark, we'd really like as a community that you work on that. But we don't really know that right now. But please keep in mind that when hardware takes hits, multiple, multiple power hits, the life expectancy of that equipment will drop significantly. And really glad you guys are moving this out to somebody who it's their day job. You guys don't need to be in the colo business.

With two factor, thank you, I see it's being worked on. And I believe that's great for the community, especially with everything that's going on with - as you saw the DOS attacks, you're becoming a vector. And my last question was: You mentioned previously about a security audit, having done that and having external, and we talked about just getting a thumbs up/thumbs down, A/B grade, something like that, are you doing regular external audits now? That just wasn't on here, so I figured I'd ask.

Mark Kosters: We have it in the budget for next year to do another audit. So, yes, that's in the budget. And we'd like to do security audits from independent third party from here on forward. So it is in the budget for next year.

John Curran: We did an external third party audit, including red team activity, and it was illuminating. I will say that while there was nothing that was terrifying, there were certainly some things that ended up being added to the engineering work list as a result of having fresh eyes look at it. So we'll periodically have that done because it seems to be a prudent move.

Kevin Blumberg: I just would reiterate a very basic executive "don't need to know the specifics" but just second time around, you got your first one for free, the second time around we'd love to see something like that.

Owen DeLong: Could you go back to the Whois queries over v6 slide for a second. Owen DeLong, Black Lotus Communications. Any idea what that dip there for a couple of days at the end is?

Mark Kosters: It's actually a couple of months. I've looked over the data. I can't explain it.

Owen DeLong: Thank you.

Martin Hannigan: Actually looks like event traffic to me. If it wasn't there, it would be pretty smooth. I think I actually know what that event is. I'll take a look and let you know, Owen. I wanted to comment real quick on your DDOS stuff. And you mentioned, and someone was asking about, penetration testing. Those are some pretty expensive endeavors, especially with your upstreams. They're not going to want to help you too much because they're going to want you to pay for the traffic they have to carry. You might want to consider DDOS mitigation services. There are a lot of good ones out there. My colleague runs one. I run one. They're not necessarily inexpensive, but they're probably more inexpensive than doing it yourself. The same with the penetration testing stuff. There are a lot of good services out there. With respect to DDOS mitigation, there are varying levels of DDOS mitigation. I would urge you to check into them. I think you'd find them to be a little less expensive than what we're reading here. Thanks.

John Curran: Thank you, Mark.

(applause)

John Curran: Our next department report will be Member Services. Susan Hamlin will come up and give that.

ARIN Reports: Communications and Member Services

Susan Hamlin: Good morning, everyone. So a quick update on our activities. And, first of all, this picture is a year old, and there's something about working at ARIN that keeps us all young. So I don't think we look much different. So we do have one addition to our staff, bottom right, Sarah Ba, who joined us a couple of months ago, and we're sharing her part time with HR and Admin Department. So CMSD is somewhat of a hybrid department. We handle sort of association business, taking care of processes and policies and also communication. So just a list of some of the things we cover. And you know the folks that handle these.

Einar takes care of the Policy Development Process support for the AC. Jud takes care of fellowships, and he also helps NANOG with their fellowship implementation and elections that are going on. Lots of meetings - PPC, these meetings, ARIN on the Road, new member outreach, training and education. And then we have the whole communications side, and Hollis is communications manager, oversees activities, the Web content, social media. And then all of us are involved in outreach and work with our PR firm. And I'm going to talk about that in a minute.

So a look at some random stats. Those are current membership and the breakdown by regions. We're very active in social media. And Jennifer has done a great job increasing our blogs. We have a lot of guest bloggers. And if any of you all are interested in contributing, please find us. Can always write to info.arin.net. We'd love to hear from you. So one of the areas - we did a customer survey. Many of you all participated in that last year, and one of the results was something we hoped and knew we would hear from; that we need to make improvements to our website.

So we've been working on this, and we worked very closely with all of our internal departments. And a couple of examples, recent things we've done, working with Registration Services, is to try and streamline some of the information on processes, transfers, requesting resources, and we're going to continue to make these types of improvements. So here is one recent page we redid. I don't know if you can really tell. But the navigation. So transfers are complicated. There are lots of - so we're trying to streamline where you can go in, find what it is you want to do and quickly follow the steps to accomplish that. Another example, Registration Services recently put up some examples of documentation that you need to include when you're requesting resources.

So some of these things, we hear from you when you call to Registration Services Help Desk, put in a request, and we do pay attention to that. So I encourage all of you, if you're experiencing any issues, to let us know. Another area this year that our departments worked on is the creation of videos, some how to tools, especially working within ARIN Online. And we will continue to provide these sort of step by step easy things to follow. And we've had pretty good hits. People are actually downloading and watching these. So, again, if there are other areas that you think a video would be helpful, let us know.

We continue to do outreach. A lot of it is still v6 focused. We're getting involved in more Internet outreach. Some of these represented here. ARIN brings a booth. Some of these John kindly goes on the road, Nate goes on the road, Richard, Cathy Handley, to provide presentations to various groups. That's part of our mission, to provide education. We're here. If any of you all know an organization that you think could benefit from having an ARIN presence, let us know. We'd like to send people on the road.

Speaking of which, ARIN on the Road, we will conduct our eighth the end of this month in Columbia, South Carolina. We've held 23 of these. We're putting - I'm putting together the schedule for next year. And I'm interested if there are any particular geographic areas, you're in an area where ARIN hasn't been in a while, you think it would be helpful, let me know. I would love to think we'd hit every province, every state, every Caribbean island before we're finished with this program.

Okay. At registration you might have picked up one of these cards that says: Get 6. Connect with IPv6. So ARIN has been conducting outreach in IPv6 for probably eight, nine years. And we started out very much as an informational campaign just explaining what IPv6 was. We had a lot of AC members that joined various booths and they showed addresses and just the basics. So this has been going on for quite a while. We feel like we have reached a lot of this community obviously. You all know the importance of IPv6, but yet there are a lot of people, perhaps in your companies and others, the CEOs, the chief marketing officers, marketers, who don't really understand or understand the need to pay attention to IPv6.

So working with Stanton Communications, our PR firm, we're developing a new approach, and we're really focused on content with the growth of mobile platforms and content. We think it's a good opportunity to bring a wider message and to start this campaign. We, at the end of this month, are going to have an open conference call. It's a great opportunity for you all to impart your v6 knowledge to share ideas, to help us figure out what the best message is for making the business case for IPv6. So I hope some of you will join us on this call.

Our goal is to reach out to a broader community, stressing the need to have websites enabled over IPv6 and perhaps draw some attention. So within an organization, the CEOs, the CMOs, the technical people might all get together and collectively understand the importance to help move an organization. So interested in feedback, what people think of the idea. And we'd love to have you join us for that call. So October 28th, if you're interested. Drop us a note at get6@arin.net.

We're very active on social media. And I was looking at stats. Actually, ARIN has tweeted over 9,000 times since 2008, and our followers are growing. Kind of exciting. Looking ahead for next year. One of the new projects we'd like to try are webinars. Our videos have been successful. My great creative team says we should try webinars. We feel internally we can develop these and do these pretty low budget. So we are now in the process of identifying topics. Probably starting with a few technical topics. We'll try them out. Hope that you all will join us for some of these.

And, again, website improvements. Our big project next year, we hope, is to move forward with an overhaul of these static sites, www.arin.net. Last year, early this year, we implemented a Feedback button, which is the top right navigation of every single page. So I want to encourage all of you, if you're on the website, you're looking for something, you can't find it, click that Feedback button and just let us know what you're looking for.

The customer survey said we needed help, but it didn't identify detail. We'll be likely coming back to you all to ask if there are particular areas of the website we need to address navigation content, et cetera. And then, as always, we are looking for ways to improve our outreach and to make it fun and to get people engaged and interested in participating in ARIN. Thank you to our sponsors. We couldn't do this meeting without them. And then, looking ahead, we have a Public Policy Consultation in February at NANOG. And the April meeting next year will be in San Francisco. So we hope to see you all there.

Fellowship Program, applications are now open for the San Francisco meeting. Encourage your colleagues, when you go back home, to apply. And that's all I have. Questions?

Kevin Blumberg: Kevin Blumberg. One very quickly. In the previous presentation, OTE was mentioned. Awesome testing playpen kind of area. We'd love to be guinea pigs. If you want us to look at UI, like what happened with the election bio information as an example, things like that, I'm sure there's a group of people that would occasionally be very happy to go and say this looks awesome, or this doesn't work on any of my devices.

Susan Hamlin: I'm going to hold you that you're going to be one of those people. It's on record.

John Curran: I'll hold him to more than that. I want him to help us organize those people.

Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. First, you guys have been doing a great job with the website. The improvements have been dramatic, and I'm very happy with it. Second, one small note of caution. A few of the times when you have improved the website - and the improvements were generally necessary, but things that you get used to going to in a certain place move, and learning the new place becomes tedious. So try to avoid as much of that as possible as you improve things. I realize some of it is inevitable. But thank you.

Susan Hamlin: Understood. Thank you.

John Curran: Thank you.

(applause)

John Curran: Next we're going to have the Human Resources Administration Department Report. I'll have Erin come up and give that.

ARIN Reports: Human Resources and Administration

Erin Alligood: Good morning, everyone. First I'll be starting with some updates specifically with HR and Admin team. I do have to click the button, don't I? We have had two new hires on our team. Denise Alston is our new receptionist. As Susan mentioned, we've had a new hire, Sarah Ba joined our team as administrative coordinator. And, again, as Susan pointed out, she's splitting her time between CMSD and the HR/Admin team. So Sarah is helping us with facilities along with booking travel for our employees.

(applause)

Erin Alligood: Therese is getting ready to celebrate her 13th anniversary with ARIN. Congratulations. We appreciate you being on our team.

(applause)

Erin Alligood: So you might remember from my last report we mentioned we were going to convert our timekeeping system. However, instead we decided to undertake a big project and convert our payroll and our timekeeping system. And the reason behind this was we wanted to improve our reporting features as well as improve upon the overall security of our employees' personal information. So we did that in second quarter. The switch went very well. And the system's been fully integrated.

So in addition to our standard facility operating and maintenance, as Mark pointed out in his presentation, we had a pretty busy year with our facility, and it's only going to probably get busier considering the space is a little older. So we had a repair to our HVAC unit and repair the UPS. But both are in working order. So that's good.

So moving on to some employee statistics, we have a total of 59 employees with ARIN. Five were new hires this year. And I'm proud to report that our retention is outstanding at 94 percent; this is a two percent increase since last October. So breaking down some of the demographics of our employee tenure in this next slide, you'll see that approximately 50 percent of our staff have been with ARIN for six years or more. Pretty impressive. But we also have a healthy pipeline of new talent that's joined ARIN within the last six years.

Moving on to some upcoming projects. We've been using the same review system for quite some time. I think we're all ready for something new. We'll be introducing this later this month with some training. And it will be rolled out in conjunction with our annual reviews in November.
We're also in the process of conducting a employee benefit survey, and this will help us further improve our current benefits package for our employees. We might make some changes based on those results or maybe add some new benefits for our employees.

We're also looking into some new options for our 401(k) plan in order to make it more attractive and more current, as compared to other companies. So we're looking at adding potentially a Roth 401(k) option along with a target date fund.
A target date fund is a default account that employees can gauge their investments based on their retirement year. So we think those two additions could really add some value to that 401(k) plan for our employees. And, last, we're hoping to improve our facility a little bit more by doing some carpeting and painting.

So thank you so much for your attention, and please let me know if you have any questions.

John Curran: Any questions for Erin? Thank you, Erin.

(applause)

John Curran: And now I'll have Val come up and give the financial services report.

ARIN Reports: Financial Services

Val Winkelman: Good morning, everybody. I'm going to talk today - there we go - about our staff, our new banking relationship, and then show you some payment and revenue statistics. We have just six of us in the accounting department, and Tammy Rowe is our accounting supervisor. She does a fantastic job. Four people are under her and two of them, Tanya and Mursal, have been at the Registration Services Desk since Tuesday. I hope you've all gone by and seen them. And the four of those, they help with the billing, the collecting, payments, RSAs and help desk. When you call the help desk, you're generally going to get one of those four people.

We decided to go out this year and look for a new banking relationship to try to curb some of the fees that we were paying. We found a wonderful bank. It was Wells Fargoand they have an excellent lockbox reporting system. They're going to reduce the costs for our fees. The estimate was around $40,000 a year. They're IPv6 enabled.

(applause)

Val Winkelman: Yes, I think they even talked at our last conference. And they provide E-Verify for ACH payments, which has always been a problem with Tammy because when they come in, there's little information for identification. So this was a huge improvement for us. They also have a great support team, instead of just one manager that you talk to. And their Visa cards are chip enabled for greater security for when we travel.

Bill Woodcock: If I could interrupt for just a moment. The person responsible for the v6 enablement of Wells Fargo was here in the room yesterday. I don't know if he still is. Jonny? Yes. Right there. Jonny Martin.

(applause)

Val Winkelman: Here's just a couple little charts. This is the payment types we've been receiving. We basically get checks and credit cards, and if you look at the chart, the checks, the dollar amount is much greater than the credit cards, but this is the first year we've actually received more credit card payments than we have checks. So we're definitely going into that area, which is great. We like to see that. And wires are not too much. This is the invoicing structure. Again, we have lots of AS and maintenance invoices that go out each month, but in revenue it's the IPv4 and IPv6 invoices that bring in the greatest money.. This is showing that it's pretty much staying fairly steady for the four revenue groups that I'm showing here. And this is just another look at the revenue mix, and again you can see that v4 is our main revenue maker. And the maintenance and transfers are coming, but the v4 is the greater of all the revenue we receive. That's it. Any questions?

Martin Hannigan: Martin Hannigan from Akamai Technologies. On the website, there's a Contact Us address that says billing@arin.net. It seems to be a black hole. I would appreciate it if you could fix that.

Val Winkelman: I'll pass that along. Thank you very much.

Owen DeLong: If you could go back to the revenue fraction slide for a second. Owen DeLong, Black Lotus Communications. The next one. No, forward. Forward. One more. There. So you've got v6 allocations and v4 allocations as if they're separate, but most people pay one fee for both.

John Curran: As it turns out, this is probably mislabeled. You're planning for category, and if your category is set because you have v4 and v6, it shows up as v4 here. If you're v6 only and that's how your category is determined, then it shows up as the v4 purple here.

Owen DeLong: I would suggest that that makes this graph pretty misleading. And it would be nice to put everybody who has v6 in the v6 category.

John Curran: For the moment now - here's my question. You just said something that sounds simple. Putting the v4, 6 - v6 revenue in the v6 category. For someone who has a service plan which includes both v4 and v6, how do you want us to allocate between them?

Paul Andersen: Paul here also. I'd just like to say let's not mix up registration statistics, which is another department, and the accounting, please.

Owen DeLong: I understand. If I can clarify. You're currently taking everybody who's got both and putting them in the v4 category. I'm suggesting you take everybody who has got both and put them in the v6 category, because that gives us a better perspective on the percentage of ARIN's revenue that is likely to go away as v4 fades.

John Curran: So I think what probably - following up on what Paul said. For this purpose, I'm not sure v4 and v6 distinguishing at this level is appropriate. Because what you probably need to do is think about them both as Registration Services revenue and consider that purple to be green. The analysis you want is long term under each of the fee schedules, if v4 returns come in, what does the revenue for Registration Services look like. You can't tell it on a graph either way. That actually has to be modeled. I've done the modeling. I'll talk about that when we talk about fee structure.

Rob Seastrom: Rob Seastrom, ARIN AC, Time Warner Cable, and a very small, as in would be extra small but for our v6 allocation which makes us small and doubles our fee, which is a discussion for later, where do we show up there? Do we get split pro rata?

John Curran: You're showing up in the v4. The only people showing in the v6 are people who have a v6 allocation and no v4.

Rob Seastrom: Thank you.

Val Winkelman: Thank you very much.

(applause)

John Curran: Now we'll have Leslie come up and give the Registration Services report.

ARIN Reports: Registration Services

Leslie Nobile: I have a quick update for the Registration Services Department. This is the current RSD team. This is the very hardworking RSD team. We have a total of eight analysts at the moment. I think most of those names look familiar to you guys. We have one analyst out indefinitely on medical leave. We're short staffed, and we've not changed our staffing levels for the past three and a half years.

I want to talk a little bit about our core functions. I don't usually do this, but I've been reading things on the Mailing List. I think people are confused about some of the things we do and how we do them. So obviously our main function is IPv4, IPv6, and ASN requests, including all the fun things that go with that, vetting and fraud reports and all those things. We get almost 600 requests in those three areas each month. We do transfer requests and related services, STLS. We're doing transfer preapprovals. Across the board with the 8.2, 8.3, and 8.4 transfers, we're getting about 50 transfer requests a month.

We do database record maintenance. We'd like to devote more time and attention to that to make sure we have an accurate database. We don't have the time at the moment, but we probably will in the future.

We do customer support. That's a big part of what we do, obviously. We have Ask ARIN, which is the questions coming in through ARIN Online. We're averaging 250 questions per month there. We run a telephone help desk. We operate that for 60 hours per week. We get about 1100 calls per month on the help desk.

And we do hostmaster@arin.net, which is the catchall for all the other questions and things that come in, and we get about 19,000 emails in that account each month. We also do have a very large role in support functions, which probably most people don't realize, and we spend a lot of time in those areas. Obviously policy development and implementation, staff assessments, implementation plans, policy experience reports, et cetera.

We work with engineering very closely in software development for a lot of the ARIN Online tools and software. We write requirements. We do the testing. We get - participate in all the sprint planning meetings, et cetera, et cetera. We are heavily involved in communications. We do a lot of writing. We're considered to be the subject matter experts in lots of areas of the registry. So we write guidelines and documentation, announcements, ACSP implementations, we write blogs.

And there is a new blog on IPv4 team review if anyone is interested. We released it yesterday or the day before. We do outreach. We participate in all the ARIN on the Roads. We do trade shows. We represent ARIN. We do presentations at various places, et cetera, et cetera. And lots of statistics and database analysis. We do monthly stats. We also respond to requests from the community for data, statistics, from the Board, from the AC, from whoever wants them.

So we have a lot of changing dynamics. We're seeing changing dynamics with IPv4 depletion. We have team review, which I'll talk about in some later slides. We see more out of region requests. We see more requests involving new technologies and services, things that we hadn't seen two or three years ago. We have a new customer profile. We have lots of first timers. A lot of ISPs are directing their downstream customers to come directly to ARIN for space. This is requiring more education, a little more hand holding with these customers. We spend a lot of time with them.

We expect to have an increase in our workload in the transfer area. That would be 8.2s and 8.3s. And we think we'll be seeing a lot more legacy holders coming in to get involved in 8.3 transfers in the post depletion world. And that is going to require an increase in vetting and chain of custody research because a lot of these legacy records are out of date. And a lot of the - because the legacy records are out of date, a lot of the 8.3 transfers will have to be preceded by 8.2 transfers to bring the registrations current.

So factors affecting IPv4 requests directly. Team review. Obviously it slowed down IPv4 request processes. Everything is serialized. All requests and responses, they're processed in a first in/first out basis. And they all now involve a second team member for each customer interaction. There are a lot of customer depletion concerns, concerns about unavailability of IPv4 later. There's some frustration with policies because people want what they want, they want what they need, and sometimes policies get in the way. And that's our job to implement and enforce policies. So sometimes there's a bit of a head butting there.

And then we are seeing some increased fraudulent activity. So this requires more due diligence, more staff time required to deal with the increase and potentially fraudulent requests and fraud reports. So the increase in the IPv4 workload. So we just went back to one year ago - I'm sorry, two years ago, 2012, and between then and now we've seen a 45 percent increase in the total number of IPv4 request tickets. And of course obviously there's more work involved in each ticket because there's more complexity. There's some more fraud. There's more red flags. We ask a lot more questions and, of course, team review.

So we're actually up to just under a thousand requests per month in IPv4. Up from, what, 650 two years ago. So it's also taking longer to approve IPv4 tickets. So the average approved IPv4 ticket length is reflected in this chart. Two years ago it was about 26 days from the time it takes to move the request from receipt to final approval - actually, to issuance. And now it's just about 38 days. So it is taking longer. There's more scrutiny involved. And our response times have been running at three to five business days. Our SLA is two business days. I am happy to say, actually, that we have been running a three business day turnaround time for the past week. I hope we can maintain it. Not sure, but we're trying.

So why are we doing IPv4 team review? Well, this is not a new concept. All the other RIRs who face depletion did team review very much like we're doing it. Everything that we do is processed first in/first out. That includes requests and responses. Whatever is in the queue that day gets processed in order. The reason we do it is there's multiple parties vying for this limited inventory, and we see the need for fair and equitable distribution of this limited resource, and this is the way that we think it works best.

And of course I've mentioned we have two analysts reviewing everything. And this is in order to ensure consistent application of policies and procedures. A second set of eyes guarantees them. So the way it works. I know there's been some speculation. So I'll briefly highlight how we actually do this. We have three analysts that get assigned about 30 tickets each day to review, with the oldest being reviewed first. They conduct preliminary review. They write their conclusions. They determine what policy they would qualify under. They determine what questions to ask, action items. They note it in a file.

We have a senior analyst who's dedicated to reviewing these initial assessments and responding. He's making sure that the policies are being followed and that we're applying the right rules, et cetera. And because the prep work has already been done, the responses can be done more quickly. So he follows up in order on the other three analysts who are doing responses - I mean who are doing analysis.

So we think it's more time efficient than having multiple analysts meeting, reviewing, and then responding. So just a clarification on the other things we do. I've seen some speculation on the list and questions. Specific analysts. We have four other analysts assigned to all other tasks. So IPv4 team review does not delay these. All of our other tasks are still responding within the two day response time per our SLA. Transfers are not team reviewed, but they do involve multiple analysts and all of the transfers are reviewed by senior staff or by me and then they're signed off on.

So our current IPv4 inventory is down to .63 /8s - /8 equivalents, sorry. In our reserve inventory; that which we call returned, revoked, held space that gets returned or typically that gets - that we revoke. Sits in a hold bucket, in a quarantine bucket for 60 days to clear filters. So we've got 14.9 /16 equivalents there. We still have a /10 reserved for NRPM 4.10 dedicated v4 block to facilitate v6 deployment. We've issued a single /24 from that block. And we've also issued I think about a 22's worth to the RIPE NCC who are conducting an experimental - I mean an experiment on routability of prefixes smaller than /24.

And then we have 225 /24s still remaining in the /16 reserved for micro allocations. This is the block size distribution. This is on our website. It gets updated every day. We don't have any 9s or 8s, but we have a 10 and 11, and we go up as high as a little over a thousand /24s remaining in our available inventory. So just to mention - someone had asked me about this, and I just want to mention ARIN does actually get space back from the IANA per this global policy for post exhaustion IPv4 allocation mechanisms by the IANA. That's a long one.

It says that the RIRs can return v4 space of any prefix size to IANA, and IANA will then reissue this returned space in equal allocation sizes to the five RIRs twice per year. That happens in March and in September. The policy was activated in May of 2014 when LACNIC reached their first /9. That is the activation of the policy. And IANA started with about 1.21 /8s in total, and they've now issued ten /12s, two to each of the RIRs. We got them in May of - we each got a single /12 in May 2014; we got another /12 in September of 2014; our next allocation will come next May of 2015.

I'm not quite sure how much that will be, but you guys are the math kids so you can probably figure it out better than me. Completed v4 market transfers. Transfers to specified recipients. We've completed 91 of them. That encompasses 53,628 /24s and 15 ASNs. And inter RIR transfers, we've completed 42 of them to date. That encompasses 5,048 /24s in total. Talking about ISP members with v4 and v6, we've been tracking this for a while. This one goes back to 2010. At that point in our membership our ISP members, 75 percent were IPv4 only and 25 percent had v4 and v6, and now, in 2014, at the end of Q3, 58 percent of our members are v4 only and 42 percent have both v4 and v6. And that's out of our almost 5,000 members. And I can tell you in that number there are 85 organizations that have legacy IPv4 space that also have IPv6 which makes them a member of ARIN by virtue of having their v6. That's all I have. Are there any questions?

Heather Schiller: So one of the things you mentioned was that the overall time - sorry. Heather Schiller, Google Fiber. One of the things you mentioned was the overall time for fulfilling requests on average has moved from 26 days to 38 days, but you also said things like a lot of new organizations are coming to you for the first time; they're not familiar with the process; you spend more time with them. Do you think that helps account for some of the amount of time that it's taking?

Leslie Nobile: I think so. We're asking a lot more questions in those cases and doing more education.

John Curran: Recognize that the total time is both our turnaround time when they give us information, takes us two or three days to respond sometimes because of the workload, and then we have to wait for them to respond to our response. So the total time is the sum of all those wait times. And, yeah, it's crept up predominantly because of when new people come, they don't understand what we're going to be asking. Even if it's on the website.

Heather Schiller: Right. So I was also wondering about applications that you see, like how often do they provide you everything that you need in the application sort of on the first or second try, like how bad is that?

Leslie Nobile: Almost never do they provide us with what we need up front. We tried to make it simpler. Susan mentioned we put up examples of how to provide the data to us. I think that's actually helped. But especially with newcomers we have to ask questions. They don't know what to provide, they really don't.

Heather Schiller: My second question is about - and I'm not sure if you had a slide on it, but the order that you allocate space in. So you have like a /10, 11, maybe like a 13 and a 15. Which block do you fragment first, because we'd heard -

Leslie Nobile: We've talked about it. I've been discussing it with my staff. Typically we would go to - so if somebody needs -

Heather Schiller: Somebody needs a 14.

Leslie Nobile: Yes, yes, we would likely go into the 13 and break it. That's what we're talking about. Don't hold me to that. We haven't decided for sure. I want to take that back and talk to -

Heather Schiller: Someone had said that you go to the largest block first. That's concerning.

Leslie Nobile: We have done that as well. We're still discussing. No need to panic yet.

Heather Schiller: Sorry to disagree with you, but, yes, actually panic now because if there's only one or two left at the top, so like going - really, like if you go and break the /10 and someone comes and asks for a 10, you can't give it to them, when you could have broken the 13. So that really does actually have an impact.

Adam Thompson: Adam Thompson, Manitoba Internet Exchange. The experimental allocation that was delegated to RIPE for that routing experiment, is there any ETA on when they're supposed to be producing results for that?

Leslie Nobile: There is. And RIPE is right behind you and they're going to tell you a little bit more.

Kaveh Ranjbar: Kaveh Ranjbar, RIPE NCC. We actually published - after four days of running the experiment, we published a basic set of results. We are planning to run it for about six months to compile a complete results set, but just to quickly tell you about the results, for a /24, after four days, 92 percent of our peers all around the globe was able to see them; for a /25, 14 percent when there was no route object and 20 percent when there was a route object present; and for a /28, only 15 percent when there was a route object and only ten percent when there was no route object. That's the resource after running it for four days. But I hope by next NANOG we will produce a more detailed or more scientific report.

Kaveh Ranjbar: 24 after four days was only 92 percent. But that's the usual. With or without route object the /24s were 92 percent after.

Paul Emmons: Paul from Internet Operating Services. Just a quick aside. Since the last ARIN meeting, I've done a couple ASN and IP requests for ourselves and other clients. And we've provided information that's normally required, and in the past I'd know it was going to be asked in the first request, but it still seems even with team review they're asking for information that's already been attached, already been provided, and that's just slowing down the process more and more.

Leslie Nobile: I've heard that in our customers' transactions a couple of times. And I work with my team on that, and I will continue to.

Paul Emmons: Also, there has been one incident on our part where a ticket number has delayed the actual assignment of the resource because accounting had one ticket number and Registration Services had another, and we're waiting around for this other allocation and it just somehow happened to have the wrong ticket going into accounting. Is that done electronically?

John Curran: Take that offline -

Leslie Nobile: We can talk about it afterwards.

John Curran: That sounds strange.

Leslie Nobile: Doesn't sound right.

John Curran: I'm going to close the queues shortly. If you want to speak on this, come get the queues.

Dan Alexander: Dan Alexander, ARIN AC. I was curious, not free pool allocations but if we just focus on the transfers, we were debating proposals yesterday about eliminating need to make the processing more efficient. Do you have a sense of when you guys are doing a transfer review how much effort actually is going into that needs assessment versus how much effort goes to assessing the chain of custody that it is a valid resource?

Leslie Nobile: Interesting question. I don't really have a sense of that. All requests get vetted and we do the chain of custody research and then we do the needs assessment. I'm not actually sure.

Dan Alexander: I was just curious if one was higher than the other.

Leslie Nobile: I will look into it and get back to you.

Terri Stumme: Terri Stumme, DEA. I was just wondering, you mentioned obviously there's an increase in out of region requests. Is it possible to get stats on that, the number of requests coming in and what areas?

John Curran: How do we know it's out of region if they have a legal -

Leslie Nobile: Yeah, they have a legal entity. I mean, it would be a guesstimate.

John Curran: The challenge is that it only comes up when verifying the information and we start asking them so we want to validate why your - your past resource usage, and then they give us a list of - like can you show us the customer assignments or the POP assignments for the dynamic pool, and then they give us back a list of addresses that are in an Asian character set. And we go, well, okay. But we don't - because all the requests have to come from a legal entity in the region, it's not recorded specifically. It's only something we observe when we're trying to process the request during the needs assessment.

Leslie Nobile: To add on to that, I actually have asked my staff to record it in summary files in our own internal files. We might be able to grep through some of those and look.

Sandy Murphy: Sandy Murphy, Parsons. I apologize. I was trying to review the past history to substantiate my thought. In past reports from Registration you have talked about legacy RSAs and the percentage of the space that's legacy and under RSA and not under legacy RSA and how many are current members and all that sort of stuff. And it's been a while since I've seen those figures. I found it in 2012.

Leslie Nobile: It's actually on the website. We publish it on the website. I haven't included it in the presentation because it is on the website. We don't see a lot of activity in the legacy RSA area. Maybe once a year at this point. But it is on the website.

Sandy Murphy: But the percentage of the ARIN managed space that's legacy is interesting to me.

John Curran: All the space is ARIN managed. You're saying the percentage done per service agreement versus done otherwise? All of the address space in the ARIN region is subject to ARIN administrative policy.

Sandy Murphy: Yes, I know that. But there's some of the space that is under ARIN management that is considered legacy and not under an RSA.

John Curran: Right. And if you go to knowledge and you -

Sandy Murphy: I'll find it. No need to take people's time to give -

Leslie Nobile: If not, send me an email.

Sandy Murphy: Thank you very much for this. It's a wonderful piece for those who are info junkies.

Kevin Blumberg: Kevin Blumberg. I believe I said yesterday I love statistics - well, I hate to love statistics or I love to hate statistics. One of the things with the requests you're doing if you're doing it just based on the global number of tickets, it really doesn't get a sense of for me what's the most important part, which is how often you're touching an overall request, and you talked about finding it very hard to see the three to five business days as an example.

One thing to consider is including the number of times you've had to go back. So we had 5,000 requests. Sorry, 5,000 total requests, and 4,000 required eight interactions; 1,000 required one interaction. That piece would help moving forward.

Leslie Nobile: Somebody wrote that down because I won't remember. But we'll have it.

Kevin Blumberg: The second is are you planning on doing anything from a surge perspective over the next potentially two to three years as things continue to ramp up? Is there a plan in place to deal with the surge that you are - that's been going on now for two years, showing from your slides?

John Curran: Are you saying in terms of staffing?

Kevin Blumberg: Yes.

John Curran: Ah. Excellent question. Do you believe that the workload will continue to ramp up past - let's put depletion between first quarter next year. After that event, first quarter next year, and you're looking at budgeting for the future year, for the 2015 year, do you believe when there is no inventory that we'll still be getting a healthy workload of allocation and assignment requests all going to a wait list?

Kevin Blumberg: I believe it will be worse because what will happen is a couple of things. You'll now have people who are trying to figure out what they have to do to get IPv4 space and having never even come to ARIN, like you're seeing now, they're upstreams, that will continue. They won't understand the transfer market. That will continue. Your outreach to help these people. So I think they will potentially be different parts but all part of RSD, and I don't see that really diminishing, John, in the next two years.

John Curran: I was thinking a lot of them would end up being pointed to the specified transfers facilitator list, the broker list, we do direct quite a few people there now who have requests that aren't going to make allocation policy.

Kevin Blumberg: There are people - anyway, my point stands. We can - I don't want to spend too much time on it, but I think that ARIN having their own plan potentially to look at surge I think is important, because the last point I was going to make was I believe that the outreach that the RSD does, that is potentially the first thing that's going to get cut in a situation where you haven't - where you're not ready to spool up is critical. I've watched help desks during NANOG help new entrants with their issues, and to me that is critical.

John Curran: Good insight. Thank you. Go ahead, Marty.

Martin Hannigan: Not sure if this is the right spot, John, but Proposition 213 suggests there will be an increase in the CI pool. Where would those addresses come from? From this distribution here or somewhere else?

Leslie Nobile: From this distribution, that's what we've got.

Martin Hannigan: One other question. Can you talk a little bit about what's happening in the CI pool right now. Seems like there's a pretty considerable amount of requests coming in. Also there was a suggestion about sparse allocations, and I don't think I've seen that go out yet. Is that going to be coming out at some point?

Leslie Nobile: We have to go back and work on that. We've not done that yet.

Martin Hannigan: The suggestion has to wait until you guys work on it, or vice versa?

Leslie Nobile: We need to plan for it.

John Curran: We need to double check that we can implement it, and then we'll respond. I don't see a difficulty with the sparse allocation suggestion. With regard to the CI pool, we don't really report on the requests against the CI pool.

Leslie Nobile: We don't. But I can tell you from personal experience, obviously, that we are seeing more Internet exchange requests under the micro allocation policy for sure.

Martin Hannigan: And the three participant rule has not been a barrier as far as you know?

Leslie Nobile: Doesn't seem to be. We can add more information.

John Curran: We can add reporting of the CI pool to the future reports so you can see a update. Thank you, Leslie.

Leslie Nobile: Thank you for your attention.

(applause)

John Curran: It's break time, but we're also a little behind schedule. I'm going to ask Richard Jimmerson to give a customer survey report and then we'll go to break. So just hold tight. We'll get through one more.

ARIN Customer Survey Report

Richard Jimmerson: Thank you, John. I'm Richard Jimmerson. I'll give you an update on the survey. A lot of you were probably present for the meeting last six months ago when we actually did an update of the survey for all of you.

What we did is we took a survey from the third party that actually conducted it on our behalf and we give you an untouched, full version of what they had given us. You saw all the raw data, everything that they had given us. There was some real positives in there, and there were some real negatives in there. And we want to let you know we've been working hard as an organization over the last six months, so making improvements inside the organization, to answer a lot of the things you had to say to us inside this survey.

We will be doing another one of these surveys in about one year from now. We'll be getting that started and we'll be conducting it again. It will allow us to create some markers and actually see where we've made progress or perhaps where we've regressed, where we can start doing some more work inside that area. Some of the post survey activity, you've actually heard in some of the reports that have just preceded this presentation. We've started making improvements in areas where you pointed out to us where there were some shortcomings.

Some of those things had to do with refining registration process documentation, some of the navigation on the site and things along those lines. We've been doing a lot of work inside that space. One of the main things that was actually called out on the survey was a desire for us to actually incorporate more Internet governance content into our meeting agendas. You saw we dedicated a good portion of our time yesterday on that topic specifically, and we're starting to pay more attention to that going forward of course. One of the more significant things we did inside the organization during the course of conducting this survey and as a result of the survey results that we got is we added a customer advocate review and approval to all changes to our customer facing products and services inside the organization.

I was inserted as a customer advocate inside the company. So every time there's a change that's made that will touch the customer, that will touch anything that you see or anything that involves an interaction with you, it requires review and approval by me inside the organization as the customer advocate. I take a pure customer advocate view of everything that's going on inside the organization on your behalf.

And that's been an interesting process over the last six months. But I think that we've made some really good decisions as a result of it, as an organization over the last six months. Another thing that we do to review feedback from you in addition to this large survey that we did earlier this year is we do transaction surveys. So every time there's a request for v4 address space, IPv6 address space or autonomous system number, we provide a link to a transaction survey. Quite a few of you do use those transaction surveys. The results are reviewed on a daily basis by the director, Leslie, and that department. And she regularly reports that information to both the Chief Operating Officer and to myself, and we sit down and we have discussions about that.

But Leslie and her team, they are making adjustments in real time as they're receiving feedback from you. For instance, Leslie brought up just at the microphone a few moments ago that they had received some comments about perhaps we're asking a question when the information's already available, and Leslie's constantly coaching her teams based on the feedback we're receiving in those transaction surveys.

One of the other things that we did to hear more from you in terms of what we're doing as an organization and how we can improve is we launched a Feedback button on our website. That was on our public site and it's also available inside ARIN Online. We received pretty good traffic on that over the last six months. We launched that on April 5th of this year. And here's some stats through October 1st of this year. About one third of everything that we received over this Feedback button is for the intended use, the type of things that we're looking for when we put up that Feedback button. And I think that's a pretty good result.

We were kind of afraid that maybe it would be less than that, but one third is really good amount of interactions with us for the intended use. So some of this stuff is more Internet help desk related. I'll give you a few more examples of what that looks like. 29 of them were "stop attacking me" type of messages. And the largest grouping was tests in spam. Early on we did a lot of tests to the Feedback button. I counted those. But there were people that were trying to sell our organization everything from the type of services that you provide in the room to furniture for our offices and things like that, using this Feedback button. It's pretty interesting. But we do get that, too.

Here's some samples of what the intended usage of that Feedback button were. Someone had told us the site is slow and fails to load pages. It eventually loads after many retries. Most problematic when filling out forms. So this was someone one day, they were in ARIN Online, and they were submitting requests. They were filling out forms inside ARIN Online. They noticed that things were moving slow. They submitted something on this Feedback button. Exact intent of what we had that there for.

And we were immediately able to contact our ops team inside the organization. And they actually did, they found some processes that were going on that were slowing things down. They immediately corrected this. And we were able to get back to that customer, let them know that we did that. And also this fixed this for everyone else who might have been having that problem who hadn't spoken up yet. That's a great use of this Feedback button, and it's really helping out. Here's another example of the intended use. An organization sent something to the Feedback button and they said Person One no longer works for us. How can he be removed? In addition, I would like to add Person One and let him have the same functionality as Person 1. Can this be done? Thanks.

So basically this is an organization where they had one individual that was managing all of their interactions with ARIN and that person left the organization. No one else in the organization understood how ARIN worked or exactly how they would manage their resources, and they couldn't find the place on the website where they might go find out that information or how to contact us otherwise. So they used this Feedback button.

This helped the customer and helped us in two ways. It helped the customer because they got a response from us, got the information they needed. The way it helped ARIN, the organization, is there was a customer with a need and we were immediately able to help them. There were other channels they could have gone through and we would have been able to help them there, too, but a second important thing it did is it told us that it might not be obvious to some of the customers using our service where to actually go and get this done.

It helps us when we're improving our registration documentation and those types of things on the website to get this type of feedback, and it's been very helpful. And here I'm going to move a little bit faster. Sample Internet help desk uses. Read through these. My Internet is not working, my games aren't working right and can you fix it for me? We get a lot of that. We really can't help this kid, but we sent him a message back and responded to him.

This other person forgot their password from Facebook and Yahoo! and they want us to help them log in again. We get a lot of stuff like that. We also get that at hostmaster. Some people want us to stop attacking them. Someone saw that an address in a TIN network was attacking their network. So they went to Whois and they found out that that's registered to ARIN, so obviously ARIN was attacking them. We get that a lot. Someone else you can see had a similar problem and they want us to stop spying on them.

That's it. Feedback button has been great. And it's been wonderful working with you guys over the last six months, and you've got a great team inside the organization that really does care about what we do for you on your behalf, and we're going to continue to do that. Thank you very much.

John Curran: Any questions for Richard?

(applause)

John Curran: Thank you, Richard. Okay. We're going to move to break and we're going to come back most expeditiously. So it says that the break is - it says the break is five minutes. I'm going to give you 15. I'll see you back in here promptly at 11:00.

(Break.)

John Curran: Okay, we're here. I'd like to resume the program in progress. Next up is John Sweeting who will give the Advisory Council Report. If people will come in and be seated. John, I'll turn it over to you.

ARIN Advisory Council Report

John Sweeting: Good morning, everyone. I'm John Sweeting, chair of the Advisory Council, giving my last update on ARIN Advisory Council as the chair of the ARIN Advisory Council. So the Advisory Council consists of 15 elected members with three-year terms. Here's a picture of the current mug shots of all of us. So this year is a - like every year is an election year. So the AC members serve three-year terms; five members up each year. Terms ending this year are myself, Dan Alexander, David Farmer, Bill Darte, Kevin Blumberg, and Andrew Dul.

You notice there's six names there. That's because Andrew filled out the term last year for Bill Sandiford who moved on and went to the Board. That's a one-year appointment, and that position has to be elected this year. So the top five voters will each serve a three-year term. The next two vote receivers will serve a one-year term this year. And there's 12 nominated individuals for the seven positions that are open.

So Stacy Hughes, I'd like to take a moment and recognize her for her outstanding 12 years of service to the ARIN community. I'd like to ask Stacy to come forward to the stage. Stacy has been an amazing asset on the Advisory Council. I don't want to start any bad rumors, but when something needed to be abandoned and we were hemming and hawing, she was the one that would come out and say: Why aren't we just abandoning this thing? We're going to miss her on the Advisory Council. But I want to take a minute to recognize her service and present her with -

(applause)

John Sweeting: I know Stacy doesn't really like microphones, but I'm going to give her a moment.

Stacy Hughes: Thank you so much. The funny thing is I'm not very good at speeches but I'm good at toasts. So cheers to me.

(applause)

Stacy Hughes: No, no. Really, cheers to you. I thank all of you for your participation and the guidance you've given the Advisory Council over the years and especially for me, helping me grow in my career, on the AC, and as a person. Thank you so much.

(applause)

Vint Cerf: I'm sorry, I have to interrupt. I don't understand why after someone serves for 12 years why we give her something as perishable as a bunch of flowers.

(laughter)

John Curran: She has a plaque.

Stacy Hughes: I have the glass thing at home.

John Sweeting: So next up I want to recognize someone with a clue, Mr. Bill Darte. An original member of the Advisory Council. Come on up, Bill. I noticed you both sat in the back of the room so you could do the walk up the aisle.

(applause)

John Sweeting: This isn't the only thing Bill's going to get either, Vint. But we do have this certificate of appreciation which reads: This certificate is presented to Bill Darte on 10 October 2014 in recognition and appreciation of outstanding service to the ARIN community while serving on the ARIN Advisory Council continuously from 1997 through 2014. Your contribution is invaluable in the support and advancement of the Internet. Thank you, Bill.

(applause)

John Sweeting: The last original member of the Advisory Council.

Bill Darte: It's an honor to be here. I'm grateful for the original Board of Trustees by honoring me by making the selection they made amongst all the applications that they must have had to serve on the original Advisory Council, great honor and validation of my educational career and the many people I've served and help understand what the Internet was and all that sort of thing. But the continuation of that was the community re-elected me for all these years to serve them. And I can - I'm really grateful for that. It's been an honor and a privilege, to be sure.

The Advisory Council is a very important part of this community effort, and the people that I've served with throughout - I've seen criticism at times about the Advisory Council, but I'm here to tell you, having been there, all the time, that there's no greater service that has been rendered by the most professional and dedicated people I've ever worked with, have been continuously serving on the Advisory Council. And, again, it's just a great privilege to have been involved with this great organization and all the staff and Board for all these years. But of course what I'll miss the most is all of you. I've formed great relationships with so many of you, and it's just been an honor. Thanks.

(applause)

John Sweeting: Okay. Thank you, Bill. So the mantle passes on to Cathy. Cathy is the longest standing Advisory Council member. I'm not saying anything about your age, Cathy, just how long you've served.

So the AC role in the Policy Development Process. We work with authors on proposals to ensure a valid problem statement. We move it to Draft Policy. We gather input from you the community through several means - PPML, PPMs, PPCs. I think everybody knows those acronyms so I'm not going to extend them out. Once we get that and we feel - the AC feels, hey, this is ready to become policy, we move it to a Recommended Draft Policy which we then present at a Public Policy Consultation such as this, gather the last - make sure that we got it right. If we have it right and we get the support that we feel we're going to need to move it to last call, to policy, we then move it to last call, making sure that everybody else that didn't - wasn't able to attend the meeting, gets one last look at it, and then we recommend it to the Board of Trustees.

In 2014, it was a busy year, second busiest I think ever, as far as proposals go. There were 23 new proposals. Six went to the Board of Trustees and were adopted, four were abandoned, one is currently recommended, nine are currently Draft Policies, two are still - are just proposals that have just come in, and one was remanded back to the originator who dropped it. And there was also two from 2013 that were Draft Policies that moved to Recommended and went to the Board.

So the Advisory Council does a lot more than just policy, though. We basically are asked by ARIN and ARIN staff to fulfill a lot of volunteer obligations. And we take that pretty like - it's cool. It's great. We get to go to the Fellowship program, we get to meet with the first timers, help them navigate their way through the meeting. We participate in the outreach program, which is ARIN on the Road. We do some conferences such as CES, Interop, and a few others. And mostly we focus on the IPv4 depletion and IPv6 education and promote ARIN meetings. We also had two members that were selected to participate on the Nomination Committee, and we do - we participate in anything else that staff needs augmentation for. They come and they ask the AC: Hey, you got anybody that would like to volunteer for this? I think we've almost always stepped up and fulfilled those.

So that's it. I got one last thing since this is my last meeting as the chair of the Advisory Council. I would like to thank all of ARIN staff, the entire ARIN staff and the community. But I would really - I would feel bad if I didn't really name these guys that have helped me through the last six years - that's Einar and Nate, Leslie, Susan, Therese, and J.C. These guys have been there and supported me through those six years and made it a lot easier. So thank you and remember to vote.

(applause)

John Curran: Okay, moving right ahead we have the Treasurer Report. I'll invite Paul Andersen, ARIN's treasurer.

ARIN Financial Report

Paul Andersen: While we're waiting for the slides, can we give a proper round of applause to Mr. Sweeting for his years as chairman.

(applause)

Paul Andersen: We can't forget about you because I know it's been an honor working with you in various roles, and I know he's done the AC very well. After I find my clicker, I'm going to give a brief treasurer's report. I'll be faster than usual so I can save some time for the next presentation which, hint, has to talk about fees. If you have fees questions, we're happy to take them in the next one. But just to give you a quick update. So for those that don't know, I am ARIN's treasurer and also lead the Finance Committee, which is also composed of fellow Board members Bill Woodcock and Aaron Hughes along with John Curran as staff liaison.

We're responsible for overseeing ARIN's finances. I'll just go a bit backwards in the presentation. We've had reasonably quiet time since you last saw us, but the fall really does get very busy for us because that means we're about to - it's already underway, our budgeting process for next fiscal year, which is also calendar. Over the coming months the Fin Com will be working with the staff to develop the budgeting for next year. It was so subtle I didn't even notice it came up. Having said that, over the last - since we last saw you, we dealt with our annual 990 filing, IRS. We've been - we wrapped up the Fee Review Committee, which of course we'll discuss next, and we met recently with our investment advisors just to make sure that - and see what trends we might be seeing in the future.

To give you a quick snapshot, and I know that earlier we kind of went over some of the revenues, but revenues are pretty much as expected and on target. Expenses are not also reasonably on target. We're looking right now at about a 2.6 million net to reserves. Again, part of that from an operating result but a lot also due to very positive returns from our investments in the market. Just giving a quick overview of where we are financially. And these numbers are as the end of August. We've seen a reasonable downtick in a few areas. Notably, communications is down a little bit due to a renegotiation for connectivity.

Depreciation is also not where - is a little higher than expected. That's just due to some timing of some of the projects that are ongoing. Mostly that's driven by a lot of Mark's engineering projects because they tend to be the capital intensive projects. Professional fees are actually quite down due to - again, mostly due to some engineering professional services that we were planning to engage which have just been pushed out a little bit. And there's also been some changes in where amounts are budgeted. Specifically there's been some change to where travel is budgeted when it has to deal with outreach. General office is down a little bit because we've delayed some renovation projects.

Legal in both amounts is much higher than expected. The legal defense fund item, that just has to do - we don't generally actually budget for that. That tends to be where we catch some of the various court cases that we've been involved in. Not necessarily litigating in but a lot of the bankruptcy court cases we sometimes have to get involved with and intervene. And I can leave it to John, if there's any questions on that. And legal itself has been a little higher than projected.

Gotta make sure I'm on the same slide. Members Meetings are actually down a little bit. That's actually a bit due to some optimizations on just overhead costs but mostly thanks to increased sponsorship. So thank you to all our sponsors for helping out on that. And the last one is travel has been significant - is down quite significantly. That has been thanks to the efforts of both staff, the AC and the Board, which we have been trying to be more efficient in how we spend on travel and also we've been tighter on who we actually send to those events, because we know we've had some feedback on that.

The last one I'll put is that our funding for ICANN is just a little bit different. That has to do with just the fact that the formula that the NRO uses for the - what our contribution changed last year. We budgeted under the old formula and the new formula had a slight variation. Reserves continue to grow, which is always good that they're in the right direction. Just to give you an idea, there's kind of been our reserve history. Again, ARIN has been very lucky and gracious, thanks in part to our good investment advisors, that we've had very good returns, except for in 2008 when most people had a bit of a dip.

And just as a reminder, we do keep a policy. We do try to keep between one and two years. We're starting to get to the upper limit of that. So the Fin Com and the Board will be discussing ways that we can deal with that, whether we'll start drawing down more from the reserves or other ways we can utilize that. I would welcome any feedback either now or later that the community or members may have on either how we could - what we would use reserves for or any input you may have as we get into our budgeting policy. That is about all I had, noting that fees are about to come up. If there's any questions?

John Curran: Microphones are open. Thank you, Paul.

(applause)

John Curran: Okay. We have two presentations before we're done. The first one is I'm going to give a - I think it's two. Let me double check. I'm going to give the fee structure discussion and Vint Cerf, our chairman, will do our Board of Trustees report. I'm going to talk about the fee structure review process and what was produced. And then we'll have a little time for questions, recognizing that we still have Vint's report and an Open Mic for everything else.

ARIN Fee Structure Discussion

John Curran: Fee structure review panel. The last time we changed our fee schedule, which was in - it was discussed in 2012 and we changed in 2013. People said: Well, you just did an incremental change, and we're not even sure if that's the right approach. A lot of philosophical questions came up about how the fees should actually be structured, not what a particular line should look like. So we impaneled a Fee Structure Review Panel to consider various long term fee structures that were suggested by the community on the topic and summarized the pros and cons back to the ARIN Board and community.

This draft report of the Fee Structure Review Panel is complete. It's a balanced document describing each of the approaches on how ARIN might structure its fees going forward. We actually used the full year numbers from 2013 to model. So we actually have in the report what the current membership would look like and the current fees and revenues would look like for each of the proposals. And then it provides a common basis of discussion for the merits of the various approaches.

It does not provide a recommendation. The goal was let's model these and see what they look like and let the community discuss what they think of that. It covers seven alternative approaches for - actually six alternatives and the current baseline for ARIN's recovery of costs in all contracted parties for registration services in a fair and equitable manner. The members of the panel: Paul Andersen, Aaron Hughes, Bill Woodcock, and myself, and then we called from the community and at large members Tim St. Pierre, Steve Feldman, Brandon Ross, Daniel Alexander, and Michael Sinatra. Because the Fee Structure Committee did its job and produced a report and is now concluded, I'd like a round of applause for these people.

(applause)

John Curran: Hopefully their report will prove useful in the discussion. The report was sent out last month to ARIN Discuss and ARIN PPML. You can get it online. There's a URL on this presentation that links to that message. It covers, as I said, the current fee structure and six proposals. There's a short summary of each proposal, what it proposes, what the pros and cons would be. I've actually included them in this presentation, but if you go to the actual document, you'll find an appendix for each one of these proposals. And each appendix has the full table and the fee table for each one and the modeling against the current membership - or actually the 2013 membership and a graph showing what it looks like as a histogram of the fees as applied to the membership.

So quite a few pages to the document. I'm only going to go through the summary of each of these. We're going to open up a community consultation next week. We will have it on ARIN Consult. It will be available to anyone - member, nonmember - to participate and to read this document, give your thoughts about what direction, if any, ARIN should take. It's not inevitable that we have to change the structure of the fee schedule. But if you want to take it in a certain direction, here's six possible directions and you can advocate for one and explain why. I'll say at the end of that process I'll summarize all of that. I'll bring it back to the ARIN Finance Committee, the Board of Trustees Finance Committee. They're the ones who actually make recommendations to the full Board for any fee schedule changes. So they would be the ones that set staff off in a direction to develop a specific fee schedule for everyone to consider.

So it will be community consultation, summarize the ARIN Fin Com, and then if they direct me to model an alternative, I'll model one and bring it to you folks. So the current fee schedule. And I think everyone knows the current fee schedule, but I'm going to summarize really quickly. We charge - we have two different ways of having fees. One is for service providers who pay an annual registration services subscription and one is for end users that pay a fixed maintenance fee based on the number of records. Legacy holders pay under the end user fee schedule, recognizing that most legacy holders have a cap. They can only charge - Nate, are we at 125 this year? Going to 150. There's a cap in the LRSA that says it's $100. It can go up 25 per year. We've raised it once.

Legacy holders pay as end users for their records, and there's a cap that over time it will slowly ramp up as we raise that to match other members. Okay. ISPs pay based on an annual amount based on the service category that accommodates both v6 and v4 holdings. So there's a tier, and based on where you fit in v4 and v6, whatever category will meet both of your holdings is what you pay. And the fee step going from $500 a year up to $32,000 a year. Organizations with larger holdings pay that top category, xx large, $32,000 a year. And that's also in an appendix in the report. The benefits are simplicity. Based on the size of your holdings, you're in a simple category. You can budget it every year. If you get resources, unless you get a lot of resources, you don't necessarily change. So it's fairly predictable. When you do get a lot of resources, yes, it can move to a different category.

It provides a single fee that covers both v4 and v6, which means that everyone who has v4 resources can get v6 without necessarily having their fees change. Now, you may not get the amount of v6 you like, and that's a question. But everyone can get v6 without any corresponding change in fees for some size of v6. There's a problem at the bottom end of the scale which one of these talks about. And the simplicity also means if we want to change fees, it's very easy to change one table of fees, lower them. We've lowered the fees several times over the years. So that's the current schedule. The concerns. Couple of concerns that were cited that kicked off this process. The larger 17 ARIN members actually have more space than the top tier. They may not be paying - if we had an infinite number of tiers, they may not be paying what people would expect for the size of their holdings.

Additionally, the present fee structure is interesting in that it provides benefits for ISPs because - versus end users. If you're an end user with a lot of resources and you're paying $100 each, you could end up paying more than a small ISP. On the other hand, if you're an ISP, once you are an ISP, you pay a fixed fee regardless of how many address blocks you have. There's a little bit of advantage to both categories. There's a difference between end users and ISPs even though there's not necessarily a difference in the services we provide.

Quite frankly, address blocks and registry maintenance is extremely similar with a very small number of exceptions that are very hard to account for. So we have two different categories now, and it's not clear whether or not that's - there's a reason for that. And then there's some concern about the alignment, as I said, between v4 and v6. Presently, if you go to get IPv6, because of the current categories, if you get something allowed by policy, you will end up seeing an increase in your fees. These fees are lower than they were in 2012, but it's still a net increase.

Okay. So here are the proposals. Okay. Proposal One is the current one. Proposal Two. Very simple. Extend those v4 categories. Add xx large and xx large. Actually the table is very nice. It actually gives xx large, xxxx large, huge, xx huge, xxx huge, goes all the way down to any possible address holding. But realistically it only affects about 20 percent of members of ARIN. The fees keep going up. We end up with fees, 124, 164, and 128,000. Is this appropriate? If you feel that people with large resource holdings need to pay more, it might be.

But recognize that an address block in the registry actually doesn't really cost that much more to ARIN in terms of our actual costs. You're really charging more because someone sees more value to it. And also the more our fees are based on v4 holdings long term, we have to worry about what happens when v4 goes away. If you have all this revenue and everything's great and then ten years from now everyone returns their v4 block, you get to see everyone's category drop precipitously down because everyone is sitting in v6. You may not want to drink the Kool Aid even if you want it. So there's some pros and cons.

Another issue. Realign IPv6. And this is basically addressing that xx small issue. Basically by taking the lowest tiers of the IPv6 category and having them start three tiers up so you can get an address block of reasonable size, up to a 32, without paying anything more. You don't have to take a smaller v6 block. This has been cited by people as a way of preventing v6 discouragement that we currently have in that if you're the smallest ISP category, you'll pay more to get v6. And we're not trying to do that. So we should fix it. Note that there's a counterpoint which is that, again, long term a lot of people end up in v6 in very small categories. And if everyone ends up in the bottom category, then long term we need to know what it looks like modeling, yes, modeling for the fee schedule.

So as it says here, a re evaluation of this policy may be needed when IPv4 usage is in decline to determine if revenue will be heavily impacted. Okay. The next proposal is linear IPv4 categories which creates granular categories which go linearly up and down to all sizes, and it means that the top end it's a $400,000 fee for the largest address holders. And it's believed to be a very equitable and fair if you want to base it on holdings. And in terms of concerns, obviously the largest fees in those categories would be a surprise to people who got those invoices the first year we sent them out. So we're thinking about.

Algorithmic, it's been noted by some people rather than having discrete categories one way to solve this and be quite proportional would be to use a formula based model based on total addressable allocations. So this was modeled. And it provides a very smooth increase as resource holdings increase. The analysis is in the full document. The good news is that it rises proportionate. It would be very simple to change total revenues by adjusting the fee. We know other regions - APNIC has experimented with this. The concerns, of course, is that we need to make sure that whatever we model matches our revenue increase so the formula needs to be tweaked the first time we do that.

The fee amounts don't fit neat buckets. You'll end up with invoices with not round amounts and they'll vary on any resource change. And so some organizations have indicated a budgeting issue with that. Okay. Next proposal would be a member based fee proposal. And this is based on looking at a flat membership for all ARIN organizations that encompass everything ARIN does. And this excludes - this is based whether you're an end user or an ISP, included all in the member based fee. Everyone pays the same fee. If we actually counted all organizations using ARIN's services either v4 or v6, then we could actually set an annual fee of $1,400 a year. It would be completely independent of your resource holdings, everyone would pay the same. Very easy to handle. It would be a relatively low cost number for many organizations. Of course, not for all.

Nearly all end users under this model, rather than paying $100 per resource per year, would see an increase in what their current invoice is. The fairness of this presumes that everyone benefits equally from ARIN or that the industry benefits equally and everyone should pay. And that is not necessarily the case. It's an indirect function. So we have to decide how important it is to be equal among all of us. Many organizations have different fees based on different sizes. If you take that last model and you try to lower the fees to the lowest number you can and break out discrete transaction costs, you end up with a transaction fee based proposal where we have a single flat fee for everyone and significant fees for transactions, because we know people who come in and do transactions with ARIN do end up with us incurring costs.

Under this proposal the fee would be $880 a year. In addition to this, the per transaction fees would be established for new resources, and resource transfer requests at $1900 and $3800 respectively.These would be reviewed, could be reviewed and adjusted annually. Registry holders would have a very low cost fee. Everyone would pay the same. Transaction fees would make sure that the parties incurring costs to ARIN would pay them. We don't need to have - it solves the end user versus ISP fee structure. And it would dramatically increase ARIN membership. Everyone would be a member - end users, ISPs of all categories.

The increase, of course, to everyone would still be a concern. We would need to make sure we're collecting appropriately so we don't go through all the work of a transaction and have someone then not pay the fee and give up on the transaction. And there's a perception issue that the people who aren't using ARIN very frequently are subsidizing those who use ARIN more frequently even if it's not through transactions. It's just through help desk requests and calling in, et cetera. So those are the proposals. And they go different directions. And now we're going to be able to have a consultation out to the community. There's some discussion topics in the report, and these are sort of some of the issues that are raised.

And some of the proposals propose significantly higher fees for larger numbers, ARIN's costs proportionate to address blocks and transactions, not discrete addresses. Is it equitable. Looking for equitable recovery. Is it equitable. ARIN's mission (to improve the business conditions of ISPs and the entire Internet community via management of Number Resources in the region) is a service to the entire industry. It's not just services to individual organizations. Does the argue of cost recovery should reflect a flat fee or not. Furthermore, trade associations, some of them, scale the membership based on the size of the participant. Is this better done based on revenue or budget by approximate of ARIN's fee structure does through total address holdings today.

One of the questions that comes up is should ARIN pursue a more service transaction based fee approach. If we take that, do we need to change what ARIN is. ARIN is a trade association for the betterment of the industry, and if we actually get specific about providing services and charging people specific recovery, then you actually leave the trade association category and you look like you're providing a for profit business. So that's a directional change that could have an organizational change. And then the vast IPv6 address space allows for very large blocks, and there's very few counter pressures to that causing people to right size their v6 block. Is that an issue or not, should we even worry about that, and should the fee be structured for convenience rather than to encourage efficient utilization.

So these topics are also in the paper. Microphones are open for comments. And we're going to remember we're going to have an online consultation for the next 60 days. So people want to talk about one of those proposals or one of the issues raised? Go ahead, front and center.

Matt Petach: Matt Petach. One quick question on this. You make it sound like there are seven proposals and the consultation will be which of the seven does the community prefer. Is there an option for mix and match and saying we like bullet point of one and -

John Curran: Yes, it's an open - this is just a discussion document so you can start by saying I'm looking at Number Three with this change or Number Four and this or half of Six and half of Two, whatever you want. We just wanted to have a framework because this covers probably 80 percent of what people want to do. Yes, center middle.

Adam Thompson: Adam Thompson, Manitoba Internet Exchange. Going back to something you said before you got into the proposals was the mention that there's increasingly, and we're not quite there yet, not that much difference between ISPs and end users. And I've already had this argument with other people earlier this week, and I will iterate on public record that my experience is with the smaller organization end of the scale and at the small end of the scale there is no difference anymore.

I would encourage, strongly encourage, ARIN to look at gradually homogenizing those two categories wherever possible to eliminate confusion and needless distinctions. If that proceeds, then Proposal 6 makes a lot more sense. And in fact Proposal Six will kind of happen by default if the distinction between ISP and end users is eliminated.

John Curran: Thank you. One little note. Services wise, it is true that ISPs have the ability to do subdelegations, and it's not clear that that's available to end users. We've had discussions on occasion. We've talked to people about that. We try not to highlight the distinction. And particularly, for example, you have a legacy holder who is paying end user fees but has existing subdelegations, you don't want to have to force them to be an ISP. It's not a universal black and white line. But, in general, 97 percent of ARIN services look the same regardless of the type of address block. Center middle.

Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC, speaking on behalf of myself as DeLong and DeLong Z. I wasn't thrilled when my fees went from $100 a year to $300 a year under the last go around. I'm certainly not finding any appeal whatsoever in Proposal Number Six where my fees would go to $1,400 a year. So I would argue that the distinction at the small end - because I'm about as small as you can get; I'm running an AS out of a house - is not a distinction without a difference. It's a very, very meaningful distinction, and I would argue against, say, the elimination.

John Curran: Understood. Center middle. Go ahead.

Brian Johnson: Brian Johnson with DRN. Relative to the Proposal Seven, transaction based, would that include transactions that are automated transactions as well as person to person transactions?

John Curran: So the reason this was discussed is because it was a question of fairness of recovery, and that's based on labor and labor categories. And so, no, I presume if we have to have a team doing a review and doing processing and working with you on the paperwork, this should correspond to the work involved. That was the impetus behind it. We'll actually have to do a fee schedule, but presumably automated transactions would have very little cost as long as they have very little people involved. Center front.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council, Time Warner Cable, RES Z. The Z means I'm an LRSA signatory. When I became an LRSA signatory, the modest amount of money that was charged on an annual basis was intended to be something that made sure there was a contractual relationship there and that the client service provider relationship with ARIN was exercised on a frequent basis. It was intended to be a token amount of money. I advocated heavily for a lot of folks to sign LRSAs on that basis. Certainly my ability to do that with a straight face is inversely proportional to the amount of money that's being charged. And were it to go to 300, okay, fine; like Owen, I'm not particularly pleased by this, but it is what it is. If it were to go to 14, my ability to advocate for that would be asymptotic to zero.

John Curran: Just to be clear, the people whom entered those agreements many have caps that specifically say they can only increase $25 per year.

Rob Seastrom: The cap is on the rate, not on the ultimate amount -

John Curran: Not on the ultimate number.

Rob Seastrom: - and shame on us for not insisting on that at the time when the LRSA was under discussion.

John Curran: Do you believe there should be an in perpetuity difference in fees for LRSA holders?

Rob Seastrom: That's a good question. It's worthy of discussion. I haven't thought that through particularly, but I haven't really been incented to until people started talking about orders of magnitude in difference what I might be paying as an LRSA.

John Curran: Understood. Center middle.

Milton Mueller: Milton Mueller, Syracuse University and ARIN Advisory Council. I'm curious about the legal change that you noted might be required, the fee for services versus the business league model. I wonder how complicated and how that might affect membership in the organization.

John Curran: To the extent that ARIN is a 503C6, we're focused on improving the environment of a particular business or industry. And we have to do that for the entire industry. To the extent that we collect fees from our community and we do that for the entire industry, it's very straightforward. If we collect fees from individual organizations and we attribute those to services to those individual organizations and that set of service revenue increases, and it's tied to our costs, there's a threshold where someone would say that's an activity that isn't a trade association activity; it's probably a more classic business activity. And so it's a judgment call. We actually have had our current structure and our current tax status reviewed even recently and found we're golden we're fine as is. But if we took a direction specifically with the fee schedule that was to try to attribute a cost service relationship and try to do it for a significant amount of ARIN's revenue, we'd probably have to revisit that. It's not a difficult thing, but it might mean a subsidiary to do just that and handling the relationships between the two, it just adds - there's an overhead complication, I guess, that people would need to think about. Obviously, if a fee schedule brings us in a direction that we need to worry about, we get appropriate counsel and figure out how to do it.

Milton Mueller: Follow up question to that. I'm curious as to the - how much do you know and how much can you tell us about the cost drivers of ARIN's services?

John Curran: Yes, actually we put all of that in the same document. If you go to Appendix C of the document, you'll find the current schedule. You'll find that about 50 percent of our costs today are attributable to registry services, related registry development registry services. About ten percent is organizational. It's the member's meeting and the elections and the Board of Trustees and the legal overhead. We have about eight percent for Internet governance. And then about 20 to 30 percent is ongoing registry operations. Literally keeping the lights and the power fed to the servers. That's opposed to registry development and policy meetings. That is in the schedule. You can go pull it down in the report. Center middle.

Mike Burns: Mike Burns, IPTrading and AC candidate. In APNIC, transfer fees are tied to the size of the transfer. In ARIN, it's a flat fee. And in the proposal, that combined a member fee with a transfer fee, it looked to be also a flat fee. I'd like to point out that a fee increase of this size is a counter incentive to small transfers and would more than double the size - I'm sorry, double the cost of the smallest transfers. So it's a real disincentive to that. And tied to that point, the idea of having members pay equally certainly has an egalitarian appeal and combined with the fact that the cost of a registry entry with a /9 at the end of it is the same to you as a /24. However, in this case, the /9 has a huge financial asset value absent from the /24.

And I think in that context it makes sense to have larger holders of resources pay larger fees. Thanks.

John Curran: Thank you. I'm going to close the mics.

Paul Andersen: A few points I just want to make. First I want to reiterate I guess what John said is that the purpose of this process was based on a bunch of feedback that occurred on one of the Mailing Lists that maybe once we had changed our fee model last time we didn't have the right one. From our standpoint the current fee model is recovering costs. We're not saying that the fee model has to change in the near future. So I point that out. This is more about a discussion about equitable. And I don't believe the committee is really recommending any specific one. This was just trying to enumerate some strawmen. Second point. On the whole end user versus ISP, one change that I think a lot of people forget that we did make in the last fee schedule was while end users generally pay a fee every time they make a request and then pay a maintenance fee, and that's generally stayed the same, although I know we now charge a bit more on the maintenance fees, the subscription fee model changed more significantly.

The last model that we had, ISPs were charged based on what their, for lack of a better term, peak request was per year. In other words, if you came for a 16 every year, you were in the category that charged a 16. We've switched that significantly now to just what is your total holdings. I think that's why we're seeing more discussion about why an end user versus ISP may look more and more similar, at least from a fee perspective.

By the way, just because they may become the same thing in a fee perspective doesn't mean that they won't stay separate in a policy perspective. And I would urge, Rob, for you to encourage any of those discussions that you can and how can we best - I don't think we're trying to - and others have said we don't want to discourage people from signing LRSAs. So if there's ways we could deal with that, we'd love to hear feedback.

John Curran: People will see the announcement of the consultation go out. We'll keep it open. It's a pretty sizable topic. We'll keep it open for 60 days. The folks who feel strongly that one of these is a good direction or that nothing is a good direction should get on ARIN Consult and participate. As I said, I'll summarize that for the ARIN Board Finance Committee.

Thank you very much.

(applause)

John Curran: Our final presentation is Vint Cerf, the chairman of the Board of Trustees.

ARIN Board of Trustees Report

Vint Cerf: I see I have ten minutes or less and I'll try to make it less so that you'll have some time for open microphone. Could I have the slides, please? I get to control this myself. That's cool. There we go. There are just a few things that the Board of Trustees does, and as you can see a fairly long list of them have to do with financial and fiduciary responsibilities. I refuse to read every single one of these, but I want to draw your attention to a few in particular.

First of all, we're quite conscious of the cost of travel, and so we're making sure that Board members who are traveling to other than meetings like this one or other face to face Board meetings clear that travel ahead of time. The second thing is that the audit was absolutely clean. I've been on many nonprofit boards in the past, and I can tell you that the way in which this audit was conducted and the way in which the staff responded produced a spotless report from the audit committee, and of course that made me and the rest of the Board members and I hope you very happy.

Another thing to point out is that we made some modifications to the bylaws, which I hope you noticed. And they were intended to protect your interests. So if you're not sure about what those were or what the intent was, just generally speaking it was intended to make sure that the bylaws could not be changed without your consultation under certain - for certain of the provisions in the bylaws. Let me go to the next slide here. The next thing is just to show you all the various things that got adopted. This has already been referred to. I want to emphasize the importance and value of the AC's work and the work of this community in helping guide the Board towards provisions that it can - or recommendations and policies that it can adopt.

So you can see that you've done a great deal of work and the Board has concurred with the value and quality of your recommendations. There are a bunch of other things that the Board does. And, in fact, this is my last slide. And I want to point out something. As I was preparing, going through these, I realized that there's a lot of stuff that Board members do that you might not know about. And so I'm now going to commit to providing you with more regular information, not just in these meetings but on the website about the activities of Board members who are serving your interests in many, many different venues.

In particular, if you look at the last bullet there, I even neglected to mention ARIN on the Road, but there are Board members who participate in that as well. I participated in the IGF. I've been very active along with the other Board members in many of the Internet governance activities, the committees that are producing various and sundry recommendations. This is a very - let me call it fluid time in the history of the Internet. Our role as ARIN, our participation in the ICANN space and the general interests of governance in let me say asserting more authority over what goes on in the Internet is an incredibly important topic and it's one which has potential hazards in it. And so I can tell you that the Board members, the AC members and others who are engaged are here to protect all of our interests in keeping the Internet open, useful and productive.

One last thing to mention, and that is an attempt to alert the general public to the importance of IPv6. By the good graces of the ARIN staff, I ended up on the Stephen Colbert show. And I have to tell you, that was a pretty remarkable experience. We did get a shot at what IPv6 was, which amazed me because I figured Stephen wouldn't let me say anything sensible. The only other thing I can tell you is it was not preplanned. We didn't have any discussions about what we were going to say or do. And when he popped that matrix architect question on me, I was not prepared for that, but he got what he deserved. I'll stop here. I thank you very much for your attention. I'm happy to answer any questions you might have, but let me thank all of you for all the support you give to ARIN and the work that you put into it. Thank you.

(applause)

John Curran: Any questions for Vint or the Board of Trustees? I'll ask for a round of applause for the Board of Trustees and all the volunteer efforts they make keeping the organization running.

(applause)

Members Meeting - Open Microphone

John Curran: Okay. We're at the end of our meeting. The thing between us and adjournment is Open Microphone. We have an open microphone session. We'll take any questions that people haven't had a chance to ask. Please approach the mics. Center middle.

Terry Hoke: Terry Hoke from Sierra Tel. This is my first time attending this meeting and I'd like to thank you for inviting me as an ARIN Fellow and Tina Morris for her excellent mentorship in the community for making me feel welcome. The topics have been broad in scope and it's been very enlightening, and I hope to continue to participate in the future. I'd also like to urge you to encourage people within your organizations to apply for the ARIN Fellowship if they can't otherwise attend this meeting. Thank you.

(applause)

John Curran: Center rear.

Rudiger Volk: Rudiger Volk, Deutsche Telekom. Well, I would like to refer to something that did come up in the NANOG technical presentations. Wes George from Time Warner Cable did a very nice presentation explaining what various problems are facing someone who wants to seriously use RPKI. There are - and I agree very much, there are quite a number of interesting problems that need to be attacked.

However, one of the major blocking stones in the way that he recognized and pointed out, in particular on Slide 21 of his presentation, was the legal framework that is put around RPKI by ARIN. And looking from the outside from where I'm coming, yes, ARIN looks less friendly for accessing the users', the members', ARIN resource holders' data than the other RIRs. Okay. Just take that report, I think for you in the region, it probably is much more important to note that serious companies, legal departments, come back and say: No way to sign those agreements. And as I gather at the same meeting, well, okay, there are federal networks that say, well, okay, no way to do this.

Let me try to give you a suggestion for taking another look and maybe coming up with a more appropriate framework that actually fits the design of RPKI better and maybe at the same time you also look at the question of, well, okay, how are you presenting the interface to the system, are you making it friendly to potential users or are you giving a service that looks like, well, okay, it is, well, okay, kind of threatening.

John Curran: I understand. Rudiger, let me respond if you will. I was at the same presentation. And I hear your suggestion. And I commit that I will bring to the ARIN Board the information from that presentation as well as some thoughts on a fresh look at what we're doing. I don't know what will come out of that because there's an important balancing that goes on, but I do commit to have the Board have a fresh look. Maybe ARIN will get sneakier in where we hide the information like some of the other RIRs.

Rudiger Volk: John, may I contribute a little bit of specific point of view that I think the current approach is kind of missing. The RPKI design assumes that the CAs actually put all the information, all the certificates on behalf of the users, the resource holders or ARIN's members into the public by the repository system, which is not really very much different from a Web PKI C8 telling their users, yes, your stuff will validate because we bribe the browser vendor to put the root certificate there. The RPA as you have it right now quite clearly declares your trust anchor as a protected secret which is very much the opposite of how the other PKIs work and quite obviously is a barrier to the public access of your users' data or your clients' data.

I'm not completely sure what can and should be done and should be done on the RPA side, but I think it is very important to put much more emphasis on the side of the relation between the CA and resource holders and understand that the resource holders, when they sign up with a CA, actually are expecting certain service. Parts of Wes's presentation I think we're asking for additional things aside from the RPA fix. In short, what is the major purpose of signing up as a client under an RPKI CA is I want to have a reliable service in publishing my certificates and making them due to the RPA architecture actually publicly and easily available. I have very much the feeling that working on that contractual relation and figuring out what it means and what implications it has has been probably missed and overrun by the considerations to protect ARIN as an organization which, of course, is an important concern and is very well appreciated.

John Curran: Okay.

Rudiger Volk: Got it?

John Curran: Yes. Do you want to respond, Bill?

Bill Woodcock: We have a fast moving train wreck here, and it sounds like what you're proposing is we could make things better by taking the liability disclaimers off the ticket so that more people will get on the train. I'm not sure how this makes things better.

Rudiger Volk: Well, of course, of course, of course we can decide that improving routing security doesn't really matter. And I have to say having worked on and looking at routing security for quite a while I do not see any serious contender in town. And looking at the slow pace of development of such things, I do not see - I do not see anything that really would be a reasonable alternate choice at this time and for the next three years.

John Curran: Rudiger, as I indicated, I will bring Wes's presentation to the ARIN Board along with some thoughts. ARIN's not trying to protect its trust anchor locator as a trade secret. That's a artifact of trying to make sure that the people who are using things in the CA actually have seen the relying party agreement. Other RIRs put a statement in their CA that say: If you use the CA, you're bound to indemnify us.

That's an informal binding, and ARIN went with a more formal one. But I will bring the - I will bring it before the Board along with some additional legal work. We'll try to make those materials that the Board's used to be briefed available to you folks so you can see it. I want to recognize just to highlight it's not a question. Nearly three of the four - four of the five RIRs have indemnification statements. We just wanted to make sure you actually saw it before you started using RPKI. Okay. Center front.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN Advisory Council. I'm going to make two comments here, one of which is vetted with and speaking on behalf of my VP who is out of the room on a conference call right now, and the sentiment here is have your people talk to our people. A consultation group that got together, the attorneys from ARIN and attorneys from the large companies that are saying no, no, no, no, other RIRs, they're saying no, no, no, no, and other interested parties to hammer out an agreement that we can all live with to a certain degree would be a step forward. Now, that's at the end of that statement.

John Curran: I will bring it as an option to the Board. I do not know where that will go.

Rob Seastrom: Thank you. We would like you to bring that as an option to the Board. That's all I can ask. My response to Bill is it may be in fact a train wreck, but given that my group is sort of the Consumer Reports and National Safety Council, car testing people for our company, there is no point in us making that evaluation for the organization if legal is just going to say you can't run it anyway. So we are not allowed to spend time on going too far down that road to figure that out for ourselves if legal says no.

John Curran: Thank you. Center middle mic.

Owen DeLong: Owen DeLong, speaking primarily on behalf of myself. I've been approached by members and in email messages. There's a perception problem brewing, and I don't know whether it's merely a perceptual problem or an actual problem. But the perception is that v4 allocations and assignments are getting harder and harder and harder and more stringently reviewed and v4 transfers are being permitted on a less stringent basis. I believe that the community was clear in linking the policies in Section 8 to Section 4 and that they wanted the same level of review and stringency applied to transfer requests as to free pool requests.

If this is merely a perception problem, then I had like to suggest that ARIN needs to do something to address the perception. Because for any given individual outside the organization, perception is indistinguishable from reality.

John Curran: Okay. Owen, it's a real problem. Real problem. When the team review went in place, the way it was being done and what was being handled was not as efficient as it could be. As Leslie said, we took some corrective actions by moving certain queues off to the side, by changing the way the team review is structured so that that's now bound to from five days for our turnaround on a response -

Owen DeLong: I'm not talking about turnaround times.

John Curran: When you talk about delays, that's where it would occur.

Owen DeLong: I didn't talk about delays. I talked about rigor and stringency of when I submit a request how much additional documentation am I asked for, how much proof do I have to provide, et cetera, et cetera.

John Curran: That's a perception issue, I promise you.

Owen DeLong: The perception issue needs to be addressed somehow.

John Curran: On the problem you didn't ask about, we're down to three and we're working to get it back within two. Center rear mic.

Sandra Murphy: Sandra Murphy, Parsons. I want to repeat myself from the comment that I made after Wes George's presentation at NANOG. I'm not a legal person. I don't speak legal speak. The difficulty I have in the RPA is the prohibition against sharing the information which presents certain - which prevents certain architectures that we had thought would be valuable in the distribution of RPKI information. You can't get it from your neighbor. You can't get it from your IXP. You can't get it from your service provider. You must get it from ARIN. And I think that presents some networking and architecture difficulties. I think it puts ARIN in a position of having to make sure that their service is even more reliable. There will be a single point of contact.

John Curran: Sandra, there's absolutely no intent of precluding any architecture that someone wants to use. We did have this problem at one point with reporting, for example. People want to do monitoring and availability reporting and statistical issues, and we actually have worked that way. We actually have an agreement that specifically allows that. If you have a technical architecture for people who want to do route integrity and republication and that's part of an architecture being considered and people are going to need to get past that trust anchor issue, then we should definitely talk, because we're not trying to inhibit any architecture that the SIDR group wants to come up with. Note - note, the party that's in there doing that publication service may not like the fact that they can republish but they still have to agree to something, but we can figure out an agreement that gives them that right.

Sandra: I see. Thank you.

John Curran: Center middle.

Adam Thompson: Adam Thompson again. Concerning RPKI, the obstacles that others have covered don't prevent me from participating. I just did sign my ROAs, but I am baffled. If I open a TCP connection and my packet doesn't make it all the way to the end host, I don't sue ARIN. If I look up the Whois entry and the data is wrong, I don't sue ARIN. Why is the RPKI data so different at such a fundamental level?

John Curran: Recognize that you don't sue ARIN in those circumstances. But if the bank you're serving ends up suffering because your use of RPKI - I'm not even worried about our service at all. I'm quite fine with that. I'm worried about your use of RPKI causes someone else to suffer, then they may turn around and sue everyone involved in the activity. And so it is not per se the party that is directly our customer. That's generally not a concern. It's the other party that might be the relying party on what you publish that we are ultimately worried about. Bill's small ISP with a bank that somehow gets impacted because he didn't understand how to correctly handle the fact that, well, maybe he couldn't refresh and validate a certificate. And so it is - to be clear, we're setting up a system here. And what we're trying to say is as people make use of this system, we want it to be clear that people are taking the right precautions. You want us to. We want everyone using this system to also take precautions, to realize that there are some failure modes that could result in people having to understand that they're not going to get the validation that they want inherent in the system right now. There were actually the five preceding pages in Wes's presentation about some of the failure modes. It is really about third parties who are impacted because we're all making use of RPKI.

Adam Thompson: May I continue for one moment? But this problem already exists in many other domains that aren't covered.

John Curran: Good. Then just click yes.

Adam Thompson: DNS -

John Curran: That's true.

Adam Thompson: - With routing. Like I can sync - well, I can attempt to sync 100 percent of VeriSign's traffic in about ten minutes from now. And we have mechanisms that handle that. People start ignoring my AS advertisements.

Bill Woodcock: The fundamental difference between the examples you cite and RPKI is that the purpose of RPKI is to carry a cryptographic assertion, a signature, that ARIN stands behind the veracity of the statement. So that is a legal hook into ARIN's legal defense fund and reserves. That's all it is. There's no other purpose of RPKI, other than to give you a legal hook into someone with deep pockets if they make a misrepresentation.

John Curran: Let me say something, as I pointed out to Wes, in his own presentation, when you contract for service, it is not uncommon to find indemnification clause. His own services offered by TWC have the same third-party indemnification clause. As we grow and professionalize the Internet, it may be that we don't have agreements. But as we add them, you're going to see these happen for services. This is a new service so we're actually putting the agreements in place that we probably should have for others. I think it's a problem, but I think our reach is exceeding our grasp with RPKI at this time legally.

Heather Schiller: You don't ask to indemnify - the user doesn't have to indemnify VeriSign for providing a certificate for Bank of America. That's more like the situation you're getting into where you're saying like some ISP's downstream customer needs to sign your agreement in order to use this system. And you don't have that in other - you don't have that in other areas.

John Curran: As I said, other RIRs have taken other approaches -

Heather Schiller: Not RIRs. I mean in other - so like -

John Curran: I understand not RIRs. I'm saying other RIRs have taken other approaches of doing that same requirement that we've done for RPKI and getting that same agreement with that customer by simply embedding it in their CA and saying use of the CA binds you in that manner. It's the same agreement, it's just they didn't click to acknowledge.

Heather Schiller: I actually came up here for other stuff.

John Curran: Okay. So hold - RPKI, Rudiger?

Rudiger Volk: Yeah, just short comment for Bill. I hear you saying the only thing to do routing security is to create situations to litigate. I'm really of a very different opinion.

John Curran: I'm not saying that at all, Rudiger. I'm saying if we offer services -

Rudiger Volk: Bill. Bill was.

Bill Woodcock: You're failing to distinguish between security and RPKI. RPKI is a method of attaching digital signatures.

Rudiger Volk: And it is the way for getting reliable information for doing your routing decisions, which is the part where the security comes in.

John Curran: Okay. So people on RPKI. I got Geoff at the back mic. Anyone else? So in order, at the back mic, go ahead, Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. It sounds like this is a great time to do a very open public discussion on RPKI. This has been an issue from a financial point of view and draining resources from ARIN. This has been an issue in implementation. This has been an issue, issue, issue. And it sounds like let's get the cat out of the bag and have a real discussion on this. It sounds like from my perspective the community needs it at some point and is saying there are roadblocks. I don't know what they are. We're not going to have enough time at the mic to do it. So let's actually have something substantive.

John Curran: Let me respond to that because I actually have to take exception. This actually is the time, unfortunately, or on the list, yes, but ultimately this is a risk trade off and it is not the community's call. It's the Board's call. Now, I'll make sure that the community gets some materials to see how that trade off is made, but even some of that ultimately is a fiduciary duty. So I recommend you find a trustee and grab them and start having that conversation, because that's who I have to have it with.

Kevin Blumberg: So, John, just to say one thing, none of us in the room are lawyers. Some of us are smart enough to know we're not lawyers. Maybe even having - what's the word? An overview that explains why we're doing it the way we're doing it would be appropriate.

John Curran: That's what I was committing to, is saying we've got to take a fresh look, try to get the briefing materials in front of the community as much as we can in front of the Board.

Kevin Blumberg: Thank you.

Geoff Huston: Geoff Huston, APNIC. I've had a long experience inside this, and I would actually like to say firstly that there is a distinction between the resource public key infrastructure and its use in routing. What we originally thought about - it was about 15 years ago - inside APNIC was we wished to take Whois a bunch of ASCII and try and put something around it that said if they're my resources, I have something, a private key, that can help me make attestations about those resources that just doesn't rely on some text in a database that really doesn't nail it down. And this seemed like a good thing.

I think it still is a good thing. In and of any other application, it's a good thing because it makes the registry work better. And in that registry context, the issues around general use are very different. Because typically you don't look at all the registry all of the time. You look at that entry once. And so the consequences of any form of failure are limited to that inquiry once. And then some bright people, who at the time were having the same thought in other rooms, thought, you know, we need to secure routing. Then RPKI comes along it goes, you know, it could be really, really useful.

The problem with routing is that all the routes are with you all of the time. It's no longer I want to open this door. Every single door needs to be opened at once. The consequences of failure in that interlocking key infrastructure in routing can verge on catastrophic because it's everybody all at once. And so operators very high in that trust hierarchy are vulnerable. And all of us at the RIR level have looked at this going this is uncomfortable because the consequences of failure - and I don't think it's a UPS thing, but yet the failure does happen - could be catastrophic on routing, and that makes us all feel extremely worried.

So, yes, there are disclaimers, yes, there are things going, you know, this is really, really hard. At the same time it's certainly from APNIC - and I know from the other RIRs - we're trying to go back to the standards folks saying can we make this a little bit less fragile? Can we alleviate some of these concerns? So when you say I'm uncomfortable, when Wes George says, look, we're not going to do it now, it would be nice to say it's ARIN's fault because that seems the meme du joure, but it's not. It's not ARIN's fault. And it's not the way you've actually done explicit permissions in using your TA material. That's not the root cause of the problem.

This is a hard problem. And after 20 years of studying it, it's still a hard problem and we don't have easy answers. What we've done so far is a prototype as far as I can feel. There's more work to happen in developing the technology. It's not finished. Give us a bit of breathing space, please, and allow us to look at this and see how we can make it really work. Because like it or not, we're going to be stuck with BGP for a long time. If it's the state of the current security, we're all toast. We need to make it a bit better, but it needs a bit of cooperation, not head bashing.

John Curran: Thank you, Geoff. Center front.

Heather Schiller: I'll resist the urge to keep going on about RPKI. So at one point you said like grab your friendly Board member, and the question that I had is about Board transparency and a couple of different parts of that and also the ACSP. So there are several items in the ACSP that have been open for a long time, some of which have been open since 2008. I get up and say this every meeting. So not all of them are - many of them are IT-related things that I know you're working on. Not all of them are. Some of them include things like term limits, candidate speeches and geographic diversity of candidates running for the AC and the Board.

The comments on all of those - and they're in various states of open and closed, but comments on all of those were that they were being referred to the governance committee on the Board of Trustees, and so I would like to encourage either now or at a future meeting feedback from the governance committee about those items.

Paul Andersen: So there was three items there I think you said - term limits, changes to candidate speeches, and Board diversity and geographic diversity?

Heather Schiller: Diversity of candidates - of - not - actually, not of candidates, because I know that there's been some work on that in Nom Com, but actually geographic diversity of seats.

Paul Andersen: Looking more at the actual selection process of how do you seat the bodies - no, whether you elect them, nominate them, appoint them -

Heather Schiller: No. So my - I put a suggestion into the ACSP that would require there to be - that would mandate that there be geographic diversity of candidates on both - not candidates, of seats on the Board and the AC. You must have one from each region.

Paul Andersen: Composition, then.

Heather Schiller: Yeah. So that was kind of a great - that was like immediately closed and said that it was referred to the governance committee. Some other items, like term limits and candidate speeches, are still open, all under the umbrella of governance.

Paul Andersen: Let me deal with specifics; John might have more general. In terms of composition, there was I believe an error, and that wasn't actually properly referred. So our apologies. But, strangely, it was already - is something that is kind of on our radar, and we have been kind of looking at both the AC and the Board on what the composition should look like for those and with an eye to how can we make sure that we ensure that there's geographic diversity - or that at least all three of our serving regions - because we identify Canada as one region, US, and then the Caribbean - are served.

I don't have an answer for you there, but I did get some good feedback from yourself earlier and some other members of the community. So we're trying to do that, but if you have ideas on how that might look, I am happy to hear them and pass them to the committee.

Bill Woodcock: One of the things we've been trying to do on the Fellowship Program is to make sure that there are people from all three regions getting to the meetings who wouldn't otherwise be able to as a stepping stone towards having there be more electable candidates to the AC and Board.

Heather Schiller: The Fellowship Program is great. I've helped with that before. It's great.

Paul Andersen: One of the easiest ways we hope that we can get people on there through - the current mechanisms is get them here so people can get to know them. Hopefully that one is easy. In terms of candidate speeches, we did look at that and have decided - there were some suggestions, should we look at - should they be pre-taped, should they be live and what restrictions should we put on that.

And the view that we've generally come to on that specific one was that we do ask candidates to try and keep any speech focused on that. But the feedback we heard from many was the electorate would like to decide - if somebody decides to get up and start talking about bananas for three minutes, then let the electorate decide how they want to deal with that. We are, though, however, as recently as just this morning discussing ways, though, that we can better get information to the membership, not only the people who are in this room, but also the wider community. I don't have anything further on that for you because it's still in very early stages.

On the third one, the term limit, that seems to - I know that has cropped up many times. There was a fairly vivid discussion on arin-discuss - I believe arin-discuss - was it - actually, I think it was cross-posted, to be honest, is why I'm getting a bit confused. I think our view is there does not seem to be consensus, and I do not believe we'll be - there's no plans to make any changes in that regard in the near future. But it is an area that has been revisited.

Heather Schiller: Concisely my feedback is the governance committee should report back to the community once a year or so on some of these things when they're outstanding and let folks know what's going on. That would be nice.

Paul Andersen: It is a committee of the Board, so it generally reports to the Board and the Board should be reporting back. But I hear you. And I agree -

Heather Schiller: Someone tell people out there.

Paul Andersen: I agree. There was a small mechanic issue, and I agree. Especially when ACSP items are getting in there. We need to find a better way to get that back to you.

John Curran: I take the fall for two of those lack of report back, because the Board was concurrently discussing them while you submitted them, and I wanted the Board discussion to finish. In some cases it only just finished. There was a third item, though, that you raised. Board transparency? So current state is meetings are announced in advance. Agendas to those meetings are posted in advance. We've begun to post attachments for those meetings, the attachments that we can. Sometimes we can't because they're privileged or confidential.

The Board has been increasingly putting emphasis on making sure that you know they're meeting and what they're talking about and what the materials are. And we've seen a lot of progress there. I hope to see more of that in the coming year.

Heather Schiller: That's all lovely. Thank you for that. However, when you read the Board minutes, I understand not just the ARIN Board but many Board minutes are - kind of sum up what happened.

John Curran: Like AC minutes.

Heather Schiller: AC minutes actually are very detailed and they say like Heather Schiller suggested this. You can read the AC minutes and get a fair idea of what particular AC member's response was to a given policy. It is extremely difficult to read through the Board minutes and get any sense of what specific - where specific Board members stand. Not everybody has the luxury of being able to grab individual Board members and get information from them.

And so when it comes time for elections, it's really hard to see like what folks are doing and where people stand and like exactly what's going on. So anything that could be done to increase transparency around that. And I would encourage anyone in the room who to speak to that as well.

Paul Andersen: Yes, please.

Bill Woodcock: So I certainly feel the same thing you do very keenly. I feel the same thing that you do very keenly that there is not the forum by which the Board, members of the Board, have a way of communicating to the community what it is they're up to. Once every three years we get three minutes to say what it is that we think we've been up to. That doesn't feel to me like the best way to communicate what our positions are. And on the one hand - so there's a little bit of a conflict between giving sitting board members more opportunity to tell the community what they're up to and the desire to have the term limits and saying that sitting board members are already at a structural advantage in elections and so forth.

As a sitting Board member, I'd very much like to have the podium some of the time to talk to you guys about the issues that I think are important and why. But at the same time that's more of your time that I'd be chewing up with things I think are important and don't know whether you guys think are important at the potential expense of the outreach of other candidates who might be trying for the seat that I'm sitting in.

Heather Schiller: I also want to be very clear. I'm not even actually talking about policy issues. It's really all the other stuff like what is an individual Board member's view about ARIN's financial plan or how many -

Bill Woodcock: We don't do policy.

Heather Schiller: I know. So that's the thing. You can see policy passed with a roll call vote and you have some sense of what happened there. But for everything else it's like a black box and you don't know what's going on.

John Curran: Got it. On the topic of Board transparency, diversity, candidate speeches, Board minutes, is that what you're on, Kevin?

Kevin Blumberg: No.

John Curran: Are you speaking on that topic, R.S.?

Rob Seastrom: I am speaking on that.

John Curran: Please do. I am closing the mics for other topics. So after Kevin, if you have any other topic, get to the mic now.

Rob Seastrom: Rob Seastrom again. I've had private conversations about the way that putting stuff into the ACSP box sort of feels like it kind of disappears. I'm going to avoid using inflammatory language here and just say there seems to be no SLA, and with no SLA, there's no SL. And we would - we would - yeah, there's no S.

(laughter)

Rob Seastrom: And I would appreciate a commitment from the Board to promptly dispose of, communicate back on whatever goes into the ACSP box in a quick manner. It's the only way we have to communicate our desires on things that are not directly affectable by changes to the NRPM.

John Curran: I want to do one quick thing. Some of that again is back to me, because the ACSP was originally envisioned for suggestions about how ARIN operates. It actually goes to me. And we actually - about - about 60 percent of the ASCs have been closed, particularly in the operational can you change this field, can you do this, can you add this feature. We still have development backlog, because we're catching up on a lot of work, but we're making progress on them. The ones that go to the Board I guess I bring to the Board on agendas where there's time to put them and maybe either we need a different process or I need to be a higher rigor so you can know your matter's gone before the Board. And that's something I've got to talk to the Board about.

Rob Seastrom: If I can reply to that briefly. I don't expect instant gratification. I don't expect everything that goes into the ACSP to be prioritized at the higher level. I understand the operational constraints you have. I do, however, like to hear back that like someone heard it and it's being taken under advisement, by the way, we probably won't get to it this quarter, we're sorry.

John Curran: Got it.

Paul Andersen: The only thing I wanted to add was to tweak one of your comments, because you said this is the only way we can let you know. I would agree it's the formal mechanism, I guess, and as John said, there's probably some improvements, but I would encourage that - our email addresses are on the website, we're in meetings. If there's informal thoughts that you have, myself and I know almost all the other trustees and John himself are always happy to hear those concerns if you want to do that. Feel free -

Rob Seastrom: I think - I don't want to be sarcastic here, but I never do that. I never talk to Board members or staff like that.

Paul Andersen: I know you don't, but you make it sound like it's the only way.

Rob Seastrom: I understand that. But you're correct, it is the only formal way, but it's the way that's well publicized and doesn't require one on one working relationships for people to come and say, hey, I need this, I need that.

Bill Woodcock: Formality is a really good thing in a lot of ways. It gives transparency, it gives public feedback. Everyone can see what the question was, what the answer was and so forth. I was going to make a suggestion. Maybe I should use -

Rob Seastrom: That might be the wrong word.

Bill Woodcock: A possibility would be that suggestions that go in be explicitly directed to either the staff or the Board. If they're directed to the staff, then John deals with them however he sees fit. If they're directed to the Board, then it's not unreasonable, assuming that we don't get ten of these a week, to expect a written response from every Board member. Right? That would be part of the public record. That would let you know where we stand and it wouldn't be us grandstanding.

Rob Seastrom: I think that's a great idea and it should be made explicit on the ACSP Web page if everybody in your team concurs.

John Curran: Nate, I'm going to close it. It's closed.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. At the last ARIN meeting you discussed changes to the RSA, LRSA. Can we get an update on that, because it does affect policy, I think.

John Curran: All right. So I actually held it - given everything we had in this meeting and what the Board had already been working on, I held engagement with the Board on that topic. I'm going to resume it immediately after this meeting. I have a draft, and now it's a question of engaging with the legal and the Board to move that ahead. But, literally, we didn't have enough cycles because of everything else going on. I could not get that and get that in front of you in a reasonable manner before this meeting. It just - we were too busy with other work. But it is top of the queue now.

Kevin Blumberg: I appreciate the feedback.

John Curran: Queues are closed. Open Mic session is completed. I'd like to thank everyone for coming. And this concludes our ARIN Member Meeting. Thank you.

(applause)

Members Meeting - Closing Announcements & Adjournment

John Curran: So all AC members gather, 15 minutes, and then we - AC members, 15 minutes, and then you gather in the Conway Room. Please vote. The elections are open. This is how you choose AC and Board members. Thank you to our sponsors one more time.

(applause)

John Curran: Don't forget your meeting survey.