ARIN 32 Members Meeting Transcript - Friday, 11 October 2013
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
- Opening and Announcements
- IPv6 IAB/IETF Activities Report
- ARIN Consultation and Suggestion Process Report
- ARIN Updates: Human Resources and Administration
- ARIN Updates: Government Affairs and Public Policy Support
- ARIN Updates: Financial Services
- ARIN Updates: Registration Services
- ARIN Updates: Engineering
- ARIN Updates: Communications and Member Services
- ARIN Board of Trustees Report
- ARIN Advisory Council Report
- ARIN Financial Report
- ARIN Fee Structure Review Report
- Open Microphone
- Closing Announcements and Adjournment
OPENING AND ANNOUNCEMENTS
John Curran: Welcome to the final day of our ARIN 32 meeting in Phoenix, Arizona. We have a couple of brief announcements, and then we're going to speed on ahead to catch up with the program because we're a little behind from yesterday. First, I'd like to thank our sponsors. Connectivity is provided by PhoenixNAP and Gila River Telecommunications. Big round of applause.
John Curran: I'd like to have someone from PhoenixNAP come up because as a sponsor they've done a great job, and so come say a few words.
Ian McClarty: Hi, I'm Ian McClarty. I'm president of PhoenixNAP. Just quick show of hands: How many of you are not from Phoenix? Round of applause for everybody not from Phoenix because you brought some wonderful weather here. A few weeks ago it was 111. Going to 80 degrees, we're grateful for that.
We're grateful for the fact we were given the opportunity to host and sponsor the connectivity for ARIN and also NANOG. It was a great thing for our company because we were forced to do IPv6 implementation finally. It's been on the back burner for the last three years. So, again, another round of applause for that. Thank you.
We as PhoenixNAP, we're a full‑service datacenter, network operator. We host co‑locate quite a bit of clients. 50 percent of revenue comes from just pure space and power play. And there's a lot of connectivity that comes with that. The other side of the house is very much managed infrastructure as a service. And that is very resource intensive when it comes to IP addresses, so we feel a lot of pain. Right now we're doing expansion into Netherlands this year. We're finishing that up, and it's been a painful process with going through RIPE. But it's not bad. It is what it is. It's a finite resource.
We're also going through ‑‑ starting to work with LACNIC ‑‑ sorry, with ‑‑ in Asia‑Pac also with APNIC. And that's also again ‑‑ just starting to do that. It's a big difference from dealing with ARIN to RIPE to APNIC and pretty soon LACNIC. It's definitely a different beast when you try to do global expansions, but, again, we're looking forward to actually IPv6 becoming more of a standard. It's going to make our life a lot easier and everybody's life easier. I think everybody's feeling the pain now. And I want to thank everybody in the committee and ARIN for giving us this great opportunity. Thank you.
John Curran: Thank you very much. Thank you, Ian. Wonderful job. I also want to thank our webcast sponsor, Google.
John Curran: Okay. Vote. If you have not voted, please vote. Vote once per organization, obviously. A few of you actually were pointed out ‑‑ we did have a case where you might have gotten two notices. We've corrected that. There's been no double voting. Everything is good. So but please vote once per organization. Thank you. Okay. Don't forget the meeting survey. If you go online, it's at arin‑32/survey.html. If you want a paper copy, get a paper copy. Raise your hand. If you want to kill a tree, raise your hand. No pressure. Either way, if you enter, you'll be entered to win a Samsung Galaxy Note.
Remember during the discussion the Chair will moderate the discussion of Draft Policy so that all can speak and all can be heard. State your name and affiliation each time you're at the mic. Comply with the courtesies and rules in the program. Today's agenda, very full agenda: The IETF/IAB IPv6 Activities Report, the ARIN Consultation and Suggestion Program Report. We have the ARIN departmental reports, the AC Report, the ARIN Financial Report, the ARIN Fee Structure Review Panel Report, the Board of Trustees Report, and an Open Microphone.
So I'm going to start right in at the head table: Myself; our Chairman, Vint Cerf; our Vice Chair and Treasurer, Paul Andersen; our Secretary, Paul Vixie; Timothy Denton of the Board; Aaron Hughes of the Board; and John Sweeting, our ARIN Advisory Council Chair. So first up will be Cathy Aronson giving the IETF Activities Update.
IPV6 IAB/IETF ACTIVITIES REPORT
Cathy Aronson: This is what I was expecting to see yesterday. Apparently I couldn't quite get my act together. This is a close‑up of a little section of the ‑‑ I keep calling it the Great Wall but it's the Berlin Wall. IETF was in Berlin. If you haven't gone there, it's pretty fabulous. Yeah, so without further ado. It didn't make a slide. Okay. This is different than usual. Anyway, so this is my little disclaimer. You can read it or not.
So some highlights of IETF. I think it's pretty exciting, and I'll go through some more of these as I go along, but there's a lot of stuff going on with IPv6 and people are starting to actually notice that maybe it might happen, which is pretty exciting. There's a lot of really interesting things like we talked about before maybe with huge address spaces, what might happen. So we'll talk about some of those. And I don't remember what group this was in, but this is my favorite thing, the term "digital exhaust," which is what you leave behind on the Internet, all that stuff you post on Facebook, and so I think about that a lot. My digital exhaust. Okay. Anyway.
So I have two little rants. Luckily I have more time today. It occurred to me that you don't see all of this stuff because you're not on the IETF attendee list. It appears that the IETF folks that write the standards that we use on the Internet don't necessarily know how to Google. So these are some of the most common questions on the attendee list, which I find to be very, very funny, and it happens every time. So if you see any of them you could maybe teach them how to Google or Bing or whatever.
So my next rant. There's a group of us, there's also NET girls, and if you're interested in either of one of these groups, feel free to contact me. There's a woman who started getting the Systers together again and we have a Mailing List, and it's all the women at IETF. And anyone can join, but I found men don't want to be on a list with a bunch of women. But it always degenerates into a discussion of groups for martians and little green men.
What I would say is if your organization sends someone to IETF, try to get people nominated and women nominated for the different committees because we're sorely underrepresented proportionally in the IETF. Even though there are a lot of women participants, there aren't a lot of women on the IAB or the ISG, or the "ISTAR" as they call it. Anyway, that's my little rant.
So the Internet Engineering Planning Group is a group that's been meeting at the IETF for a while. It's a bunch of operators we meet on Sunday. It's a little extra bonus meeting. And some of the presentations that happen there, ULAs are like RFC 1918 addresses for IPv6, and George Michaelson gave a great presentation about the pathologies that are happening with ULAs and how many people are doing reverse lookups for them.
And so I guess the takeaway from this is maybe we should start filtering this stuff. I think they wrote a paper, too. Geoff can probably tell me, but it's an interesting presentation. We don't have a lot of time to go into all of it. So some more stuff about the DNSSEC, and of course "If you bugger up your signature, you're stuffed", which was the quote of that meeting. But I think that was Geoff. It sounds like him. So there's a lot of DNSSEC going on. It can really slow things down. So hopefully that will get better.
Let's see. What else? I don't know why these are animated. I'm really sorry about that. Wes George, so gave a presentation about he's testing IPv6 only. And my question that I was going to ask yesterday of the woman who presented from LACNIC, when you're certifying these applications for IPv6, we also have to look at things like software update and the stuff that happens in the background, because all of that still works over IPv4, which I thought was really interesting. So like if you're IPv6 only, you can run the software but you might not be able to update it.
And the other thing that I thought was interesting that he said was that their view right now is that IPv4 is for customers and they're trying to move everything else to v6 so that they can have a better customer experience in the transition. So there's a link to the document. Let's see what was next. Homenet. It's really cool when somebody takes a poor college intern and gives them a really exciting project of making Homenets glued together with Google whatever, Google Circles. So you can click on your neighbor's Google Circle and use their printer. Whatever.
The poor kid. Everyone was like, wow, that's a really bad idea. And he looked kind of pathetic and sad. But he had a great animation of like people's faces and their Google Circles and being able to click on them and connect to their Homenet. Super cool. Oh, "Having Google+ reconfigure my network layer just feels wrong"' was the quote of that. And social network networking. Anyway, I don't know why these are animated. It scares me.
Let's see. It seems like there's still a group of people on the Internet that really want the network to look like circuits. And this BoF I went to because there wasn't any v6 thing going on. It's sort of like taking MPLS and making it ‑‑ putting the state into the packets instead of into the network. I don't know. It was an interesting thought experiment.
Okay. There's a paper that a woman on the IAB wrote with some other folks about semantics of IPv6 addresses and the privacy concerns of generating different kinds of addresses. It's pretty interesting paper. I can't go into all the detail, but it's a good read. And some of the other drafts that were going on for security in v6, maintenance.
Let's see. I think I'm just going to skip that one. There was a plenary about the Opus Codec. We won't go into, but it's a program that makes video happen. And this is pretty entertaining. I think it happens a lot at the IETF. You can look at it at some point, but it's pretty funny.
Let's see, oh, the Internet Society does a lunch at every IETF, and this one was shocking to me, but if you haven't read this paper, "Confused, Timid and Unstable," that was put out by Stanford, it really explains why your video streaming doesn't work. It's like this death spiral that happens. It's pretty interesting. So this whole panel was about that pathology that's been happening, and it's not necessarily just v6 but it's got to do with bufferbloat and all kinds of pathologies that are happening and how the video speeds up and slows down and how it doesn't quite work with TCP. It's a really good paper.
Twenty-two presentations in Softwire, so we won't be really talking about those. But if you're into tunneling everything over everything and everything else, that's Softwire. There was more talk about ULAs, and that's the RFC 1918 of IPv6 in v6 operations. And the interesting thing about this is ten percent of the ULAs are in this globally unique space that doesn't exist. Like there's no registration mechanism for that space, so people are just kind of guessing.
The v6 deployment guideline is coming along. It's a good read. If you're demoing v6, you might want to look at it. It's hard to do 50 slides in 15 minutes. Let's see. There's guidelines for datacenters. We've talked about that before. VPE security is coming along. And there's this whole happy eyeballs thing, you know, like comparing v4 and v6 and trying to make the user experience consistent, and apparently it's not. So when v6 wins, it's a lot slower, so that needs to be ‑‑ still some work on that.
Teredo is a v6 transition mechanism where if you're on a v6‑only network you can still get connectivity. And they turned it off and there's a paper that they wrote about when they turned it off and turned it back on, and it looks like they're probably going to be phasing it out. It's funny because they turned it off, and after like a day and a half no one noticed. That's a pretty good sign, actually.
There's a presentation about embedding different semantics into v6 addresses, and this is something that this community should really start paying attention to, because it really ‑‑ if this stuff starts moving along, which I'm not really sure it does, it may change how RIRs do business and how addresses get assigned. And there's going to be a draft by Fred and Ole about this semantics. So I'll keep following that. We can skip that. If you have any questions about the HIPnet stuff, you can ask Chris Grundemann. That's his deal.
There's a lot of work being done in low power, low, like, machine floor kinds of stuff in v6 and low power devices and things that you don't really want them to be chatty, you want them to just wake up and do what they need to do and go back to sleep and not use ‑‑ they have a little bit of RAM and a little bit of battery and maybe the battery needs to last for ten years. So there's a whole lot of work being done to try to make v6 work in an environment that isn't chatty.
This is a sunset in Big Bend I randomly threw in, because I was there and I have to rub it in. And now we'll talk about sunsetting. You're awake, you're laughing. It's good.
It's a beautiful place. So in sunsetting, the sunsetting group is basically all the stuff you need to do to v4 to keep it kind of in the transition, keep it going, but nothing new.
So there's this ARP‑for‑everything problem, which is another new pathology where you have a v6 network that's routable but you're coming up and trying to do v4 and you end up ARPing for the entire world instead of realizing that you have v6 and doing v6.
So there's a bunch of different proposals for how to turn that off, like have your DHCP say no, no, it's v6 only. And so there's a bunch of arguments yet right now about the best way to make this stop happening.
Let's see. One of the other ones is to just get rid of the A record. So the WIDE guys in Japan have been doing a lot of work with v6‑only networks and v4 hosts connecting to them. They've written a few papers and done some work on that.
There's some other drafts that are going on in the sunsetting working group you can follow if you're interested. They're looking at the same kind of things for MPLS, what happens if it's MPLS over v6, just like what happens if you're updating your Mac OS software and you only have v6 can you do it. So they're looking at that with MPLS.
And then that quote was pretty funny, big fog. The DHC group and the DHCP group have been meeting and kind of working out how things ‑‑ I mean the sunset group, how things overlap. There are a lot of drafts in that group, so if you do DHCP or you're interested, you should follow those.
There's some interesting work being done with DNS security. And they did most of the initial work in the lab but now they're going to start doing it in the wild. But it's really kind of scary how vulnerable the DNS is. So hopefully we'll have DNSSEC pretty soon. Like they said, 15 years and we have less than six percent that's encrypted.
Yeah. Let's see. There's some more stuff about poisoning the DNS cache and the security implications of that. These guys were pretty interesting. If you haven't followed the TOR project, it's like this loose association of ‑‑ it's anonymity on the Internet. And right after the IETF, they kind of got shut down and then they brought it all back up. But it's all the foreign countries with the uprisings are all using the TOR little network to get to Google and YouTube. It's pretty fascinating. You can set up your own little host that participates.
So DNS operations had some interesting thrust issues that won't fly if it's pointed toward the ground, apparently. The DNS flush and the DNS hammer. So apparently a significant amount of time gets spent manually clearing the cache in the DNS. 27‑person‑years is what's per domain apparently. So they're talking about ideas to automate flushing the cache but not destabilizing the DNS. So those are some pretty interesting presentations.
This is more work being done on the low‑energy, non‑chatty node stuff. And there was a BoF about it because the 6lowpan working group went away even though there's work to be done, so now they're trying to figure out where to put the work for that. 6RENUM is still talking about renumbering, you know, how to renumber on a massive scale.
Homenet. So there's some drafts about different Homenets. It's getting a little bit more rooted in reality, but it's still a little bit if I take my router to my neighbor's house what address should it get. So hopefully they're going to be focused more and more on just a Homenet that comes up and works and the routing works and stuff. There's a few more other drafts in that group.
The SIDR group, I missed one of the sessions because it conflicted, but I was glad I got to go to this session. There's some tools being done for RPKI that you should really check out. And I'm kind of hoping that maybe ARIN will be doing some of these tools. But there's a dashboard that you can look at on the prefixes in the routing table and which ones are authenticated. There's a tool that will let you generate a ROA, like you put in the information and out pops a ROA. You can validate origins with this little looking glass tool. And all the links to them are on here.
The ROA wizard. ROA to BGP prefix converter. Things that would facilitate ease of use of getting your data in and figuring out what's valid. They're pretty neat. I think it's LACNIC that has those. And then this, I don't see why this is ARIN's fault, but the uptake of RPKI in this region is embarrassing, I believe is what the slide says. So maybe we could all look into that. I swiped this slide. But this is some statistics on what's in the table, what's valid, what's invalid. The table. And there's performance as well. I believe his slides are online.
So this wasn't presented, but I was at the systers lunch and Lixia Zhang is a syster, and this is a interesting project and Van Jacobsen and Lixia have been working on it. It's kind of like the next generation of the Internet. So if you're interested in that, I would check out their website. It's pretty cool. These are the usual references and links. And I guess if there are any questions...
John Curran: Any questions for Cathy?
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Not so much a question as a comment. The low‑power stuff really isn't just machine focused. It's about a lot of technologies that are coming in cars, that are coming in household gadgets and small‑sensor doohickeys and lots of little networking‑enabled things that are coming down the pipe that are going to be everyday‑use kind of articles including the ability to program the LEDs that are built into your shirt to display different things. There's all kinds of really bizarre projects involving this low‑power networking stuff that are going to be pretty interesting.
Cathy Aronson: The people who are really pushing it, though, really are the machine ‑‑ the guys in the factories and stuff, but you're totally right.
Leo Vegoda: Leo Vegoda from ICANN. You mentioned ULAs and lack of filtering. And I just wanted to let people know or remind them, because they may not know, earlier this year Michelle Cotton and I as ICANN worked with Ron Bonica and Brian Haberman on updating the special registries.
Previously they were lists of addresses and references to go and see the RFC for why they are special. And now they are useful. And if you go and look at the special registries now, you will go and see stuff like can this address be used as a source address, should it be a destination address, is it forwardable, is it global, all that kind of thing with a billion true and false, and you can go and use this information to quickly and easily go and build some of the basic elements of the security policy, and that's the same for IPv4 and IPv6. So we probably haven't communicated the fact that we've gone and made things more useful as well as we could have communicated. So I'm just taking this opportunity.
Cathy Aronson: Will you have someone at IEPG? Because that would be a really good thing to bring up.
Leo Vegoda: I don't know if we will, but if that's a request, we can probably make an effort to do that.
Cathy Aronson: Or if you could send me a couple of slides, I'd be happy to ‑‑
Leo Vegoda: I'll be in contact.
Cathy Aronson: Okay. Cool.
Andrew Sullivan: Andrew Sullivan. I work for Dyn, but I'm here because I'm the IAB liaison to the IETF Nom Com this year and I just wanted to point out given the earlier remark about getting people ‑‑ I have to be very careful. As the IAB liaison I have no opinion about this matter, but if you have an opinion about people that ought to be nominated, now is the time to do it. So please hurry because we're going to move ahead. And if you wanted that to change, then you could suggest people who would be willing to stand.
Cathy Aronson: Thank you.
John Curran: Thank you very much. Okay. Thank you, Cathy.
Vint Cerf: Cathy, that's actually one of the most useful summaries I've seen in a long time. Do you do this on a regular basis and is that available as a blog or something?
Cathy Aronson: Well, ARIN sends me there and then I give this presentation.
Vint Cerf: But is that material put up somewhere where anyone who wants to could get access to it?
John Curran: It's on our meeting materials every meeting.
Vint Cerf: I would encourage you to consider blogging it to make it easily obtainable. It's great. It's terrific.
Cathy Aronson: Okay.
Vint Cerf: Wow. I don't know how you do that, but very impressive.
Cathy Aronson: I used to go to the IETF in the '90s. I think it's really hilarious. So I spend a lot of time trying to point out the interesting and funny bits. So if you like it, I'm really glad.
John Curran: I attend IETF, or about half of them, and I will tell you I still find this report incredibly useful and valuable. Just really good job. Thank you.
John Curran: Next up we have the ARIN Consultation and Suggestion Process Report with Richard Jimmerson.
ARIN Consultation and Suggestion Process Report
Richard Jimmerson: Thank you, John. I'm Richard Jimmerson with ARIN. For those of you who don't know, the ARIN Consultation and Suggestion Process is a mechanism for you to submit suggestions that you have about changes to ARIN's services and what we're actually delivering to you.
And inside that process one of the things that we have is an Open Consultation period. And we do this Open Consultation period twice a year. The most recent one opened on September 26th of 2013, just last month, and it closes on October 24th, here in a few weeks.
There were seven new suggestions submitted since the last consultation period that opened in March of 2013. With this Open Consultation we have a prioritization survey that you can go fill out, and you can actually let us know of these consultations ‑‑ or of these suggestions that we've received how you would actually rank them in priority. And what we do is we use that information to go and help determine our project work going forward.
These are the seven that were submitted since the last Open Consultation period. One of these, deploy two‑factor authentication, will be part of the engineering presentation that's going to happen here in a few moments. But for the others you can go to our website where we have all of the information listed about the open suggestions.
You can see what they're about. You can see their status, you can see comments from staff on them. You can see exactly what the author's intent was, the text that they submitted, and what they had to say about them, and you can actually share your feedback about those in this prioritization survey or on the ARIN Consult Mailing List, or you can speak to us here and we'll be sure to make sure that we put that information in the prioritization discussions at the staff level. With that, that's the update on the ARIN Consultation and Suggestion Process for this period. I'm happy to answer any questions you have. Thank you very much.
John Curran: Okay. We're going to move directly into the ARIN staff reports. First one up, Director of HR and administration, Erin Alligood.
ARIN Updates: Human Resources and Administration
Erin Alligood: Good morning, everyone. I'm Erin Alligood. I'm the new Director of HR and Administration for ARIN. I'm Erin at ARIN. I've been with ARIN for about six months, so this is my first official ARIN meeting. I'm very happy to be here. Thank you.
So, with that, we do have some new employees with the HR and Admin team. Myself and Sue Jones are both new. Sue Jones is our new office administrator. She's actually here. She's working at the registration desk. And Sue took the place of Misuk Kwon who is now in RSD with Leslie Nobile. So please stop by and say hello to Sue.
Thérèse Colosi is still part of the HR and admin team. She's back at the office holding down the fort. I'd like to thank both Sue and Thérèse for getting all of us here and booking our travel. They do a great job of that, so thank you. Some other additions to our management team. Val Winkelman was recently promoted to Director of Financial Services. And, with that, Nate Davis, our COO, has assumed some of the financial executive responsibilities for ARIN.
We've also successfully converted our contractors to full‑time employees, and we only have one contractor on staff at this time. We also completed our AC unit install project earlier this year before I came on board. I'm glad actually that was completed before I came on board. I heard it was quite a big project.
Vint Cerf: Advisory Council?
Erin Alligood: Oh, no. I'm sorry. An AC unit, air conditioning unit.
Vint Cerf: I thought it was installing the Advisory Council at ARIN.
Erin Alligood: I'm sorry, I should have been more clear.
John Curran: It's our new digital replacements for the AC.
Erin Alligood: Mary K. Lee actually did that project right before I came on board, so thank you to her for taking care of that. We conducted a salary survey with an outside consultant and as well as six‑month reviews earlier this summer. So some updates to our employee statistics. Right now we're at 57 employees. Eleven of those are new this year. So we've had some growth. But our tenure still remains very high. It's at almost six years. And our retention is also very good at 92 percent.
So this is just a snapshot of our employee population. As you can see, the majority of our employees are at six‑plus years. These figures are certainly very impressive and one of the main reasons why I came to work at ARIN. So some recent projects that I've taken on since I've come on board. We've planned some company‑sponsored events, including a full staff meeting that was held just a few weeks ago, in addition to some company socials. And we also had a flu shot clinic just a couple of weeks ago, actually. So hopefully all of us will remain healthy through this flu season.
We also ‑‑ I've also been attending some health care reform seminars, given some of the new legislation with the Affordable Health Care Act and making sure that all our benefits are in compliance with that new legislation. Additionally, we've updated our 401(k) trustees. They are myself, Val Winkelman, and Nate Davis, our COO. So we've been doing a fiduciary review of our plan and negotiating some of our fees associated with the plan.
Some upcoming projects that I'm going to take on over the course of the next year and possibly into 2015 are installing a new review performance mechanism. Right now we currently use Appraisal Smart and have been for several years now. I think our employees and our managers are ready for something new. So I'm going to be looking into something new for us to use to get everyone excited about a process that's probably a little bit monotonous for all of us.
We're also in the process of updating our cost category codes. And, with that, we're updating our timekeeping system. And we're actually just going to upgrade to the platform that's above the one we have now. So it's not a big change; however, it's a little bit more robust and has more reporting features.
So we're also ‑‑ excuse me. Our office configuration is pretty much the same as what it was when we first moved into the space several years ago. I don't know exactly the year we moved in. But since our employee count is a lot higher, the configuration probably needs to be revised along with some improvements to the space. We're probably going to look into new carpet and painting and hopefully maybe some revitalization to the space.
I've also been tackling rewriting some of our policies and procedures, and we'll do that over the course of the next few months as needed based, on the changing needs of the company. I'm also planning to conduct a 401(k) education session in conjunction with our benefits open enrollment probably in November or December. And at that time our investment advisor, along with our benefits broker, will be in attendance as well to answer any questions for our employees.
Next we'll be having harassment training for employees, probably in the first quarter of 2014. And then I'm planning to look into doing some team‑building activities for both our employees and our management team. So that's all I have.
John Curran: Thank you.
John Curran: Okay. Next up will be me giving the Government Affairs and Public Policy Report. Cathy would normally be doing this, but she's traveling. So because Cathy Handley can't be here, Executive Director of Government Affairs and Public Policy, I'll be doing it. It's actually an interesting report this time. Not that the others weren't, but this is probably more interesting given the recent developments.
ARIN Updates: Government Affairs and Public Policy Support
John Curran: What's our role? Participate in the Internet governance discussions globally to protect the community‑based multi‑stakeholder policy development model. That's sort of job one in what we do out there. These take place at a wide range of institutions and meetings. UN organized, IT organized, other events. We also involve coordination with other Internet registries, via the NRO, Internet Society, ICANN, IETF/IAB, and W3C, to get alignment as much as possible, make sure we're all working with each other.
Two days ago, three days ago, a group of us got together in Montevideo, and coming out of that was a statement, the Montevideo Statement on the Future of Internet Cooperation. It was the RIRs, IAB, IETF, W3C, the Internet Society, and ICANN, and we said it's important we have a globally coherent network and it's not fragmented on a national level and with concerns that responses to the revelations of widespread surveillance going on could cause fragmentation, people breaking up the Internet into national boundaries.
We want to make sure the Internet continues to evolve and addresses the challenges before us, including challenges that government and civil society have in making the Internet useful for the needs of the people. And so we want to see discussions towards global multi‑stakeholder Internet cooperation.
We called for accelerating for the globalization of the ICANN and IANA functions. These are performed by ICANN under various agreements, affirmation of commitments, MoU and IANA functions contract. I'd like to see an environment where all stakeholders including all governments participate on an equal footing.
And we called again for the transition to v6 to remain a top priority, particularly getting Internet content connected via both v4 and IPv6 because it's only once everything's reachable via v6 that it's really a complete substitute for IPv4. So this was the statement. ARIN signed on to this. This is positions that we've actually taken here before. People know that we are a big advocate for IPv6 and that we are going to be participating in these discussions. I reported it at our last meeting. Cathy reported it at the meeting before.
We're going to continue in these discussions to protect ‑‑ again, to protect the community‑based, multi‑stakeholder policy development model. I can't really say where the Internet's going today. We really don't know. We do know that there's going to be a lot of organizations having these discussions. And we may find ourselves in a reformed ecosystem, in a remodeled one, one with different structures and functions.
I hope to say no matter what happens I'll be standing before you in some number of years saying you can still make policies regarding how the Number Resources are administered in this region, that that's done in an open manner, and that it's based on the community coming together on that policy development, protecting that as our first and foremost concern. That's actually it for me. Questions? I'm like: Come on, please. Milton, come ask a question.
Milton Mueller: Let's have some fun, then. Milton Mueller, Syracuse University. I wrote a blog post about the Montevideo Statement last night. My title was something like "The Core Internet Institutions Abandon the US Government." I want you to know that this has spread like wildfire. Our traffic on the blog has gone from 4,000 to like 20,000. Still rising. So I would say there's a bit of interest in this topic and that it's a very significant statement.
Do you think there's going to be any fallout from the US government, or do you think you're in a position to actually follow up on some of the expectations you may be creating?
John Curran: So let's answer both those questions. First, on the following up. It's a call for discussions. There's no accompanying document, a blueprint that says this is what has to happen. It literally was saying we want to see these discussions happen, we want to have involvement of many parties.
I do think discussions will happen. In fact, I noticed right afterwards there was an announcement of a meeting between Fadi Chehade` of ICANN and President Rousseff of Brazil in which a meeting was announced. So I do think just like the IGF's meetings, just like that meeting was announced, there's going to be a lot of meetings discussing this. I'm not really worried about the follow‑up. I think that will happen.
So your first question had to do with fallout, not follow‑up, and I guess the Internet community is pretty important. The institutions involved, the RIRs, ICANN, ISOC, W3C, represent a lot of the technical coordination for the Internet. And if it turns out there's a model that protects that and protects the principles that the US government stood behind ‑‑ open, transparent, multi‑stakeholder, participatory ‑‑ then I think it's natural we'll be able to evolve as we need to. I'm not thinking it's inevitable, it will not be without quite a bit of discussion.
But the most important thing is we predict the principles. And under the current model, the Internet isn't really worth much if people don't have faith in it, if users don't trust it and if it fragments. So we really have to avoid that. We to have a global Internet we have to have discussions. If those lead to a model that protect the principles that we've been asserting for a decade, I don't know why we won't be able to evolve that way. Any other questions?
Geoff Huston: Geoff Huston. Like many I suppose around here, I happen to have been involved in this activity for a long, long time. And I reflect that a lot of the reasons why we do things and even to some extent the rationale and, dare I say it, the authority to do so actually stems from conversations and practices.
And when we look for documents that go this is your job, this is our job, often it was ‑‑ actually, now, that was a conversation with John. And it was a fine conversation and the right conversation and we've ended up doing the right things, but when some of the balls get tossed in the air and folk go, well, why, the answer is really, well, that's the way it was the right thing to do, and we've gone and done that ever since.
Is it time for us to look at each other and go, let's write down the reasons why we all stand together, why the IETF and the RIRs and the IANA function and ICANN have these things in common, and would such an exercise help us in explaining to other parties who are looking at the situation, explain why we do what we do? Because, I must admit, when I look for some of the rationale, and I was searching for it in the address space when thinking about activities in LISP, et cetera, I was going, other than RFC 2850, where is this stuff?
So I'm not saying you should. I'm not saying any of us should. I'm simply observing we've come a long way on understanding and common principle. But when others look at it, that's all we've got to rely on. And maybe we should think about what can we say about the way in which we work together.
John Curran: I think that's very worthwhile. Obviously efforts like ‑‑ even though it wasn't necessarily mandatory, efforts like touching 2050 and refreshing it with RFC 7020, even though we all know what's involved and what should be there, it's helpful for the rest of the world to see something that's current and accurate. And I do think we'll see a lot of those activities over the next few months, as we just make sure we understand what are the principles, morals, and values that hold us together.
Geoff Huston: And speaking to someone who has some of this, I would be happy to help you and happy to write down my bits.
John Curran: Thank you. Next.
Scott Leibrand: Remote comment from jabber. Regarding your last slide about v6 adoption, Kevin Otte asks: What can we do to encourage the content providers to step up their adoption?
John Curran: So that problem comes up ‑‑ let's see, it's been two days now ‑‑ actually, if I go back to NANOG, it's been five, and I've probably heard ten or 15 times people say: What can we do to get v6 deployed? I'm going to get very specific on this bullet. It says: Make sure that Internet content serve Internet with v4 and v6 to make sure it's fully reachable. It's actually not that hard.
If someone says they have something on the Internet and it's not v6 reachable, call them on it. It's only on a subset of the Internet. If you have a website and it's not v6 reachable, it's not on the Internet. It's only on a part of the Internet. If everyone in this room says that to everyone they meet, that will make a difference. Thank you. Okay. I'd like to move on to the next report, and it is Val Winkelman, Financial Services.
ARIN Updates: Financial Services
Val Winkelman: Good morning. I'm Val Winkelman with Financial Services, and today I'm going to talk a little bit about the staff, some ARIN Online issues that deal with billing and the payment invoicing statistics. After Bob Stratton's passing we reorganized the finance department, as Erin had reported in her report, and Nate Davis assumed the executive responsibilities for the finance department. I was selected as Director of Finance. We have Tammy Rowe, Accounting Supervisor, and she's been here all week on the registration desk. So I'm sure all of you have seen her.
And she's done a wonderful job, and she has four people under her now: Tanya, Amaris, Amy, and Mursal. And Mursal is the newest addition to our finance department. Came on as a temporary; did such a wonderful job we offered her a full‑time position.
Billing management and ARIN Online. It's very important to keep your billing point of contact updated. It's the contact for when we send out our invoices. It's also the contact for when we send out reminders when your invoice is overdue. And if the ARIN staff needs to contact you regarding a payment or questions about your invoices, that's the person that we'll initially contact.
And the way you do it is you have to have an account on ARIN Online, and you log in to your online account. You select the billing information tab on the left‑hand menu, click the ORG ID, and at the billing page, if the information is correct or not correct, you go ahead and fill out any changes you want and then you proceed to the new contact information.
ARIN fee calculator was added when the new fee schedule was instituted. And it was designed to help companies estimate their annual fees since they may have changed. And to use a calculator you log in to your ARIN Online account, navigate to the billing information section and select the ORG that you want to look at. The estimated fees will ‑‑ I'm sorry. Excuse me. I'm going ahead of myself. Once you selected the ORG you're inquiring about, you can select the fee button on the right and the estimated fees will display.
Now, the fees are just the fees at that time. If you make any changes, obviously the fees are going to change on there. And the fee calculator cannot be used to show different years, old fee schedule estimates or what‑if scenarios. It is just the fee at the time.
Payment types. As you can see, we have more credit card payments than we do check payments. But the check payments are much higher than the credit cards. And the wires are very minimal.
Registration revenue, it's very steady throughout the years, going up just a little, and of course v4 and v6 are the lion's share of all the revenue. And in a percentage mix, it's very much steady throughout the years. And that's all.
John Curran: Any questions? No? Thank you.
John Curran: As many of you know, Bob Stratton, our CFO, passed earlier this year. His efforts have already been recognized by the Board of Trustees, the ARIN Advisory Council, many of you in the community. And we've passed your kind words and thoughts to his family. Bob was at the inception of ARIN, and his efforts led to our financial strength and the success we are today. We'll remember Bob by his accomplishments, his spirit, and his friendship. He'll remain within our memories. Thank you.
John Curran: I'd like to ask Leslie Nobile to come up and give the Registration Services presentation.
ARIN Updates: Registration Services
Leslie Nobile: Good morning, everyone. I have a quick update from Registration Services. The RSD team ‑‑ this is a very hard‑working team, by the way. There's nine of us. Nine of them; I'm the tenth. You might see some changes on here. Two of our analysts left us this year in June, David Huberman and Chad Eastman, and they were both senior analysts. And the stars sort of aligned in a bad way and one of our staff members had a heart attack the same week that they left.
So we were down three staff members for almost two months, and you may have noticed a slowdown in some of our requests and processing, and that is the reason why. But we are back up to speed. We have hired two new analysts, Shawn and Misuk, and we are in training and getting up to speed.
Recent trends we're seeing. So with IPv4, there's been no measurable increase in the total amount of space that we're issuing. This year I think we've issued 1.07 /8s and we've got a quarter left. Last year we issued 1.7 /8s in total, so we're pretty much on track. We've seen a slight increase in the number of requests, particularly in the end‑user requests, not ISP requests, and it's like less than ten percent increase.
Transfers. No measurable increase in any of the requested transfers, and that's 8.23 and ‑4. Well, 8.4 is a slight increase. But IPv6, a slight increase in the ISP requests and a decrease in the End‑user requests. It's about a 13 percent increase in the v6 ISP requests, which is a very good thing. ASNs, we're seeing a slight increase in the total ASNs issued, and I had mentioned the 4‑byte ASNs yesterday.
Recent trends. We are seeing Points of Contacts of Legacy resources that are registered to companies that were dissolved long ago coming into us and requesting to transfer these resources. And it's not always evident to us that they're actually authorized to do this. To perform this, as you know, ARIN issues resources to organizations based on need. And when companies go out of business and we can't find successor companies, we then have to do a trail, you know, to see where it leads. So we're doing lots of vetting and research on this stuff. And we're seeing an increase in out‑of‑region requests from both APNIC and the RIPE regions.
I mentioned the Customer Transaction Survey. We asked ten questions. We send a link out at the beginning of every single resource request and transfer request so that we get those that complete the process and those that don't. They both have an opportunity to give us their feedback; we sort of want the good and the bad.
And the tenth question is: Overall, how satisfied were you with the entire process? And this is the chart. And overall 93.1 percent were either very satisfied, satisfied, or somewhat satisfied. And we are working to increase that percentage and we're taking the feedback that we're getting. We've gotten over 150 responses, and we are using that feedback toward our process improvements this year.
John Curran: Pause. I like 93.1 percent. That pie chart we're going to look at, because that's the biggest 6.9 percent I've ever seen. And so I'm thinking it's 93, I hope, but we'll look at that afterwards.
Leslie Nobile: You're right. It is 93 percent, I promise you.
Okay. Current IPv4 inventory. We've got 1.74 /8s equivalents remaining in the pool of available addresses. We've got about 7.02 /16 equivalents in our RRH bucket. That's our quarantine space; space that we recover, reclaim, revoke, whatever. We put it in there and we hold it for three months to clear filters, and then we release it back into our available inventory. We have one /10 reserved for the NRPM dedicated IPv4 block to facilitate IPv6 deployment.
Oh, that's ugly. What happened? That didn't come out right, but I think I can talk to it maybe. Wow, that's really bad. I'm sorry. You can go to the link and actually see the block sizes yourself, but it's the block size distribution of our remaining IPv4 inventory. We have it at that link right there. And it shows you how many prefixes of each ‑‑ I mean how many prefixes in total that we have left. And, as you can see, the one that you can't actually see is the one /8 total.
And people have asked us when might you break into that last /8. So we've got about .74 /8s equivalents remaining, not including that /8, and based on ‑‑ we did some numbers. On our current issuance rates of the blocks /22 and larger, it could be six to seven months before we actually need to break into the block, but that's all dependent upon the number of larger prefixes that we issue. If a couple of large ISPs come in and take those /12s or the /11s that we have, we'll end up having to go into the /8.
That's better. ARIN's IPv4 countdown plan. We have a defined process for our final IPv4 requests, and we've divided it into four phases. We are currently in Phase 3. We will move into Phase Four once we have one /8 equivalent remaining. And the procedures will be first in, first out. That's how we process all requests. That's what we do now. That's not going to change. All IPv4 requests will be team reviewed to keep things on an even level. And right now only the /16s and larger are team reviewed.
The hold period for those recovered resources will move from 90 days to 30 days. So as soon as we hit the 30‑day mark, they'll go back into the available pool. And you will have 60 days from the time that we approve your request to complete the payment and sign the RSA and get everything back to us. If it goes over 60 days into day 61, that transaction will be cancelled and you'd have to start over again.
Recovered resources. We get lots of resources back. We've gone back six years and looked at what we've gotten returned or recovered, revoked or reclaimed. And you can see we had a high in 2011 of 284 v6 and v4 blocks ‑‑ sorry, /16 equivalents, and that was the Interop space that was returned which basically went back to IANA.
And even this year we've had 4.4 /16s equivalents come back; four percent of those were returned. So we are still seeing people return space to us. ASNs are mostly all revoked due to nonpayment of registration fees. And you can see, as I said yesterday, it's sort of all over the place. We had a high of 1500 and a low of three something, 365.
So some of the common problems with resource requests. Someone asked me: Maybe you should talk about what you see, what are the top five things that people have difficulty with or ask you to do when they're requesting resources. First‑time requesters don't have IPs reassigned or SWIPed to them when they come to us, and they need to be. The policy says you have to be SWIPed and we have to be able to see it. So that's very common.
We're seeing /24s being requested for anycast and multi‑homing requirements, with no host counts to support the request. They say: I'm multi‑homed; I should be able to get the 24. So they're not really understanding the policy. And obviously there's no policy that supports that. We have people that are not multi‑homed or won't be for many months but they want their IP addresses in advance in order to be ready to deploy. It's kind of that chicken and egg because the policy says you have to be multi‑homed or immediately plan on immediately multi‑homing.
The block size that's been requested is larger than is justified for the three‑month need based on their demonstrated historical utilization rate. So they ask big. They ask for a /16 and we give them a /22. That's pretty typical. And that goes back to slow start, by the way. Customer justification data is not well understood. They actually don't understand what we're looking for. And they have asked us for a standard form. We've seen that request come a couple of times. So we're now working on a customer justification form as an example that we're going to put up on the Web that people can use.
And a lot of people don't want to provide customer information due to privacy concerns. That is particularly relevant from our Canadian customers as there are some strict privacy laws in Canada. And then we're seeing a lot of customers who want their requests expedited. This is a new thing. And obviously we said we'd do first in, first out, and we do not expedite. Everyone is treated equally.
Phone stats. I just thought I would throw this in. We have a new phone system. It's really easy to get these stats. We operate our phones from 7:00 a.m. to 7:00 p.m. we're averaging about 776 calls per month. Our highest call volume time is between 2:00 and 3:00. If you want to talk to someone, you might not want to call between 2:00 and 3:00. Lowest call volume time is between 7:00 and 8:00 a.m. Eastern Time and then after 5:00 p.m. as well. And busiest call day of the week is Tuesday and the least busy day is Friday.
Just looking at IPv4 space issued. Well, there's no growth trend, as I said. We have seen no discernible growth rate in what we're issuing. We've got assignments in light blue and allocations in dark blue. And, as I mentioned, 1.07 /8s issued and should be about the same this year as last year.
IPv6 space issued. This is actually encouraging because it looks like 2013 we will issue more IPv6 allocations than we did last year. And that's a good thing. We were on a steady growth rate and then something happened in 2012 where it just ‑‑ I don't know, it just went down. But it's rebounding. So that's good. And we always look at how many of our subscriber members have both IPv4 and IPv6. We've got 4,484 total subscriber members. 55 percent of them are IPv4 only. six percent of them are IPv6 only. And those are our legacy customers who have IPv4 from before but are coming to us for IPv6 allocations and then they become subscriber members by virtue of having IPv6. And then 39 percent of our members have both IPv4 and IPv6, which is getting better. It was 37 percent the last time I did the report a few months ago. So it's some growth.
Okay. 8.3 and 8.4 transfers. There's not a lot of them happening, as you can see. Three is the top number there that we've completed in a month. And there's not really much to say. It goes up and down. I expect 8.3s to really ‑‑ and 8.4s to really increase as we get closer to depletion, but right now they're kind of scattered. We've completed 18 inter‑RIR transfers from ARIN to the APNIC region to date. And that's all I have. Any questions?
Owen DeLong: Owen DeLong, Hurricane Electric. Can you go back, I think it's two slides. There. Would it be possible to get a version of that that is weighted by the portion of IPv4 address space held so that we could, for example, tell what percentage of the total IPv4 space holders have IPv6 versus the total IPv4 organizations? Does that make any sense?
Leslie Nobile: Kind of.
John Curran: Can you get offline with Leslie and ‑‑
Owen DeLong: Sure.
John Curran: ‑‑ figure out what you're asking for. Happy to generate if we know what we're generating.
Leslie Nobile: Kevin is next.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Can you go back to the common problems slide for a second. That's great. Thank you. So you said these companies come in from anycast, multi‑homing with no host counts, meaning they don't have IPs currently in use or they just don't have a form on how they're going to use that space immediately once they have them?
Leslie Nobile: They're coming in without any IP addresses and they have ‑‑ so no history. They have nothing to show us as far as ‑‑
John Curran: None of them were SWIPed to them.
Kevin Blumberg: Okay. But with current policy, if I'm a new entrant ‑‑ correct me if I'm wrong ‑‑ and I can show that I'm going to use that, I've got my contracts ready to go, does previous history play into this? Is this an issue? If I'm immediately going to use a /26, as an example, and I am showing you my host counts and here's my server that I've purchased and here's my contracts for my multi‑homing, is that an issue?
Leslie Nobile: You know, I'm actually not sure.
John Curran: I was going to say, if you're looking to ‑‑ so you're a new requester, initial requester?
Kevin Blumberg: Correct.
John Curran: You're not going under immediate need?
Kevin Blumberg: Correct.
John Curran: And you're multi‑homed, not multi‑homed?
Kevin Blumberg: This is multi‑homed.
John Curran: You're multi‑homed, you're a requester, you have multi‑home threshold for the minimum block. Whether you qualify for that minimum block, you're going to have to show us you have enough hosts. If you have similar sizes already SWIPed to you, then it's very fast, because you've already been allocated upstream space.
If you haven't, you have to explain to us what addresses you need, but you have no evidence that you need them because an ISP didn't give them to you out of their block already.
Kevin Blumberg: I understand that. That's going to get harder and harder as the new entrant can't get the IPs in the first place. So, again, I'm asking is the policy ‑‑ is it just a documentation issue that the initial requester just needs to give you more information: Here's how I'm going to use it, here's my contracts, et cetera, et cetera? More due diligence: Here's the host I'm going to be setting up in the next 30 days?
John Curran: Existing practice is that the SWIPs from your existing ISPs are considered to be valid demonstration of need. And, absent those, we have to do it manually. So as things get tighter and tighter, it gets harder and harder. If you want to address this problem, we need to come up with a common way for you to say, yes, I'm qualified, even though my ISP didn't give it to me and he should have.
Leslie Nobile: So, Kevin, there's no policy right now that says you can get a /24 if you're multi‑homed.
John Curran: Or we adopt a policy that says all requesters have the chance to get one block regardless of whether or not their ISP qualified them and regardless ‑‑ because otherwise you're going to have to give us justification of why you suddenly are warranting a /24.
Leslie Nobile: Cathy.
Cathy Aronson: Cathy Aronson. So we were at ‑‑ maybe it was Barbados, and we have a whole policy right now about out of‑region assignments and allocations because we were told that this was exploding and that there's lots and lots of address space and people coming back for more that are perhaps out of region. But then I see that the trend is we've assigned just about what we did last year. So I guess has that changed? Was it not accurate? Because some of us felt that we need this policy that we're working on right now because all the address space was being drained to some other place, and now I don't see that that ‑‑
John Curran: Let me address that. The total number of requests, as of the beginning of this month, we had done 52 requests of that nature and they added up to about a /11 of IPv4 space. They're still ongoing. So it's hard to know whether they're getting more rapid or less rapid. If you can live with that amount of space going out of the pool, then there's no problem.
Cathy Aronson: But it looks like ‑‑
John Curran: At the beginning when we were reporting in Barbados, it looked like it was growing rapidly and more rapidly. Now it looks to be more a steady trend than a rapid growth, if that helps to characterize it.
Andrew Dul: Andrew Dul. I have a question about the legacy resources suddenly coming back to life. Do you think you have the tools and/or the policy necessary to do the right things with regard to these issues that you're seeing?
John Curran: So yes. Recognize people are very creative. So there's ‑‑ if an organization was dissolved long ago and now you're showing up ten years later or 12 years later and you're saying, oh, but really it's been in use, I sold it to my brother just before we went into the courtroom, we're going to ask for justification of that. And it's ‑‑ if the community wants us to be very generous and just say yes, we could, but recognize in some cases those resources might have ended up being turned in or reclaimed and gone out again.
So to some extent I think we're doing the right thing exactly as we are now. Want the community to know that if your organization's dissolved and you didn't come to ARIN and tell us why, coming now ten years later probably makes no sense.
I think we've got it covered. I'll let ‑‑ myself and/or Steve Ryan will let you know a year from now if I'm telling you the truth.
Leslie Nobile: John Springer's in the back.
John Springer: John Springer, Inland Telephone. The initial IPv6 allocation slide. Initial and total. Allocation and assignments. I'm sorry, I misread it.
Leslie Nobile: Geoff.
Geoff Huston: I have a nitpicky question. You mentioned that you reserved that /10 to be used at the last point somewhere there, reserved. Because I'll catch that word and remember it. And then I look up the global policy for the allocation of recovered IPv4 addresses from IANA, and it states quite carefully when the first RIR has less than a /9 in its inventory, it's going to start dealing them out. And there are 20.4 million addresses.
Now that you've reserved it, for the purposes of this other policy, is it in your inventory or not?
John Curran: I would need to look at it.
Geoff Huston: You better have an answer between now and, say, nine months' time, because at some point this really does affect everybody, including LACNIC, most critically, because if you trigger it, LACNIC gets some millions of addresses as well. And they're running at about four or five months after ARIN. If you don't trigger it, LACNIC's got a different policy and they haven't reserved. So we want it free off those blocks anytime soon.
So it would be good for us to understand kind of now exactly how the application of that IANA policy maps to your practices in ARIN about the treatment of that /10. And when you work it out, could you let me know so I can update the exhaustion timetable?
John Curran: Sure. I will go look at the policy and I will report back.
Leslie Nobile: We have talked about this and ‑‑ Geoff and I have talked about this and the policy very clearly says that it's for a special use, it's only for those transitioning, and it's very specific. So it's not a general inventory. It's not available to the general public. That is one thing I can say. So it becomes tricky. That's all I have. Someone in the back.
Derek Adamian: Hi. Derek Adamian, HostCurve. This is more of a privacy issue in a lot of nondisclosure agreements. How can hosting providers and ISPs help feed ARIN information which they require for new allocations while keeping customer data private and what does ARIN do to also help ease the worries of the people feeding information that it won't be released? How do they help keep this confidential information confidential?
John Curran: ARIN has an NDA that we will enter into specifically to protect the information that you need to make your request. So it's something that we've had very few organizations that have had difficulty with. It's a fairly routine process to enter an NDA with us. We'll take that information, we'll use it to process your request. That information remains confidential. We don't share it with anyone. All of the ‑‑ you'll see me routinely say on the Mailing List, people say, well, we don't understand why that happened. I'm sorry, the nature of the supporting information is confidential. We don't disclose it to anyone.
Derek Adamian: Thank you.
Leslie Nobile: Thank you for your time.
John Curran: Thank you, Leslie.
John Curran: Moving right ahead, the Engineering Report. Mark. No, Andy. Welcome
ARIN Updates: Engineering
Andy Newton: I'm Andy Newton, Chief Engineer at ARIN. Normally Mark Kosters gives this report, but he had a previous commitment and had to fly out earlier today ‑‑ or yesterday. So how does this work? Here we go. Staffing, engineering staffing. So normally when Mark gets up here and goes over our staffing requirements, we normally in one area of engineering have ‑‑ we're not at full strength in some regard or another.
And unfortunately I have to report that same thing this time around. For about four months we did have full staff, we did have our full complement and strength in the Engineering department, but recently we had a developer be with us 12 years departed.
But in operations we have seven engineers plus two managers. Seven programmers in development, plus manager, which is me. Q&A, we have four engineers, a contractor, and another manager. And then we have project management. And at the top we have Mark Kosters.
So the things we've been working on in the Engineering department since the last time we gave this report. We've been doing a lot of work on improving back‑office processes, things that automate the things that both our Registration Services department and our Financial Services department do, including revocation of resources and returning of resources and automation of how the database works, and automation of invoicing.
The new fee schedule, which Val showed you, that consumed quite a bit of our time earlier on during the year. But that's now down. We also have RPKI delegated services now. We introduced web-delegated earlier this year. And as of last month, the 7th of last month, we have up‑down delegated services, including ERX space.
One of the other projects that we're currently working on is consuming quite a bit of resources, but hopefully we'll get it done pretty soon, is we're migrating off our Oracle relational database and we're moving to Postgres, which is an open source database. This will reduce our costs as far as licensing goes and ongoing maintenance of the database, and we hope it will also enable some speed of development, better speed of development.
This past year we've had some issues with some of our hardware and some of our vendors, specifically some of the load‑balancing hardware that caused some instability in our networks. We had a couple of outages due to these things. I'm happy to announce we've got them all resolved. But it consumed quite a bit of our time, especially for our operations department.
We deployed the extended statistics files earlier this year. That now puts us on parity with the other RIRs. All the RIRs are doing this, publishing this information.
And our operations department has been extremely busy. One of the things they've been up to is they're trying to make our systems more robust, more fault tolerant, been improving our backups, moving some of our production services to our disaster recovery sites. And they're installing new systems for auto provisioning of servers and, as servers reach end of life, switching them out and making it as painless as possible, using things like Puppet and Foreman.
And in addition to that they help run our help desk and do IT support. They're here at the member meeting helping to run the network as well. We're also involved with third‑party vendor selection for some of the systems that are going to be used at ARIN. Jud talked about the new election system, which is now integrated with ARIN Online. That's one of the things we did in the past year. And coming up we're in the midst of looking at a new meeting registration system from a third‑party vendor.
One of the efforts we began earlier late last year and continues as an ongoing effort is improvement in our user interface for the website. And we were doing some usability testing. For those of you ‑‑ some of you who were in Barbados, you got pulled into a room and we ran you through a script trying to figure out where in the website process people were getting hung up.
And, finally, one of the other things we do is we go to the IETF and we participate in activities there, most specifically the SIDR working group and the RPKI work that goes on there and also in the WEIRDS working group with the RDAP protocol. Statistics. We now have just north of 74,000 ARIN Online accounts. We continue adding accounts this year at a considerable clip, though not as much as we did in the two previous years. I'm sorry, three previous years. But it's still going.
Usage of ARIN Online hasn't really changed as a result of how many log in. We have a considerable number who log in only once, and we have this inverse bell shape where we have people who will log in between one and 15 times, and from there we have a lot of people who log in over 16 times. We have about 9,000 who log in quite a lot.
This has changed since the last meeting. So our transactions for the registration system, registration RESTful Web service, Reg‑RWS, has gone up considerably since the last meeting. These are transactions, which means this is someone doing a REST call to our system and changing information in our database in one way or other, either updating, modifying, or deleting data.
What the graph actually doesn't show is we also have a considerable number of people who every single day throughout the day are querying our system using Reg‑RWS to verify that the customer data they have in their database matches the customer data we have in our database. They do this all the time. They're doing it hundreds of times a second every day. So that system is seeing quite a bit of use.
As far as reports go, people who are getting reports via ARIN Online or via the Reg‑RWS, which is what the Via REST column says, we have a considerable number asking for reassignment reports, 31,000 via the website. WhoWas, which is actually the newest type of report that you can do, we have 10,000 of those that have been requested via the website.
And interesting other number is the 30,000 that had been requested via RESTful web service. This slide is wrong because it's now 40,000. We had someone just last week hit us with 10,000 requests.
As far as API keys go, the API keys are the means that people use for submitting templates and for using the Reg‑RWS system. We have just about 7,000 users, ARIN Online users, with API keys, and somewhere around two‑thirds of them have associated those with an email address so they can use it with the template ‑‑ with a template.
RPKI usage. All the numbers in RPKI continue to go up. The number of RPAs signed is actually getting pretty good. We started off with 27 and now we have 130 RPAs signed. Number of ROAs, number of covered resources is also going up.
As I said before, to the bottom of the chart we have 0 for web-delegated and up/down delegated. Web delegated has been around for just over six months and up/down we just deployed last month, so that's why those are 0.
Whois traffic continues to be about the same. We're running around 400 queries per second over Port 43 and around 600 queries per second over the RESTful system. Though the percentage coming over v6 has increased, now we're almost up to three percent of our total Whois traffic coming over v6.
The IRR. So we continue adding IRR maintainers. The acceleration ‑‑ or it's actually decelerated quite a bit. The rate's gone down ‑‑ not quite a bit ‑‑ a little bit, the number of maintainers, but they're still coming in.
As far as route objects go, the route objects are being added about the same pace. The Route6 objects, the rate has declined slightly. And the same thing for the InetNum and Inet6Num objects in the IRR. One of the other efforts we have in the Engineering department is we're looking how to implement ACSP 2013.8 and what kind of technology we would be required for doing two‑factor authentication of our systems.
One of the issues we have there is we're trying to find technologies that are acceptable to our community. We went and looked at how many people adopted the PGP signing of templates since we do offer that and how many use the X 509 template signing when we did offer that. And the numbers there aren't very high. So we're trying to figure out how to target a technology to our community that doesn't have a high barrier to adoption.
We note that most common two‑factor authentication used today either uses an email, a link in an email, or that uses an SMS code on a mobile phone. And we started looking at these methods and seeing what they involved and how well they work. A lot of these things are actually susceptible to man‑in‑the‑middle attacks still. So we're trying to evaluate what kind of technology we want there that meets the security that we need. So far the most secure method that we have found is the use of a mobile app that uses an out‑of‑band verification. Doesn't require someone to key in a code back into our website.
And finally the other things we've been up to is we performed two Interops at the last IETF. As far as RPKI goes, we did Interop testing with our up/down protocol suite with the other RIRs, and that was very successful. And we plan to start doing ERX up/down testing with our production with APNIC very soon when we start talking to them at the next IETF about becoming an up server and down client with them.
And then, finally, we also did ‑‑ we participated in the RDAP Interop testing that occurred at the last IETF. And that was with quite a few registries. APNIC was there, RIPE NCC was there, LACNIC was there, and then we had the domain registries who were there, Afilias, VeriSign, and CNNIC as well. We have a testbed for our RDAP server that runs the registry services. It has the same information or close to the same information that you would get out of the WHOIS‑RWS system. And we also have some open source software which we wrote to help this Interop go smoothly. And there is another Interop planned for IETF 88, which we do plan to participate in. And that's it. Any questions?
Cathy Aronson: I guess I should sit closer to the microphone. Cathy Aronson. Do you have plans to do any of those tools like LACNIC's doing for the RPKI? Because they seem like they'd be super useful for our customers.
Andy Newton: At present, no, we don't have anything planned for that.
Heather Schiller: Hi. Heather Schiller, Google Fiber. You have a suggestion list. You have ‑‑ every time we come and we say we really want this neat new thing or this really neat old thing that everybody else already has, you say: Put it in the suggestion box. We put things in the suggestion box and they languish and they go there to die. We do have WhoWas. That only took like two or three years. So you have stuff ‑‑ I'm sorry, but like really you have stuff that's been in there for years.
And like maybe in 2012 we had this discussion and I got up at the mic and I said: You have these things that have been in the bucket for years. And ‑‑ or, I'm sorry, maybe that was 2011. And you came back and you said: Okay, we rank them according to cost and tell us which ones you want to implement. Can you prioritize these? So the funny thing is you built a web page that has all of the ones that are not prioritized, and so we don't know when we're getting the ones that were prioritized, and that aside from the fact that some of the costs for these things was mind-boggling.
So a million and a half dollars to support multiple API keys? Really? Really? Because you can already generate API keys and you can set up separate POC IDs and fudge your way around it. But there should be an easier way. And $270,000 to display on the results of a Whois page the IP address that you put in the form that you were searching for to begin with, like some of these really ‑‑ it's unbelievable. So what I would ask for, and I put it in the suggestion box for you today, is please publish a list of all of the projects, not just the things that have been asked for by the community, but the things that you have on your own plate that you've come up with yourselves.
Publish that publicly, ranked with the cost estimate and the estimated completion date so that the community can see when ‑‑ like on a quarterly or semi‑annual basis what things are coming so that we understand not just at the meeting when you show a slide that nobody can then go back and find what you're working on, and then at the next meeting you can say, look, we've been telling you that you're going to get these things by the next meeting, and here they are. Because it's really ‑‑ it's really difficult.
When we compare the tools that we have in the ARIN region to RIPE and APNIC, I would really like to see more sharing, more integration. Use things that other regions have built. If LACNIC has built some awesome tools for RPKI, don't go rebuild your own; please work out some arrangement with them to be able to share some of these tools. And maybe do advanced coordination of new tools so that you're not all separately developing something different. If you can work together on policy and work together for other things and you can get the AC together, I imagine that you can get your engineering teams together.
John Curran: Let me take this one. Heather, come on back. First, recognize we were starting a little behind. So we had the circumstance where we didn't even have ARIN Online and we spent several years actually in a surge trying to catch up and build the system. And we did. And with a lot of contractors actually. And the Board has given me guidance that says we don't want to have a very large permanent‑standing engineering organization. We actually converted from having a large pool of contractors to a modest size of development. That's what Andy covered earlier.
So we do have development capabilities and ‑‑ but they're modest. And so we do have to prioritize. I will look to see if we can get clearer information about what's next in the queue on the website. That shouldn't be hard to do. But understand we also have demands from all over. So the rate at which we go is modulated by how much effort we want to put into engineering each year, and we're trying to do that at a modest pace because it affects the cost of the organization.
We are willing to share tools and work with the other RIRs. We don't want to reproduce anything. But recognize that we all have different back-ends and different systems and it doesn't just come together. So, for example, when we're doing work, our requirements for RPKI actually in some cases are different than other regions. We actually have hardware HSMs that were required for our security profile.
So we are working with the other RIRs. We do try to share. I will get more information out there. We can try to figure out how much to put up ‑‑ whether or not we can pre-commit to items and put them up, as soon as the Board gives us a budget for the year, I can try to put it in the pipeline what exactly you're going to see and when.
But that's an annual process. We're at the end of the year so we're catching up on a lot of internal items. I'm not trying to discourage you. In fact, I think your feedback is enormously valuable here, but at the same time I want people to realize that the amount of tools that you could ask us for, we're an organization of 57 people. We don't want to be an organization of 100. So we want to prioritize all the expenditures if we're going to keep ARIN at the size that we're at.
Paul Andersen: Can I add to that. You said you put it in the suggestion bucket ‑‑
Heather Schiller: Because I knew you were going to tell me to do that anyway.
Paul Andersen: I think you make a good point. I'd have to work with Nate, who I know carries forward at least when we come and ask the community and the membership for feedback on which items should we maybe be prioritizing. And putting some kind of magnitude of effort and cost in there might be a useful information since, as you pointed out, there are some shocks in terms of the cost and such like that.
So I think that would be good thing to explore, to kind of address that. I don't know if we get into exact numbers because I don't think that might be useful, but I think just giving some degree of magnitude of the impact on the resources and costs to the organization is useful information, if we're going to ask you to help prioritize something.
Heather Schiller: So the ones that ‑‑ if you go in the suggestion box, just the suggestion box, because I don't know what ‑‑ and aside from what you tell us here, we don't really have a published list of what other projects you're working on. So in the suggestion box, the older ones have the cost estimate. And it came out of the fact that we were saying ‑‑ you came back and said there's a cost to these things. So the cost estimates are like exact, like $1,459,000. I mean, like they're pretty –
Paul Andersen: Precise estimates, I think.
Heather Schiller: I'm not totally convinced they're based entirely in reality, but some were surprising. But I think one of the things that I really want to stress is when you have a choice about tools and you have the opportunity to use something that another RIR already has that works ‑‑ I mean, you talked about building my ARIN Online like RIPE and APNIC, and I think probably LACNIC even had something before you had my ARIN Online. Like you're telling me that in all three there wasn't something there that you could have used? It's kind of surprising.
And there's another subtle part of this that might get missed, which is if you're a large multi‑national organization like we've been talking about the last couple of days and you manage resources in five regions, that's five logins, that's five different systems. It's five different methods of querying Whois. It's five different ‑‑ so you're balancing like not just five different sets of policies and five sets of rules about how to get resources or five different regions of templates and forms, but now you also have to balance the like ‑‑ the minutia of how to manage query updates and all this other crap. And having some consistency between the RIRs would be pretty nice.
John Curran: I hear your message and we're happy to use work where we can. The goal of consistency among the RIRs, however, in systems is a new design goal that we haven't been operating under. It's something that really would take a commitment of all of the members of all of the RIRs to pull off. So I'm all for getting synergies where we can get them. But you're adding a new requirement that we've never had before if you want the same systems. I want to share one thing. Andy, you can sit down. Actually, no, I see other people. Stay up.
So I do want to show one thing. Can you bring up arin.net/features. If you go to www.arin.net/features and hit return, you'll get a list, and it's not just what's in suggestions. You'll get a list of all the projects awaiting implementation in the order of priority that we set. So if you want to know what ‑‑ scroll down past projects underway. Keep going. Okay. Down. Past implemented. Keep going. That's all the stuff we've gotten done. Stop there.
This list, projects awaiting implementation in order of priority. Next, streamlined transfer. Next, additional operations test and evaluation services. Next, DNSSEC improvements. Next, Suggestion 2012‑1. Next, 2011 ‑‑ this is in the order of the nickels. Small bag of nickels, first two; big bag of nickels, first five; very large bag of nickels, more. Okay?
We try to put this in front of the members, and then ‑‑ you can scroll down. There's a few. Go to the next section. Engineering projects awaiting prioritization.
We're not losing track of anything. These are all the projects, about a page worth ‑‑ if you scroll down a little more to the end ‑‑ it's about a page worth that aren't on the list. They may end up earlier in the list, they may end up later. So we're trying to give you a level of visibility into what comes next. The implementation is order of priority, it just doesn't have dates yet. And it will. We'll try to add dates to that so you can know when to expect these. Heather, thoughts on that?
Heather Schiller: Yes. Of course. None of this is tied to the suggestion stuff. I could find the part ‑‑ there's a whole separate page for the stuff that's not prioritized. Like you have it in two places, but there's still no like ‑‑ there's no data, there's no ‑‑ you can't say I expect this to be implemented in the third quarter of 2014. Like there's no way to ‑‑
John Curran: Scroll down to order of priority on the screen, please.
Heather Schiller: You said that they were in cost order.
John Curran: No. You got to go up to get to them. Go ahead. Go up. Up, up, up, up, up, up. Beginning of section. Right there. Projects awaiting implementation in order of priority. The next project name is streamlined transfer service, the next is additional operation test and evaluation. What's not here ‑‑ and you're right ‑‑ is based on our current resources when are these going to get done. So we'll now work on adding a column on the far side or at the beginning that's our current ETA for all of these, for everything in this order, when it will get done.
The reason that this isn't the suggestions box is you'll see quite a few of these are internal. We spend a few nickels supporting our internal, like getting off Oracle or changing over a billing system. Takes quite a bit of resources. But because you want more than priority, you want estimates, we'll try to get quarterly estimates down for everything on this list based on our current resourcing. Will that help?
Heather Schiller: Yes. And I think it would be helpful in your engineering report, like bring up this list and say, okay, here's where we're at. Because it's sort of this feeling of reporting on ‑‑ doesn't feel like there's consistency, like being able to say in April this is the thing you can expect by the next meeting. And so just having status ‑‑ you used to have a session that reported on the suggestion stuff and saying ‑‑ going through each one and saying like here's where it's at, this is why we're doing it, this is why we're not doing it, here's why this might get implemented. And I don't think ‑‑ as far as I know, we don't have that anymore.
John Curran: Let's try to bring that back, then. Very helpful, Heather. Thank you.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Two things. From what I saw here, you did a lot of back‑office work this year. You've done a lot of back‑office work for a number of years. It's almost the ASCP has a very small bucket when all of the back‑office work gets taken into account. I'd like to see the focus on customer‑facing features. I'd like to see a change log from ARIN being sent out once a month saying, hey, we've added this little feature. Hey, we've added this little feature.
I'd like to see ARIN stop retooling the same back‑end systems, at least put a hold on it so you can get some of the features in. I'm going to echo what Heather was saying, but, quite frankly, after a year of seeing very little, if it was any other software platform, I'd consider it abandoned ware at this point. That was my one comment.
John Curran: Let me respond to your one comment. It's valid. So ARIN inherited a lot of systems, and they're all back there. They're like little boxes stacked on each other, kind of tied together, meshed together. It's an interesting back room with a lot of different pieces. When we built ARIN Online, you got to have interfaces to all of those. In addition to what you used to have, you picked up this new interface. But they're all still back there. What happened over the last two years is we started building new, new cleaner systems. For example, we finally ended up instead of working off of records that weren't resource records, we actually built a database of resource records, and that was huge. We added an organizational structure.
What we've been doing in the last year is shooting some of those older features. It's RSD when someone calls in and asks this, needs to go to that older system, which we're keeping alive on life support, even though we really want to kill it, until we add some feature into our new ARIN Online. You're seeing a lot of internal work. It's not churning the new system. It's adding functionality so we can shoot old ones. Because right now, when we do a major change, sometimes we have to backstitch it to these old systems. And it's only with having been able to shoot a bunch of them that we're at the point now where we can actually look at a smaller development team, et cetera.
So I know that's not visible, but that's what's been happening in the back room, is we're getting rid of these older systems as we move their functionality forward.
Kevin Blumberg: So, John, please let us know when the culling is complete so we can see the features on a reasonable basis.
John Curran: Yes.
Kevin Blumberg: Thank you. The second part was in regards to the two‑factor authentication. I was the person who put that in. And I actually just wanted to expand based on seeing the word "email" as this is what's being used but we don't think that's a good idea. Does ARIN get third‑party audits done in regards to security from anybody?
John Curran: We do a system ‑‑ we do a financial audit every year. We do an operations audit every year other year. And so the operations audit does pick up some security aspects, but it's not an independent security assessment.
Kevin Blumberg: So you don't do a best practices "we have found these issues with your external and internal systems" type from a third‑party; is that correct?
John Curran: We do that with a third‑party. It's an operations audit. Security is an aspect. It's not a dedicated security audit. It's a third‑party operations aspect that covers more than just security. It covers data integrity and other aspects.
Kevin Blumberg: Just out of curiosity, because this is worrying me, two‑factor never came up in these kinds of audits?
John Curran: It's a question of what the users want, not a question of what we use internally.
Kevin Blumberg: Maybe I'm confused. There are companies that audit for best practices from a security perspective. Irrelevant of what the customers ‑‑ the lowest common denominator might not care, but they will say, hey, we recommend these things because we're seeing these types of attacks. You don't have that done today?
John Curran: No, our auditor does not pick up that and decide that that's a priority. That's generally what occurs in some systems that ‑‑ for example, PCI and other ‑‑ run a datacenter with several hundred online applications. I'm aware of those type of audits. Our auditor did not say, no, you need to have two‑factor authentication for all the ARIN users.
Kevin Blumberg: I see another request coming in. Thank you.
John Curran: Okay.
Andy Newton: Sandy.
Sandy Murphy: Sandy Murphy, SPARTA. I was going to ask this offline but somebody asked me what it meant, so I thought I'd bring it up. On the slide that listed IETF participation listed as SIDR, of which I am well aware and thank you very much, WEIRDS, of which I was also aware, and RPKI GTA, which I pretty much am confident means global trust anchor, I was unaware of any IETF work on the RPKI global trust anchor. So I was going to ask.
Andy Newton: So at the IETF meetings we have been getting together with the other RIRs and with IANA staff and talking about how we were going to implement a global trust anchor.
Sandy Murphy: So this is a coincidence of timing and locality, not a IETF problem.
Andy Newton: Right. It's actually not an official IETF function. It's just that all the players are there at the IETF, so it's very convenient to do it there.
Sandy Murphy: Okay. Thank you.
John Curran: Ruediger?
Ruediger Volk: Ruediger Volk, Deutsche Telekom. I wonder whether you skipped to mention something or whether something is actually missing in your RPKI activities picture. Last year we were very happy about this time to see you actually turn up production, which, well, okay, production service only started about the last year's NANOG meeting and, well, okay, at that time you got rid of the old test environment.
For getting actual use of your RPKI, actually providing test and actually training environment for potential users I think is really important. For example, starting out as delegated CA is something that should not be taken lightly. If you do something wrong there, you will be shooting yourself not only into your foot but in other parts of your body as well. And not having testing and training environment there is certainly not helping people to move forward and it's always going to take some time. Was it missing just on your slides or is it just ‑‑ is it still missing in your environment?
John Curran: Go ahead and answer and I'll follow up.
Andy Newton: We have an OT&E environment, which is for testing of all of our services, except for ‑‑ I believe you can't test templates there. But anything that's online you can test there. Now, delegated CAs ‑‑ doing up/down, we just delivered that last month. So there haven't been many people who have had the opportunity. I'll let John address the training part.
John Curran: So we do have ‑‑ as he noted, we just added the RPKI delegated to the test environment. So you have that capability. And that's something that ARIN has to pretty much supply. It's not something that you can get from a third party. We believe in training for RPKI using people who are using our hosted service because that's what the vast majority of people are going to be doing. Someone who is building their own RPKI CA, we're not sure if it's ARIN's job for us to train you, how to build your own CA. If you're going to build your own CA, we want you to go become an expert before you start shooting yourself in the foot. So does that answer the question?
Ruediger Volk: Well, okay, completely agreed on that, but you need to provide the environment where the interaction of the systems can be tested and trained.
John Curran: And we did that.
Ruediger Volk: Thanks. Other question falling back to your IETF activities. Andy, you are author of the policy qualifier draft ‑‑
Andy Newton: Yes.
Ruediger Volk: ‑‑ which is moving forward? I wonder whether that ‑‑ well, okay, getting that draft finalized and turned into standard, whether that is expected to be a reason for you to drop or modify the relying party agreement stuff.
Andy Newton: I'll let John answer that, too.
John Curran: So the relying party agreement, what aspect of it don't you like?
Ruediger Volk: Well, I don't like ‑‑ I don't like the result of, well, okay, for the ARIN members and resource holders the benefit of getting certificates and doing ROAs is very limited if the relying parties have to jump through extra hoops to get actually access to validating the certificates.
John Curran: You're right. They have to supply their email address and click okay.
Ruediger Volk: Okay. Kind of, kind of, kind of. And, yes, next week I will be giving the presentation and I will have to ask people to exit because I will be showing some validated RPKI information that is under the relying party agreement.
John Curran: Actually we changed it to allow that, as I pointed to people. So you can use that for educational purposes.
Ruediger Volk: Okay.
Scott Leibrand: A question from a remote participant, Kevin Otte: To the engineering points, how many of these tools can have their sources be freely available so engineering efforts can be aided by the community at large?
John Curran: At this time ARIN doesn't run the registry with open source tools. That's an interesting approach. And if people want that, we definitely need to discuss that. Because it's a very ‑‑ much like all the RIRs using one engineering philosophy, it's a new requirement that we haven't started going down.
Andy Newton: I will add there are ‑‑ if you go to projects.arin.net, we have some open source software out there that we have written, but the registry back end is not open source. Yes, Owen.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. It is lovely that you have that wonderful page you showed us just a few minutes ago, John, in response to Heather's question. It is not so lovely that that page, as near as I can tell, is not conveniently linked from any of the likely pages that people know about, such as the ACSP page, et cetera, in order to know that it even existed until you showed it to us at this meeting.
John Curran: Okay. Excellent point. We announced it a couple of times and we covered it at the last meeting, but we will fix that.
Unidentified Audience Member at 39 minutes, 37 seconds: If you go to Service's page, it's on the right‑hand side.
John Curran: It is right there on the right‑hand side. Any final questions for Andy?
Heather Schiller: I'm back. Heather Schiller. I'm still with Google Fiber. Kind of going back to what Kevin brought up about the security auditing, like really? You know? So you asked for all of the sensitive information about companies' networks and their business and their kind of future forecasts, and we know it's under NDA so we think it's safe, but then you're saying your systems aren't getting audited.
John Curran: Our systems are getting audited. Kevin asked about the logins for users to our ARIN Online, which some people want username and password, some want two‑factor authentication. It's a customer service question. We do an operational audit. It includes a security audit.
Heather Schiller: I'm pretty sure that's not what he's saying.
John Curran: Kevin?
Kevin Blumberg: The two‑factor was the start. I was actually asking if you perform penetration and best practice security testing of your external interfaces, as well as internal, but predominantly external, if a third‑party actually tests your systems and makes suggestions.
John Curran: I will check the operations audit includes security. I don't know if it includes pen tests. I don't think it includes pen test.
Kevin Blumberg: Thank you.
John Curran: But it is a security audit.
Heather Schiller: That's not reassuring. I mean, when you think about the businesses that all of these companies are providing you and how lucrative that is to other companies to obtain, it's sort of like saying, oh, we have it, come get it. That's not good. So please work on that.
John Curran: Okay.
Come on back. Go ahead, Sandra.
Sandy Murphy: Sandy Murphy, SPARTA. So I was interested by your response to Ruediger about the relying party agreement. You had to have anticipated that. The troubling part of the relying party agreement is the part that says: You shall not use, copy, link to, rebroadcast, or disclose the services or any part thereof or any of its related content. Which would seem to disallow such things as someone at an exchange point having a cache that the members could use.
But then there's this caveat, as long as ‑‑ you may make available to any third‑party the information made available as long as such use and disclosure is solely for informational purposes; namely, reporting educational summary or statistical purposes. I can't imagine any use of the information that is not for informational purposes. Is that a get out of jail free card?
John Curran: No. I'll be very clear. So as I told Ruediger, that is a get out of jail free card for people doing reports. People doing presentations at NANOG, doing summaries, people writing papers. If you want to scan the RPKI tree and do a wonderful informational report, that's a great thing. And we try to make sure that any possible analysis study, reporting research would not be hindered, but it's pretty clear that it can't be used as an operational tool. You can't take the information and build, example, a cache and provide it to someone who is going to use it for their routing unless they sign off on it.
Now, we actually have had a couple parties approach us and say that's exactly what we want to do. We want to run a cache. And I'm happy to turn around and say you can do that. I'll give you a copy of that that waives the requirement as long as you accept the responsibility of your users using the cache. That's it.
Sandy Murphy: Okay. I cannot predict how much people will be willing to take on that risk. But ‑‑
John Curran: You're saying ARIN should take on the risk even though we don't know the users?
Sandy Murphy: No, I said I can't predict how many people would be willing to take on that risk. And it's a true statement. And I doubt you would disagree with it. But I believe that what you've just characterized does limit some of the architectural possibilities like the running a cache that I said.
John Curran: Could you explain how? If a cache operator is willing to take on that responsibility of running a cache.
Sandy Murphy: That's a big if. I said I couldn't be able to tell you how many would be willing to do it.
John Curran: But it affects business models of people who want to run caches without accepting the responsibility for the caches.
Sandy Murphy: I do know of people who have been providing interesting looking‑glass sort of information on a per‑prefix or per‑AS basis and including in their presentation of that material whether or not the material had been certified and had to remove those sorts of things for anything in the ARIN region because they thought that it conflicted.
There's a lot of uncertainty in the community about this.
John Curran: If you see someone who is removing looking glass or uptime reporting, you should point them to that first phrase, because those are people looking at ‑‑
Sandy Murphy: The informational ‑‑
John Curran: Yeah. For publishing information allowing for redistribution of the information for informational educational purposes. There should be no one running a looking glass or status monitor or an uptime monitor who doesn't have the information from the ARIN region. They probably are looking at a prior version of the agreement. We fixed it once it was discussed at the SIDR working group.
Sandy Murphy: Okay.
Ruediger Volk: Once more. I lost one small question in my previous run. When you report that you are doing ERX support for RPKI with APNIC, that is supposed to be essentially kind of figuring out how transfers inter-region will work in RPKI?
Andy Newton: So the ERX work involved a lot of technical work in the back-end to enable signing of ERX space. We're going to start talking with APNIC next month about actually initiating the up/down interchange with them so we can actually start assigning space of ARIN customers that are in their space and of APNIC customers that are in our space. As far as transfers go, it doesn't specifically address that.
John Curran: Thank you. I'm going to close the mics so we don't run indefinitely. R.S.
Rob Seastrom: Lovely I have the last question. I don't want to be accused of piling on here, so please don't take this personally, but I'm really disappointed at the wholesale omission of one particular section from this slide deck. And I know that we can do better, and next time around I really would appreciate it if we get an update that mentions the situation with the sorted fowl such as geese, ducks, et cetera.
John Curran: Let's go break. And we're going to pick up Communications and Member Services up after the break because we are running about 30 minutes late. Folks, you had a half‑hour break. That was in the other universe. You're in this universe now. You have a 15‑minute break. Please be back promptly in 15 minutes. That means I will see you all here at 11:25.
(Break taken at 11:12 p.m.)
John Curran: We're going to get started. Communications and Member Services, Susan Hamlin.
ARIN Updates: Communications and Member Services
Susan Hamlin: I'm going to take a leap of faith all in the room or remotely read every ARIN Announce message that comes your way or you look at the home page every day and you see all of the activities that ARIN's doing. So what I want to do is talk about participation. And we're going to have a little speed dating here, one‑sided, because I'm going to ask all the questions.
So what I would like you to do, please ‑‑ it's not a vote; we don't have to wait for the tabulators ‑‑ I'd just like you to quickly raise your hand if you have done one of the following: If you're subscribed to arin-announce. Just a quick up and down. If you subscribe to the Public Policy Mailing List. If you subscribe to tech-discuss. Okay. Raise your hand.
Have you ever submitted a candidate statement of support this year or in past years? Have you voted in an ARIN election? Have you submitted a suggestion to ARIN through the ACSP? Have you commented on a Community Consultation ever? And there's one going on now about the suggestions. Have you submitted a policy proposal?
Have you attended an ARIN on the Road or Outreach event anywhere? Have you attended an Internet governance meeting? Have you talked to your state regional or national government about the need for multi‑stakeholder approach to Internet governance? Two hands, awesome.
Have you posted on the IPv6 wiki? Have you tweeted @teamarin or #arin32? Have you liked us on Facebook? Have you followed ARIN on LinkedIn? Okay. So if you've raised your hand to one or more, please put your hand up now and keep it up. Look around. This is what participation means. Okay. Thank you all.
Susan Hamlin: Now, the other part of this is currently we have about 4500 members. These are organizations who automatically become a member because they receive a direct allocation of resources from ARIN.
We would like to see more of those 4500 involved. So if you have found any of these methods of participation ARIN useful, share the word with your colleagues when you go back home or other meetings where there are folks that need to know about ARIN. Just a few things looking ahead. We recently released some new videos, instructions on how to interact with ARIN. And these are about managing your database records. You can find them online. There's a link off the home page. We'll be doing more of these interactive videos. I think coming up is one on transfers, and then we'll be talking about billing interfaces.
We also are currently using the new voting interface. I encourage you all again to vote if you're a DMR. And starting next year we will have a new meeting registration system.
So the other areas I want to talk about are participation from you. Communication and Member Services is a service department. We service the other internal departments at ARIN helping to get the word out about their activities, how to interact with ARIN. We also have an external face. We publish on the website information. We talk about Internet governance. We work in coordination with the other RIRs.
We get very little feedback from the community, and we'd like to know that we are giving you basically what you need. So coming soon, before the end of the year, we're going to set up a new Mailing List, and you'll hear about it. Looking for people who want to subscribe. And from time to time we may throw out a question asking for input; for instance, where we should take ARIN on the Road next year.
We currently have a survey about ARIN meetings. And then also we're interested in the type, method, and frequency of communications you hear from us. So if you're interested in participating when we announce the Mailing List, please sign up.
Again, a quick thank to our sponsors. And then we hope to see you soon. Our next ARIN meeting will be a public consultation at NANOG in February, followed by an ARIN Public Policy and Members Meeting in Chicago in April.
I'd like to remind everybody about the Fellowship Program. If you've never had colleagues that attended a meeting, encourage them to ask. Last but not least, I'd like to introduce the members of the CMSD team. We're all here except Erin on your bottom right. I'd like Dé to stand up, our meeting planner, and ask that you all give CMSD a round of applause for this meeting and all the other activities.
Susan Hamlin: Okay. That's it. Any questions?
John Curran: Any questions for Susan? Thank you, Susan.
Next up we're going to have the ARIN Board of Trustees Chairman ‑‑ there's a slight switch; I see panic in everyone's eyes ‑‑ come up and give the Board of Trustees report.
ARIN Board of Trustees Report
Vint Cerf: Thank you very much for this. I have a scheduled ‑‑ I'm practicing my British. I have a scheduled call at noon precisely that I can't avoid to participate in. So let me start out. The Board is taking ‑‑ this is since just ARIN 31, so you're just getting a snapshot. First of all, we made sure that the investment policy controls included two officers of the company for any kind of transactions that take place. This is so we can avoid potential hazard of someone doing something inappropriate with regard to your funds.
The second thing, as you know, is that the fee structure has been evolved, partly to take into account the v4 runout and the presence of what we hope to be a large fraction of IPv6 users, so a review panel has been set up in order to advise us and provide feedback. And, finally, we made decision at the Board to provide additional Internet Governance Forum funding. There were two tranches of support for IGF. One came from our position as an NRO member. So there was a joint contribution from the NRO. And then in addition to that, we and I think perhaps some of the other RIRs also made separate contributions in order to help the IGF occur. This year there was a real serious problem with regard to funding.
And although many of the people in the community, including ARIN, responded well, I hope that by the time next year that the IGF comes along we have a much more, let's say, stable way of assuring that the secretariat is funded and that other costs are properly covered. With regard to policies, there are two: one fairly minor but important, and the other one more substantive. The 2012‑2 Subsequent Allocations Utilization computation was adopted, and finally it was noticed under the Section 8.2 that we had neglected to include reorganization as a possible reason for transfers to occur.
And I have control over the next slide. There we are. The other things that we've been involved in, as you see listed here, one has been a discussion about our relationship with NANOG, which, as you know, has been fairly close. We've even provided support to them. The question is how closely should we be linked to them because of purposes of meetings. John's already laid out a little bit the consideration there.
The second thing, and something that I am very much interested in, is increasing our accountability, not only to the Board, but the rest of the organization, to you, as members of our organization and community participants. So I am looking for your ideas, either here on the spot or certainly by email or even in the suggestion box, which I now pay a great deal of attention to about how we can supply you with improved accountability.
We will continue the Board support's promotion of IPv6. The one thing which did come up in the last few days for me, which was a surprise, is that some of the ISPs are saying we don't have trained staff to implement and operate IPv6. As opposed to no one's asking for it. Which is the earlier claim for not doing anything.
This is sort of credible, I guess. We can imagine having a bunch of people who are doing IPv4 and have done it for many years and don't have adequate knowledge for an installation provisioning and configuring of IPv6. So there might be an opportunity for us to help. I don't know how much of our resource we would want to put into this, but doing MOOCs for training purposes to help people to understand O&M for IPv6 might actually be a way of responding, assuming that's really the problem.
We've also been very interested and I've personally been interested as Chairman to assess the effectiveness of the ARIN Board and to encourage the Advisory Council to consider whether it could make improvements in the way it operates. And finally and most critically, during this period of potential change in turmoil with regard to Internet governance, I think we need to be very much involved in that discussion and that debate, providing our voices and our ideas and I hope yours as well. I think that's all I have. So if you have questions for me, I'm happy to answer them now or await your email.
John Curran: Thank you.
Vint Cerf: Hearing none says the deaf guy.
John Curran: Now we'll pick up with the Advisory Council report followed by the Financial Report and Fee Structure Review Committee. Okay. You're here. Thank you.
ARIN Advisory Council Report
John Sweeting: John Sweeting, chair of the Advisory Council. Let's get right into this. Jennifer? Thank you.
Here's your ‑‑ the Advisory Council is made up of 15 elected members. Three‑year terms. So that would mean five come up for open election each year. 2013 Advisory Council election. So as I said three‑year terms, five members up for re‑election each year. Terms ending this year: Chris Grundemann, Scott Leibrand, Milton Mueller, Cathy Aronson, Owen DeLong.
Top five vote receivers will serve the three‑year position. There's seven nominated individuals for the five positions. There were eight, but due to Chris Grundemann landing a new position in life, he decided to withdraw from the race. And I'd like to at this time recognize Chris for his three years of dedicated service and also congratulate him on his new position with the Internet Society.
John Sweeting: Thanks, Chris. The AC role and the PDP. Proposals are submitted. The AC takes ‑‑ at this point with the new PDP, we work with the author on the proposal to turn them into Draft Policies by ensuring that there's a valid problem statement. Once we move it to Draft Policy, we work with the community through PPML, PPMs, and PPCs.
Once we feel that we have a Draft Policy that we would recommend to the Board for adoption, we move it to a Recommended Draft Policy so that it can be presented at a Public Policy Consultation and take that feedback there to tweak it and move it to Last Call. Unless we get feedback that we should do something different. This year we've had nine new proposals, two that came over from 2012. One was remanded and closed. Remanded means we sent it back to the author for further clarification. And in this case what happened was a new proposal was submitted in the place of the one that was remanded, with a much clearer problem statement.
And one was implemented as an editorial update, which was the Proposal-186 that Vint referred to. And seven were moved to Draft Policies at the Draft Policy stage. Three were abandoned, two were moved to Recommended Draft Policy, one was abandoned, one was discussed this week. And we also discussed two drafts this week.
Other things that the Advisory Council participates in is the Fellowship Program. Each meeting there's three Fellows, one selected from each of the major regions within ARIN, Canada, North America, and the Caribbean. So we appoint a mentor to that. We also ‑‑ at this particular meeting, I think we had six mentors with six Fellows because we supported fellowships that were in conjunction with NANOG.
We also participate in the Outreach program. Most of the focus on that has been IPv6 education, but we do get a lot of IPv4 transfer questions. And a lot of operational questions also come up there, and that's where the Advisory Council members that participate there really help out a lot.
We also have two AC members that serve on the nomination committee each year, and then we will participate in just about anything else that the ARIN staff asks us to help them with. Okay. That's all I have. So thank you, and please remember to vote. That's the theme of this. Vote, vote, vote.
John Curran: Thank you. Any questions for John? No. Next up, treasurer Paul Andersen.
John Sweeting: Stage left.
Darlene Thompson: This isn't a question but a comment as being a Fellow here. I'm Darlene Thompson. I'm the secretariat for the North American RALO. I'm highly involved in ICANN issues. And I must say that your Fellowship Program is way better than anything I've ever seen. The fact that you have mentors that will follow you around and actually tell you what's happening and clarify things for you ‑‑ being on the list does not cut it, because I was as confused as I was when I started on the list as I was when I came here.
So being at this meeting actually clarifies so many things, and now I feel like I can actually participate whereas before I did not feel like I could participate. So your Fellowship Program is excellent. And please continue with the way that you're doing it. Thank you very much.
John Sweeting: Thank you very much for the welcomed input.
ARIN Financial Report
Paul Andersen: I know we're getting late in the day. I'll try to keep it short. The FinCom has been actually very busy since we last met. Obviously with the passing of Bob, we had to ‑‑ we've been working very closely with John, Nate, and the entire Financial Services team to just get things back on track.
One of the things was Val has graciously accepted to move into the role of Director of Financial Services, and I'd like to thank her personally for all her efforts in making this transition as smooth as possible. It was also just busy in general. We, of course, have been working with staff on the new fee schedule. That is now well into deployment. Seems to be going very smoothly.
The FinCom has also been working quite closely with staff to just reevaluate a lot of the financial, especially in regard to the investments, just the controls and the methods and processes on how we've been doing that. We've met with our financial advisor actually at the last NANOG since it was a convenient place. And the FinCom is very happy with how that is progressing.
As for how we're doing numbers‑wise, things are reasonably on track. Registration revenues you can see through the last quarter came in just a little bit over ten million. Distribution still heavily on our ISP registrations, are the bulk of that. Expenses are we're just over 9.6 million. So we are still to the good, about 849,000. Our investments continue to do very well. We watch them very closely. We're not I would say at all aggressive with that. We've still had very good returns. So we're right now looking at about 2.4 million net to the reserve as of the last quarter.
And I guess I've now fallen into you think ‑‑ I know, I know. Do you have to press something for me to get back? How many engineers does it take to run a slide thing.
Vint Cerf: Depends on whether they're Canadian or not.
Paul Andersen: At least our government's open for business.
Paul Andersen: Salaries are a little bit over. There's been some additional benefits that were capitalized and some new hires that we potentially have had. Communication you'll actually see is falling a bit behind. That's more from a capital realization ‑‑ sorry, recognition mainly due to some delays in the DRP co‑lo that was budgeted for this year. There's been delays in the Postgres implementation, which is kind of weird that software is actually also down. It's going to go up as we start to recognize some of the development expenses to putting in Postgres and replacing Oracle, which of course will then again lower licensing costs, so that's going to dip up and down a bit.
We are significantly under, as you can see, in the professional fees and outreach. We do plan for some of that to catch up by the end of the year and all that. We're just a bit behind on the RSD audit. Some survey consultants we're bringing in. Our PR budget is also down.
Credit card expenses have gone up. Our fees to ‑‑ as you know, the credit card companies like to take a small cut, and that has increased. And also we've had a bit of an increase in write‑offs, which has been quite flat for the last few years. Our bad debt expense has been strangely quite flat, but there has been an increase. We're not entirely sure what, so we'll keep a close eye on that. We've had less than expected legal fees so far this year, but we do expect that to catch up.
Generally, though, the rest of the expenses are kind of coming in line with the exception of travel. Staff travel is a little bit down through Q3, but, again, that's expected to catch up. We're running about ‑‑ we ran about 900,000 below budget this year, but we expect a lot of that to catch up again just as some recognitions tick in in Q4. Although we do expect to be about 400,000 under for the year.
Reserve‑wise, at the end of the last quarter we had about 22 million in our reserves. As of September 24th this year that had actually increased another 1.4 million to 23 million. As you know, the markets have been reasonably volatile lately. But we are, of course, watching and we continue to look for ways to potentially level off the reserves a bit. I think we stated at previous meetings we know that we've increased it significantly, and we're not trying to necessarily build that up. And I think that ‑‑ oh, yes. We filed our 990 Form in mid‑August. And with that I'll take any questions. You finally thought of your comeback.
Vint Cerf: No, no, there's no comeback to that. That's a killer. I just wanted to mention that we also had the strong audit report. Organization is in excellent condition. You see the finances here. But the audit reporter said that ‑‑ the auditing organization confirmed that we are operating excellently. There are no issues, there were no complaints, no corrections, no changes, or anything. So you can congratulate the team at ARIN for doing that.
Paul Andersen: First that.
Paul Andersen: For those that aren't aware, the Board of the six Trustees are split with three of us sitting on the FinCom and then the audit committee is the other, so we try and keep a bit of that separation. So one last thank you again to Nate, John, and of course Val and the entire Finance team for their efforts. I know it's been a very difficult and busy last few months, and I really do appreciate their efforts. So if you could just give them one more thank you, I'd appreciate it.
John Curran: Okay. We're moving into the last presentation, which, because of the reordering, is now me, which wasn't planned, Fee Structure Review Panel Status Report.
ARIN Fee Structure Review Report
John Curran: So ARIN did a pretty significant fee change this year. It was something we talked about at the end of last year, the beginning of this year. We rolled out this summer part of the fee calculator you saw. We normalized and simplified the fees. They went down for the majority of people. Did go up for a few.
And in the process of this, a lot of people came out and said, well, yeah, you're making minor tweaks to the fees, but how about wholesale changes? How about innovative new approaches to the problem? We also noticed our fees do have policy implications. Our fees have tables that are tied to things like allocations and size of allocations, which means you can have a side effect in the fees that effectively makes implications for resource holders.
For example, the smallest line on the fee table has a representation to the smallest address block. So there is a policy implication. We decided that we really needed to look at rather than incremental changes, as staff and the FinCom recommend, we really needed a good discussion of is this the right approach to fees altogether and that that should be done with the community.
The FinCom actually convened a Fee Structure Review Panel. We asked for volunteers in April and May. We got 34 volunteers from the community. We narrowed it down to six. And so that's the three FinCom members plus the three Fee Structure Review Panel Members, make a total of nine.
So Fee Structure Review Panel, the goal is to consider various long‑term fee structures raised in the community discussion of this topic and to summarize their pros and cons in a balanced report. It is not a group to make a recommendation. It's to produce a discussion document so that we can have a discussion with the rest of the community and make sure we're all working on the same statement of these ideas of these alternatives and what they actually mean financially.
The report is to be provided to the community as a common basis of discussion for potential changes. Specifically, not chartered to make a recommendation. So it's going to assess a whole list of alternatives. Let's see. What do we have? We did the call for panelists. We selected them at the FinCom. We appointed them. Here's the list of them. The Board members of the FinCom: Paul, Aaron Hughes, Bill Woodcock, myself. And then on the Panel, the at‑large members: Tim St. Pierre, Steve Feldman, Brandon Ross, Dan Alexander, Michael Sinatra.
So the initial document draft is done, and it includes the following fee structure proposals: The current structure, of course, because you want to have a baseline, and then one that extends the IPv4 fee categories because our current categories end at XX large but people have even larger holdings, so that's one linear fee categories proposal which would not only extend them but extend them all the way up indefinitely.
Realigning v4 and v6 to provide larger v6 allocations for each fee category.
An algorithmic one: Type in your total v6 and v4 holdings, hit the button, and, bing, out comes a number and that's what you pay. We're very close to a semi‑log algorithm. But we have step functions right now on the fee table. This actually would eliminate the fee schedule. Membership based. You're all equal. You're all members. Come on in. Give us money. Your holdings are secondary. We're all doing a mission together.
Transaction based. Sort of the opposite. If we don't hear from you, you're not paying much; when we do hear from you, get out your wallet and we'll tell you what that particular request costs. So we're busy looking at these, and they're going to flesh them out and actually have details for each one. For each one there's a description. And then the merits and the potential issues with it. And we're doing a summary at the front of the document, and then the full fee schedules will all be appendixes attached to the end.
So we're still working. It's a bit of work. Realistic completion is ‑‑ we wanted to have it for this meeting, and we don't. But it's going to be finished before year‑end. We're going to use it as supporting material to a community consultation. That's where we send it out and ask you all to comment on it. So that's the goal. Consultation will run up to and including ARIN 33 in the spring of 2014.
The finance committee will consider everything after that, after that meeting, and try to figure out do we need to look at some sort of change to the fee schedule again.
And, as always, if we end up going in the direction of a new fee schedule with specific changes, those would be sent out for specific approval by the community and their feedback. So we're starting a fairly long process here. But the first part of it is to get the document done and get it out in January for all of you to look at.
The Board authorized us continuing the Fee Structure Review Panel. It was supposed to report at this meeting, and clearly we need a little more time. We should be able to get it done by year‑end, and we're in good shape. Update on review panel. Questions? If there are no other questions –
Kevin Blumberg: I gotta stop standing over here. Kevin Blumberg, The Wire, ARIN AC. Very quick question. Are you expecting in the report that's produced to give examples of each of them from a ‑‑ with the metrics as if in 2012 this is what the current fee schedule looked like, all the other ones would have looked like this in 2013, that sort of idea?
John Curran: What we're hoping to do is do for 2015, okay, to do what each fee schedule would look like. And they're all ‑‑ they all end after the same number. That's the goal. None of these are a revenue change, it's just a question of allocation. And we're also going to try to do a distribution chart. So a histogram of 0 through 45,000 lines that show where the ‑‑ some of them have histograms that are a nice curve if you saw it. Some are flat. Some are fuzzy. So we'll try to show how it's allocated across all 4500 members as well.
Kevin Blumberg: That's awesome. I'm so used to seeing hashtags with these kinds of things, so looking forward to it.
John Curran: That's it. I'm going to move, if there's nothing else, into Open Microphone. Okay.
John Curran: Welcome to Open Microphone. The microphones are open to talk about any topic before the organization. We try not to spend too long at this because it's between us and ending the meeting. But the microphones are open.
Scott Leibrand: I have a very prompt remote participant, Gary Buhrmaster, speaking for himself: As a follow‑up to John Curran's statement in a previous session on calling content providers out on not providing IPv6 access, I would like to call ARIN on not contracting with the remote livestream provider whose website supports IPv6. Thank you.
John Curran: Thank you. We are actually pretty aggressive with our contracting. We've had vendors who have looked at me and said: I have to support what? Why? Who?
We are pretty insistent on v6. But in this case it may be a carry‑over from how the meeting's arranged. In any case, we'll pick that up and definitely get on top of it.
Okay. Rear microphone.
Jason Schiller: YouTube supports IPv6 and now streams ARIN conferences.
John Curran: Problem solved, but we might not have the right pointers to that and we'll have to work on that. Thanks. Louie?
Louie Lee: I wonder if people want to talk about whether we should have an April ARIN meeting in 2015, is it? We're only having ‑‑ we're planning on only the October meeting?
John Curran: We do not ‑‑
Louie Lee: Other than the Public Consultation blocks.
John Curran: We have a Public Consultation right now. People who have a view on what our meeting schedule should be for 2015, there is a public survey out there right now that you should go fill. You should tell us how many meetings we're going to have and where we should have them and whether they should be adjacent to NANOG, whether they should be standalone, should we be adjacent to something other than NANOG. We could be adjacent to the United Nations or DEFCON or something. We need your input.
John Curran: Rear of the room.
Chris Grundemann: Chris Grundemann. On that same topic ‑‑
John Curran: UN or DEFCON?
Chris Grundemann: We're talking about when to have the meetings and how often to have them and alongside what. Maybe this is step two, but the meeting format could probably be revisited as well. I note that in every meeting I've ever been to, we've stopped conversation on at least one policy at the end of a policy block. And so perhaps looking into that and having more active working sessions at meetings in person in the format change would be beneficial.
John Curran: Happy to have it. Definitely put that into the comments. People who want us to change a structure. Because we now have the PPCs, that provides input, but they're not necessarily the same type of input. We don't have reports, for example. So definitely need feedback on what you folks want. Okay. Rear mic.
Jason Schiller: Jason Schiller, Google. Following up on Chris Grundemann's comments. I also support having more working group time to work on policy. I think that would be good in the meetings. And I think one thing that this community sorely misses is what we used to do on Sundays, which was, Einar, if you could stand up, you've been doing a fantastic job at this ‑‑
Jason Schiller: ‑‑ he always put together a presentation for what the PDP is. I think that's valuable to new members ‑‑ to new attendees, but I think it's also valuable to the people that have been doing this for many years, because the PDP has changed. It is changing. And I think a lot of people don't actually know what the specific rules of the PDP are. So I think having that would be very helpful.
The other thing that we did on that Sunday was we had an Open Mic. And that Open Mic was different than the one that we're having now, because it wasn't at the tail end of a session, it wasn't cut short, and it was one that people specifically showed up to to attend. So I think that would also be helpful.
John Curran: And I don't mean to cut you short. I will be here as long as you want to be, Jason. So you can keep going. I do have one question about the working, if you can get up there. So you said more working time. And it's kind of interesting, because I've got the AC and I want to respect them as well. Do you mean time in a meeting room with the AC to work or time for people to go off on their own or wordsmithing in a big group? Because I'm trying to figure out what you mean. Do you mean after the proposal's discussed or before, and are you actually working on proposal text or not?
Jason Schiller: Yes, I mean working on proposal text.
John Curran: With the shepherds?
Jason Schiller: With or without the shepherds, yes. I think it's valuable to get some people together in a room and hammer out some text, whether that is revisiting a policy that we discussed here that didn't fly because there was some issues that maybe 20, 30 minutes sitting down we can address, or if that's because something came up like, oh, my gosh, slow start doesn't work in a transfer market because you can't get addresses from your upstream ISP.
Maybe three or four of us can sit down and write out some text. And whether that's just people from the community putting together a proposal and sending it out to the AC or whether that's actually grabbing a shepherd and getting them to help, could be either.
John Curran: Would it be helpful if there were ‑‑ after discussions of policy proposals, if there were slots with rooms so people could get together, so if the shepherd wanted to say everyone who wants to try to work on this after come here? Or if you had an independent idea you could say: I'm going to be in the slot tomorrow in the second room if you want to work on address space for, you know, whatever?
Jason Schiller: Yeah, I think having a time slot in the room would be helpful but it's also a time when you're not competing with something else that people want to attend.
John Curran: Challenging. Can you try to write some of this up when you do your survey?
Jason Schiller: Yeah, I'll do the survey again and put some notes about this in there.
John Curran: Okay.
Scott Leibrand: I have a remote question from Jesse Geddis: When will we be able to see the other fee proposals? I understand there are four including leaving it the same. It sounded like they were going to wait until they had summaries of their financial impact.
John Curran: You're going to see the whole document at once. There's actually six or seven of them. And it will all ‑‑ the document with the summaries and all the proposals attached will come out when the review panel's done. Back rear.
Bill Darte: So in the early days of policy development, we almost rigorously didn't get any involvement of staff. And then in recent times we've had the Policy Implementation and Experience Report, and that's been extremely valuable to the AC, speaking for myself.
And ‑‑ but I think it could go even further. I understand that staff is the only group that can't propose policy or whatever. But I think to the maximum extent possible, in the Experience and Policy Development Process or something adjunct to that in communication with the Advisory Council, specifics of things that they might even suggest would make good policy considerations would be valuable to us. And just the more the better, as far as I'm concerned.
John Curran: Okay. There is a ‑‑ there's a philosophical reason for that separation. And such things aren't generally set aside lightly. But I hear what you're saying. I think there's ways of approaching that. One of my questions would be if the AC asks for staff help, and so it's not staff submitting a policy proposal on their own, I could see the AC asking for suggestions on text or help with text. Is that what you're suggesting, or is it something else?
Bill Darte: Speaking for myself, on the Advisory Council, I would want ‑‑ I think that's what I just did and said, you know, we always welcome anything that goes beyond just some general, you know, this looks like it's a problem.
John Curran: Okay. Got it. Center front.
Scott Leibrand: Scott Leibrand, ARIN Advisory Council, speaking only for myself. I am interested in the community's feedback on the question of whether the Advisory Council is the right size, is 15 the correct number of Advisory Council members. This is something that I have been discussing and will be discussing with AC members and others, but I think the biggest gap right here is from non‑AC members who might have an opinion on the subject. So if anyone who is not on the AC has an opinion on it, I'd love to hear it either now at the mic or catch me afterward. Thank you.
John Curran: Excellent. And center front mic.
David Farmer: David Farmer, University of Minnesota, ARIN AC. To the question that Bill was bringing up and that discussion, a better understanding ‑‑ in many situations when we're working with policy, a better understanding of operational practice can become vital. Because the policy I've been working on is woven in completely about current operational practice. And sometimes I feel like I'm pulling teeth trying to get information. So that ‑‑ any way to fix that flow would be appreciated.
John Curran: Right. We've had some discussions about that. And it would be helpful. Recognize, as people realize, there's a lot of different things that are networks out there and a lot of different end users, and they come at us from a lot of different directions and a lot of them look different. And so I'm going to say something, and I'm not channelling another AC member, but the process of doing needs assessment is fraught with challenges. And the more detailed and accurate you try to make a needs assessment, the higher the level of effort and the more process you need.
So I'm happy to keep going, but whatever we tell you will not accommodate what happens in the next three months with the next set of requests that are using different technology or assigning it differently.
David Farmer: That was the point I was trying to get at. Is the ‑‑ on one side we might have some conceptualization of it, but we don't get to see inside the sausage factory, or whatever it is, whatever metaphor you want to use. So we don't know what all the pieces are. And as an Advisory Council member, I don't want to make it any worse, at least accidentally or unknowingly make it worse.
John Curran: And what that says is that you need to focus on policy that you think makes a difference.
David Farmer: Yes.
John Curran: And all I can do is ‑‑ I'm happy to try to explain things. But when you start working in generalizations, the number of use cases could go 30 pages. So it's very hard ‑‑ and the other problem we have, just to be clear, when the AC uses a phrase or something, sometimes it's not until we look at that phrase that I can tell you how it applies.
David Farmer: Exactly.
John Curran: What will help? Not omnibus simplification of the NRPM, but incremental simplification of the NRPM would probably be a prudent idea.
David Farmer: Uh‑huh. Yep.
John Curran: Thank you. Okay. Microphones remain open. We have another ‑‑ actually we're negative ten. I was going to say we have another three hours. We're negative ten minutes. There's lunch ‑‑ we actually don't have lunch; you're kind of on your own for lunch. But there's probably people waiting for people to meet for lunch that are late already. So I'm going to close the microphones. Yes, center rear.
Mike Joseph: Mike Joseph, Google. When you produce cost estimates to complete certain projects that the community has asked for, would it be possible to get a breakdown of why the costs end up at the numbers that they do? It seems that there's been a disconnect historically. When we ask for something, for example, you know, multiple API keys or something like that and the cost comes back at 1.4 million, it would be interesting to know why.
John Curran: So I'm going to say I'll bring that to the Board and talk about it. Right now we're beginning to spend more time doing cost estimates than engineering. So the cost estimates have to include the estimates of doing all the other cost estimates. And if you want cleaner breakdowns, then we have to put more effort in. We only have a very small development staff, and that's what you're seeking cost estimates of.
Mike Joseph: Presumably you did the estimate once because you produced a total.
John Curran: Yes. We do an estimate that includes ‑‑
Mike Joseph: And presumably you produced a total by summing some components. Can you just share ‑‑
John Curran: You got it. And we can clean that up and begin looking at it, but the question is what use is that? We provided the cost estimates so you can understand the relative size of development efforts, not so that you can check our development costs.
So if you can give me a goal, how you're going to use those, and it's productive, then I'm all for it.
Mike Joseph: I think I want to understand how our dollars are being spent and why certain costs seem higher than they should be. And if those costs are legitimately that high, then I think that's something the community needs to know. But if it seems there are inefficiencies in ARIN operations, I think that's something that the people who fund ARIN have a very vested interest in understanding as well.
John Curran: Thank you.
Kevin Blumberg: Kevin Blumberg. Just in relation to what Mike Joseph said, on a $1 million line item, I'd like to know that 985,000 went to culling the herd because that was needed and then it was $15 to actually implement it. Where we can hit now all these new features after the fact. So, again, the back-office, legacy systems that need to be migrated, that's the main thing for me, is to actually do the work on our systems today will cost ten grand ‑‑ yeah.
John Curran: Yes, Paul.
Paul Andersen: To go to Mike's and your point, I think we've heard a lot of feedback. There's some concerns in this area. I've spoken with Nate, the COO, a bit, and I think that we can do a bit better job maybe explaining some communication. So give us a little bit to come back to the community with something on that.
John Curran: Okay.
Kevin Blumberg: See you at the next ARIN meeting.
Paul Andersen: See you there, bright and early.
John Curran: Closing the mics shortly. The mics are closing down. Okay, that's the end of the Open Microphone session. Thank you everyone.
Closing Announcements and Adjournment
John Curran: We are now adjourned. Thank you to coming to the ARIN 32 Phoenix, Arizona, meeting. We're going to ‑‑ I want to thank our sponsors, PhoenixNAP and Gila River Telecommunications.
John Curran: Also our webcast sponsor, Google.
John Curran: I'd like to remind everyone that return your badges. Do we have a badge bucket out front or a table for badges? Here it is. Remember your meeting surveys. Thank you also. If you need a paper copy, you should have it already. You'll be entered to win a Samsung Galaxy Note. Check your bill. You should not have been billed for in‑room wireless connectivity. Thank you for being part of ARIN 32. We're going to see everyone at the consultation in Atlanta, if you go to NANOG. If not, we'll see you at ARIN 33 in Chicago, Illinois. Thank you.
(Meeting concluded at 12:15 p.m.)