ARIN XXVIII Members Meeting Draft Transcript - 14 October 2011
Table of Contents
- Opening and Announcements
- ARIN Updates: Registration Services
- ARIN Updates: Human Resources and Administration
- ARIN Updates: Government Affairs and Public Policy Support
- ARIN Updates: Financial Services
- ARIN Updates: Engineering
- ARIN Updates: Communications and Member Services
- ARIN Advisory Council Report
- ARIN Financial Report
- Financial Cost Model
- ARIN Board of Trustees Report
- Open Microphone
- Closing Announcements and Adjournment
John Curran: Welcome to the ARIN's Members Meeting. This is open to everyone. I'd like to point out we'll have some presentations.
The same rules as always: Be polite at the microphones, state your affiliation, comply with the rules and courtesies in the program.
Vote. If you are a DMR or if you're in an organization that gets ARIN resources so you have a DMR but you're not it, find your DMR and make sure they vote. We need organizations to vote. This is very important. This is how we determine the Board and the AC.
And, rest assured, the Board and the AC do make important decisions for the organization, so it's worth having people that you believe in up here.
Open Community Survey. I already said the ICANN review of the ASO is taking place. If you go to http.www.items.fr/aso.php, you can complete a survey about what you think about the ASO and how it's doing its job.
Thank you for our sponsor. Yes. Everyone clap.
John Curran: People who do not clap will have their network ID removed from the filter list, so clap loudly.
Today's agenda. We'll have ARIN departmental reports, the ARIN Advisory Council report, ARIN financial report, and the ARIN Board of Trustees report. We'll start off with those so we can get ahead.
At the head table we have the Board of Trustees and the Chair of the Advisory Council. So Paul Andersen; Scott Bradner; Vint Cerf; myself; Timothy Denton was here a moment ago, will be right back; Paul Vixie; Bill Woodcock; and AC Chair John Sweeting.
Next up will be Leslie Nobile giving the Registration Services Update.
Leslie Nobile: Quick update from Registration Services. This is our team. On the left we have Cathy, David, and Jon. That's our senior team. And note the change to David's title; he's now principal technical analyst.
And we have our resource analysts, Doreen, Sue, Mike, Lisa, Chad, and Eddie. Let's see. Mike, Lisa, David, and Cathy are all here, so hopefully you've had a chance to speak with them.
Our current focus. Well, it's pretty much the same as it was last time in April. We're working on — with IPv4 depletion and IPv6 uptake, we're working on developing, adapting, and improving processes and procedures, making changes as needed with these quick changes that are happening with our v4 depletion situation.
Policy work. We've got lots of policy work going on. We do staff assessments, lots of new policy implementation and ongoing policy reviews for efficiency.
And we are preparing for an upcoming RSD audit. The ARIN Board thought it would be a good idea for us to be audited to basically ensure that our internal procedures match our external policies, the policies that you all develop.
So we're in the process of preparing for that. We're meeting with them next week, and we'll have a nice long week of work and questions with them.
Fraud and noncompliance work, resource reclamation where appropriate. That's sort of an ongoing thing we do.
And ARIN Online. We continue working with our engineering team and the rest of the ARIN team on, in particular, RSDs working on enhancements, new requirements, and prioritization.
So I'll start with recovered resources. We still do get resources back. We went back to 2005, January 2005 through September 30th, and this is what we have in our various sort of bins.
As far as returned space, that space that is voluntarily returned by a registrant, and we still do get space returned to us, we right now have 461 /16 equivalents in our returned bin — that have been returned to us over the years, excuse me, and 1,618 ASNs that have been returned.
For revocations, those are revoked for non-payment of registration services. We've got 120.93 /16 equivalents that we've revoked, and 4,665 2-byte ASNs.
And then reclaimed space, that's space that we reclaimed for fraud or misappropriation or a business dissolution, and we've reclaimed a little over seven /16 equivalents over the years, the past six years, and 15 ASNs.
Current IPv4 inventory. This shows you the exact details of how much space we have. Our front page just lists our total available inventory. It's updated daily. This shows exactly where it sort of resides.
We've got 5.70 /8 equivalents in our pool of available addresses. We've got 4.33 /16 equivalents in our returned bucket; that's space that's voluntarily returned. .38 /16 equivalents in our revoked bucket right now. And — revoked due to non-payment — and 4.68 /16 equivalents in our held bucket.
And this is space that has been deregistered from Whois for one reason or another but it's still being routed, so we keep it in this bucket, because we don't want to reissue it if we know it's being routed, and we try to get it unrerouted, but not always successful sometimes.
So just in case you don't know, any space that comes back to ARIN, we hold for a six-month periods to clear filters before we put it back into our available pool. So that's always sort of a dynamic pool, it's always changing; there's always space coming in and space going out.
Legacy RSA status hasn't changed much since last time. We've had a little over a thousand requests to sign a Legacy RSA. We've got 527 signed. 147 have been approved but are just sort of sitting there waiting for people to take the final step and come in and sign it.
106 are pending. We're still working back and forth with questions, verifying that they are the accurate person to sign the LRSA. 45 were abandoned; they never came back after repeated requests to — you know, that you still have an open ticket. They just never come back, so we closed those tickets. And 179 were not required or not authorized.
And then at the bottom you can see the total resources and organizations that are covered under Legacy RSA. 177 ASNs; 1,472 v4 blocks totaling 8.24 /8 equivalents; and 527 different Org IDs are covered.
So v4 depletion and v6 uptake. This shows you the number of requests. It goes back through 2010. And, as I mentioned yesterday, we haven't seen much of a change in request rate. It's fairly stable and consistent.
But then you look at what we're allocating and assigning, and that has really dropped. I mentioned that was due — much of it, some of it, was due to the three-month limitation on ISPs since February of 2011.
But our rates, as I said yesterday, have been going up and down, and downward trending in the past couple of years, anyway. So we're issuing less space and we're seeing less of the larger ISPs coming in on a regular basis.
V6 requests. We had a peak when v4 run-out was imminent at IANA. And it's slightly dropped off. But it's still higher than it's been in any years. We are regularly receiving requests for v6, and we are regularly issuing v6 allocations and assignments, and you can see that trend is exactly the same as the request rate, because we pretty much approve everything that comes in in v6 land.
So we look at how many v4 members, subscriber members, ISP subscriber members actually have v6 as well. And not such good rates. But it's improving every day. We've got 3,748 IPv4 ISP subscribers today, and out of that total 66 percent of them do not have an IPv6 allocation. So 34 percent have both IPv4 and IPv6. It goes up about 1 percent every time I do this presentation, so it's fairly slow, but it does go up.
Vint Cerf: It just occurred to me, if we were permitted to do so, to publish a list of the ISPs who have no IPv6?
Leslie Nobile: John, would you like to address that?
John Curran: So that's interesting. The information is out there for someone who wants to get creative, because the Org IDs are common and the records are all public.
I'd actually much prefer some innovative member of the community go do that data mining than ARIN go do that. But obviously if you direct us so, I will do so.
Bill Woodcock: We already have a page of Internet exchange points that don't have v6, so we'd be happy to add a page of ISPs that don't have v6.
John Curran: Thank you, Mr. Woodcock. I presume that's PH- — PCH, you mean.
Bill Woodcock: Yes.
John Curran: So we will get that.
Scott Leibrand: Scott Leibrand, ARIN AC. Can you go back to the bucket slide? My question was where is the Interop block? I would assume it belonged in the returned bucket.
Leslie Nobile: It's in the 5.70 /8s. It was held for a little over six months to clear filters, and when that policy was enacted, we moved it out of —
Scott Leibrand: So these buckets are only the stuff that hasn't been in there long enough to clear, and then everything goes into available after a certain amount of time?
Leslie Nobile: Six months we hold it to clear filters.
Vint Cerf: This is a question out of ignorance. When things are revoked, implicitly — I think you must have answered this question — do we check to see whether it's still being routed?
Leslie Nobile: Absolutely. And we hold it for six months. If it's still being routed, we put it in this held bucket and keep it there until it's not routed.
Sandra Murphy: Sandra Murphy, SPARTA. I had one question about the legacy slide. At the end you made a reference to some people turned out not to be authorized.
And is that you could not establish their authorization, or you had some inkling that these actually were people who were trying to pull something?
Leslie Nobile: Typically it was people who were not authorized who were not the registrant. We didn't ever feel they were trying to pull something. I have to say with LRSA it's typically just been people who have been reassignments, for example, they thought they should sign an LRSA. Or who are new registrants, they transferred the space years ago, but they're not the authorized registrant so we make them go through a transfer. So that's a long process.
But it hasn't been sort of nefarious activity that we can tell.
Sandra Murphy: Thank you.
Leslie Nobile: Martin? Oh, sorry. I totally didn't go that way.
Stan Barber: Stan Barber speaking as Academ Consulting Services, a sole proprietorship. I don't see any reports here related to end users, and I'm wondering where I might find those.
Leslie Nobile: What type of information about end users?
Stan Barber: The same kind of stuff you're reporting on ISP members, as you term them.
Leslie Nobile: Maybe I didn't point this out. These request rates and issuing rates, the light blue is the assignments to end users and the dark blue are the allocations to ISPs. So you can see in the v6 —
Stan Barber: On the LRSA slide, who is that?
John Curran: Oh. That could be either.
Stan Barber: Either/or?
John Curran: It's both.
Leslie Nobile: It's both.
John Curran: It's not distinguished. In the prior slides, assignments are end users; allocations are ISPs.
Stan Barber: I got that part. I just couldn't see on some of the other slides whether you were distinguishing between ISP members, because you specifically used that term versus end users.
Leslie Nobile: On our website we have an LRSA page. We have Legacy RSA stats, and we actually distinguish — we tell which — what types of communities the LRSA holders are from. We have education. We have government.
Stan Barber: On the ASN slide, is that also combined?
Leslie Nobile: Yes, it is.
Stan Barber: Okay. Just you might be a little clearer about that when you speak so that guys like me who are end-user assignments can understand what bucket I'm in.
Leslie Nobile: Okay. Good information to have. Thank you.
Martin Hannigan: Hi. Martin Hannigan, AC member. Could you go back to the bucket slide? So is that representative — is that slide representative of every single address in the ARIN inventory whether it's available to be used or not including various registries?
Leslie Nobile: Yes. That has everything. Various registries is in the 5.70.
John Curran: Which is why it's 5.70, not 1 or 2, which is what everyone expected.
Leslie Nobile: Chris?
Chris Grundemann: Chris Grundemann, ARIN AC. Slightly tangential, I guess. In your slides you have some really nice graphs that go month by month, like back the last two years. Online the only thing I can find is month-by-month year-to-date and then year-by-year for the last ten years.
Leslie Nobile: Exactly. They're all historically archived, so we —
Chris Grundemann: Is there any way to have access to those online, like the previous years, month by month?
Leslie Nobile: I think they are online, right? Oh, not month by month. Oh.
Chris Grundemann: There's the last ten years year by year, and then there's a year-to-date month-by-month.
Leslie Nobile: Yeah.
John Curran: We can make them available if we have them, absolutely.
Leslie Nobile: I think we can do that. We can put that up. Sure. Thank you.
Okay. Thank you for your time.
John Curran: Next up is Mary K. to do the HR and Administration report.
Mary K. Lee: Good morning, everyone. And I'm sure, like me, even though it's not a perfectly sunny day, it's the first sun in several days, and I was pretty glad to see that this morning. Really.
Okay. I'm going to talk about the department staff, what we're doing on the administration side and on the human resources side.
Department staff. Thérèse Colosi, our executive assistant, provides support to the Board and AC, including travel arrangements, minute taking, helping with agendas. This year she's also helping with our effort to provide support to the NRO secretariat.
Misuk Kwon, our office administrator, so my right hand these days, she helps with facility management. She does packing and shipping for the Communications and Member Services Department. She's updating office procedures. She provides statistics to Nate for reports. She kind of does a little bit of everything to help us out.
And my area is pretty much the same. Hasn't changed too much: Payroll; comp; recruiting, which is very big right now, and I'll talk about that a little bit later; compensation benefits; facility management.
Our biggest news — or for me and I know for Bob as well, some of our biggest news this year was we were able to renegotiate a favorable deal for our lease. We will be there seven more years in addition to what we have right now through January the 31st, 2019.
And the even better news on top of that was we reduced the rate per square foot and we got additional parking for our staff. So we're pretty happy about all that.
Mary K. Lee: Corporate documentation. We're very gradually — I should back up a little bit. Last year we inventoried all of our major corporate documents, and we are gradually scanning all of them into a central electronic archive.
Electronic timekeeping. Paper time sheets went away at ARIN about six months ago, and we've gradually moved into this system of all timekeeping online. This has enabled us to put together better reports for budgets and labor distribution.
Employee benefits. We had some pretty significant changes at the beginning of the year. So right now we're really not looking at much going into 2012. Which is a good thing. We're happy with how the changes worked out.
Training and education. I'll start on the education side first. We have two employees currently working on their master's degrees. How they're doing that and working full time and everything else, I don't know, but they're doing a great job.
Training, a little bit of everything. Let's see. I have a list here, because it was quite long. Team Building, Transition from Staff to Manager, annual HR training, Puppet training, Red Hat Enterprise Virtualization, Project Management, Business Writing and Writing for the Web. So trying to keep up on our training side.
Staffing. Staffing, a lot of concentration in this area, because for the first time really in quite a while, we've had some turnover at ARIN and we have some openings that we are trying to fill.
You can see from this slide our tenure is still quite significant. Our average tenure is still six years, even with losing some long-term employees this year.
I'd like to just chat with you all briefly about this. It's very difficult for ARIN sometimes as a non-profit to compete with other companies. We provide good salaries and excellent benefits. We do not provide top-notch salaries. And, last time I checked, we still didn't have any stock options to offer anyone. So it is hard to compete.
Andy has been looking for some software engineers. And he and I spent a lot of time talking about this and running ads and reading resumes. So about a month ago we decided, well, just for fun, we'll put an ad out on careerbuilder.com.
Our ad was one of 1,712 ads in the metro Washington D.C. area looking for software engineers. So that will give you a little idea of some of the things we're struggling with.
So I ask you: If you have some good people, please send them our way. We would love to read their resumes.
And then just want to point out lastly some anniversaries. I like to mention those. Always the five-year anniversaries, one of those people are here, Mike Pappano, and Amy Sanchez. And then our ten-year anniversaries this year are Adam Guyot, Ming Yan, and Thérèse Colosi a little bit later this year.
And then going to do an odd-year number, because two of those people are in the audience and they joined us right at an ARIN meeting time four years ago, and that would be Hollis Kara and Mark Kosters.
Mary K. Lee: Thank you very much.
Aaron Hughes: Aaron Hughes, 6Connect. For clarity, do you need any community support if it turns out to be that salary is the issue preventing acquiring new staff?
Mary K. Lee: Maybe. I'm not quite sure how we would do that or what would be the way we would do it.
John Curran: Could you be more specific?
Aaron Hughes: For the community to express interest in allowing ARIN to raise salaries if they are not meeting requirements to get appropriate new hires?
John Curran: Let me address that, because we're going to be talking a little bit about the budget.
Across the board in ARIN we do comprehensive salary surveys. We actually go out and have a couple of salary surveys we use to rate all the positions.
And, as it turns out, the engineering department is one of the departments because of the area we're in, where even the salary surveys come back with very significant salaries compared to other personnel.
And so we're in a position where we think we've got good baseline. And we're doing the best we can to manage it. But I will note that the Board's given me the leeway to hire the people I need to hire.
At the same time I need to hear from the community. If you feel the budget is too high and people are standing up at the mic saying the budget is too high, obviously that has a primary effect on what I can do. I'm interested in overall direction on the budget much more than specific.
We understand software engineers are unique creatures, highly valuable, and probably that 1 percent.
Aaron Hughes: Fair enough. Thanks.
Mary K. Lee: Thank you.
John Curran: Okay. Next up is the Government Affairs and Public Policy report, which Cathy Handley would normally do; I'm going to cover this briefly because she's not here.
John Curran: We have been very busy in the area of Government Affairs and Public Policy Support. We have actually — this year has been a groundswell event that we are in the — we are covering both IGF and ITU functions at the same time.
These functions are — require extensive travel. IGF, we had both Lithuania earlier this year and we actually all just came back from IGF in Nairobi.
These require us to not only get involved in presenting at these functions, but also arranging the presentations. Cathy sits on the MAG, which helps choose the presentations and the sessions and what will develop those.
So we're heavily involved. As I've noted before, the IGF is quite important because the IGF actually is a body which meets and discusses Internet issues without being decisional.
So it allows governments, civil society, network operators, everyone to get together, talk about the issues without anyone saying: Well, we need to make some rules here.
And that's pretty important. The Internet's wildly successful to date because we've all worked cooperatively. There hasn't been one party standing up saying they have to make the rules.
So we value the IGF. And we've been doing a lot of work with it. But we're also working with initiatives in other government affairs organizations, such as the ITU.
The ITU is a decisional body made up of governments, and the ITU has many meetings where it has decided to take matters of interest into the Internet community.
Now, in general, we've been able to shape those interests towards the area of education and outreach where we think the ITU actually has a very good role, particularly the ITU development organization, where getting information out to smaller economies is a high priority.
We've been somewhat successful in preventing ITU from trying to make standards in the Internet area, because we note there's already standards bodies there, there's the IETF that's done very well, and these require continuous pressure and continuous involvement.
In ARIN, I'll talk a little bit about the costs involved, but it is full time, Cathy, it's full time, Cathy Handley, about a third of my time, and actually we've had so many events now that we've been tapping both Mary K. and Susan Hamlin to buttress up these efforts.
We do expect maintaining the existing Internet system is going to be something that takes a bit of ARIN resources going forward.
I'm glad to say we've been successful to date. I look forward to any questions or comments. But obviously the fact that we're still here and able to set policy means we've been somewhat successful.
Questions? Okay. Thank you very much.
I'm going to turn it over to Bob Stratton to do the financial report.
Bob Stratton: Hello, everybody. As John said, I'm Bob Stratton, CFO here at ARIN. I'm going to go over my staff, what's new, and I'm going to go over the 2010 financial statistics in some detail.
We've had feedback that the community wants to see these statistics in detail. So those of you that asked, we'll go through. Those that you — the rest of you can do email. And our plans for the future.
Staff. Val Winkelman is the staff accountant; she's my right hand. Michael Abejuela is the staff attorney. He's been on staff about a year now. He's been quite busy. Keeping up with Steve is a task in and of itself.
Tammy Rowe is the accounting supervisor. Her staff is Amaris, Tanya, and Amy. Tammy is quite busy as well at almost all times. They're a good group, and hopefully you've had a chance to meet with Val, Michael, or Tammy. They're all here.
ARIN Online. The Billing POC administration. You now have the capability of administering your billing POC which means you can change your email, your mailing address, and the personal contact through ARIN Online. This is a secure way of administering your billing POC. We're quite happy about that.
We're also sending reminder notices out through ARIN Online. This gives the organization clarity and visibility to the status of accounts.
You're also allowed to — now through ARIN Online to look at your invoices, both your current and past payment history. It's more of a recent payment history. And you'll see from our plans that we have plans to allow you to do more through ARIN Online on the payment side.
Last year's financial results. We had 13,175,000 in registration revenue, 13,533,000 in operational expense, a net result of 358,000 to the negative. However, this was overwhelmed by the net result from our investments. Last year was pretty good. This year may be a different story, however. The net gain to reserves was 2,558,000.
The breakdown on those expenses. This is from our financial statements. These are online. We break them down by five functional departments: Engineering, Registration Services, Member Services, Outreach, and General and Administrative.
As you can see from these, the net increase in engineering has to do with the engineering infrastructure build out. We tie both the software buildout and the network build out, which means colocation sites, all to engineering. So that's the reason for the net increase there.
The overhead is allocated over the departments by head count. And you can also see outreach increased as we let people know about v4 depletion and v6 deployment hopefully in the future.
The net increase year on year is 1.5 million. Here's a different way of looking at it. As I said, this is more detail. These are the different line items. These adhere to the budget line items. Again, this is a statement of operating expenses as part of financial statements.
The three lines right under compensation — depreciation, communication, and equipment and support — are all associated with the engineering infrastructure build out.
Under depreciation, we're depreciating the software associated with ARIN Online, RPKI, the IRR, and other infrastructure-related items. We have consultants associated with that. That's where the depreciation or the capitalization of the software occurs.
This also has to do with equipment. We're purchasing equipment and also related to the colocation where we put this equipment.
Communication, the majority of the costs there is the colocation sites and the Internet connectivity adherent to there.
Travel. There's an increase there, as John alluded to. We now have the ITU, the IGF, to add to the ICANN, the RIRs, the IETF, the NANOG, you can keep going.
The reason for the increase in general office is that's where we put the credit card expenses. As more of you pay by credit cards, that line goes up. Of course, it's offset by the revenue. But that's the reason for the increase in general office.
Continuing on, these line items are holding steady. This is 2009 to 2010 comparison, which is standard for financial statements.
Again, the net increase year on year was 1.5 million.
Speaking of software development, this is a graph showing you the cash outlay in red and the yellow is the actual expense recognition, where GAAP designates this is a five-year depreciation schedule. So this just gives you the idea that the cash has already been spent, but the expense is going to show up in future years.
This is another way of looking at it. This is a history of the expense by department in a graphic form, going back three years.
Again, as you can see, engineering is where the infrastructure build out is occurring and outreach is, whereas the other departments are holding steady.
Another way of looking at it is we break our budget into four functional areas: compensation, operations, general office and administration, and Internet support.
Compensation isn't that we're necessarily adding positions, it's just that over this time frame we actually kept people in positions until this year. And, thus, that's the reason for the increase there.
Operations are those three line items I spoke to earlier, which was communications, depreciation, and support and maintenance.
So that's the engineering infrastructure build out.
Plans for the future for FSD. We hope to integrate payments inside ARIN Online, as I alluded to earlier. We're currently working on associating Registration Services Agreements with resources and billing events. And Tammy will be happy to hear that we hope to eliminate the billing email role account so that you communicate to us via ARIN Online in an email form.
We also have a billing help desk line. If you do have any questions on your bills, Tammy's the person to see, or you can communicate through ARIN Online or call the billing help desk.
And I usually end my talks with just a snapshot of maybe something going on in global financial structure. This is a balance sheet of where the global financial assets lie for the 79 major economies of the world.
I just thought it was an interesting — this is from The Economist magazine.
And with that, I'm open to any questions.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. More of a comment than a question. Please don't eliminate the billing email role account. I like to get notifications that way instead of going to ARIN Online to find out what I owe ARIN or actively seek that out. I like to get my invoices in email and going to ARIN Online to pay them.
John Curran: So noted. Good feedback. Thank you.
John Curran: Okay. Next up we have the engineering report, which will be given by Mark Kosters. Mark is here to help us with the ARIN rebranding initiatives.
Go ahead, Mark. Come on up.
Mark Kosters: So where's mine?
John Curran: Right here.
People might remember that at the last meeting Mark reported on his attack by ducks, and it was the highlight of his slide. We decided we could make that part of our new branding message.
Mark Kosters: The duck stops right here. That's nice. I'll put on the shirt, because as many of you have probably — maybe you've experienced, but if you look on the remote participation and actually look on this, you'll see this huge screen here on the side, and then you see this little person. And I'm even shorter. So I must — I wonder how that looks for the remotes right now seeing this little head. And soon after I put this shirt on, I'm going to disappear, except for the little bouncing head.
Let's go ahead and get started with this. Any questions, first of all, about ducks? I have great knowledge. Okay.
Mark Kosters: The theme this time is that the surge is coming to a close. And you will see that we're starting to roll off contractors. Contractors have been — actually have had an incredibly long tenure also at ARIN. Almost all of them that have come aboard they've stayed there.
They actually love working at ARIN, for a number of different reasons. One of the best ones that I know of is that they think that Andy's handsome. So I don't know why that's true. I don't see that myself, but that's okay, Andy.
There's a lot of work left to do — you're welcome.
The other thing that we have going on is — Mary K. alluded to this, and I just want to bring this home. This is also new age for engineering. When I came aboard four years ago, most of the staff has been there for a long period of time. Which has been awesome. Having these guys that really know the system really well and actually making changes and knowing what the history has been has been actually a great asset.
Well, the tenure for most of these people have been like 10 years. And it's been a growing opportunity for them. And many of them have moved on to different positions. Some of you all in this audience may have hired one or two of them.
So they're really great guys. And I'm proud to see that they're actually moving onward and upwards. And what we like to do is bring in people with as good of skills if not better as we build out our staff some more.
So here is the — boy, that looks a little bit funny. So here is the staffing for our team. We have seven people in operations. There's one opening.
And in development, we have 12 people. Six contractors and six developers, plus a manager.
And quality assurance, we have eight people. And we have four personnel doing that and four contractors.
And then we have this incredible asset with Erika actually running project management for the company for engineering.
And then there's me, just the general pain-in-the-neck person.
Operations. What has operations been doing? Upgrading end-of-life equipment. There's a lot of equipment that has been part of ARIN ever since its inception. Seems like. No, that's not quite true. But we keep on rolling off equipment because it's end of their lifecycle. We've been trying to give away the equipment. We've been making the equipment recyclers very happy by the amount of gear we're giving out or sending to them.
We're starting to roll out anycast services for our public-facing DNS services that we have. And you'll be seeing that soon.
One of the other things that we've been doing is we've been consolidating our colos especially on the East Coast, and that's really based on RPKI needs.
One of the things we need to do with RPKI is we need to have our HSMs in a secure location. We want to make sure they're behind locked doors and within a cage.
In doing so we said, well, if we're going to do this, let's go ahead and consolidate our two locations within Equinix — within this one facility all within a cage with HSM gear.
So that's been a significant amount of time that's been taken up by making that happen. Especially when we're — that is part of our core operations in making that change happen. It's been a challenge for the operations guys.
It went through without a hitch. I don't think any of you have actually seen the move actually take place.
The operations crew also has a huge number of environments that they need to maintain. And we have production, of course. The other one is we have an OT&E environment. Do you know what OT&E is? Operational Test and Evaluation. And one of the things about this which is cool is those people who want to test their RESTful provisioning or registration software systems against ours, they can go ahead and do so in this environment and not affect production data.
If you make a mistake, we can — you could easily take out that mistake and you won't affect any production data.
We also have development, Q&A, and staging within our company to make sure that as we put these changes out that these changes actually do work.
And at least it seems one Saturday a month or every other month we'll go ahead and roll out a new release of ARIN Online. We'll do it on a Saturday morning.
We've had many practices, many practice sessions over the weeks beforehand to make sure it is correct.
Now I want to do a little bit of sort of a way-back machine. At ARIN XXV, and this is soon after I started here, we started seeing huge amounts of traffic increase. And there was all self-referential queries going, hey, I am from 192.168.1.1 and tell me who has 192.168.1.1. Okay. And it was huge. We saw just a huge amount of traffic over that history. And as soon as the conference was over, the traffic went away.
At ARIN XXVI, we saw a huge amount of traffic that — it was sort of ironic that this was right after Google announced OpenID collaboration with Yahoo!. And the very next day we saw a huge amount of traffic against our servers in dealing with login sites for the various social media and Google and so on, and all asking for the IP addresses of those particular web servers dealing with logins. And we are seeing 5600 queries per second against our Whois servers.
Now, you think about this. VeriSign, where Andy and I and Pete Toscano from operations came from, that was what they were seeing on a daily basis for .com and .net.
So actually part of me was saying: This is really cool. We're seeing the same traffic as this large monetized organization. We're able to keep the load up.
But then we started thinking about this: How are we going to keep this going — pretty soon we'll be as large as Yahoo! and Facebook and all these other guys — with the number of machines that we have to do to service this traffic.
But — all right. Here's a graph that shows the traffic spikes.
But as soon as the conference went over, the loads went away.
So at the next meeting we saw — at ARIN XXVII we just said, hey, look, loads are running normally, about 2,000 queries per second.
Today it's the same.
Vint Cerf: What did you do?
Mark Kosters: We don't know. We have no idea. It was all over the place. A lot of them were in the US, but there was equal amounts outside the US as well.
John Curran: But clearly someone heard about us at our meeting saying this really has to stop and probably changed their software.
Mark Kosters: So here's our graph against our Whois services. What's interesting about this is you can see that there's barely a blip from the beginning of time of ARIN's inception to what happened over the last two years.
It was just an incredible increase that we saw, and things have leveled off and things are starting to come to a new steady-state.
But who knows. Maybe the next conference someone will want to try something new and I have to report on — we just took over half of Equinix. I don't want to do that. And John doesn't want to pay for it.
So to me this is interesting in that ARIN was able to keep up with this. There were times that we were nervous. We were sweating like bullets to make sure, because we were red-lining our systems for a while, but we were able to keep up with the load and keep on going.
Another thing that's interesting is v6 traffic. So we've had these talks over and over, hey, we need to move to v6. But really this has all become steady state as well. There's been an increase in traffic over v6, and all ARIN services, core services, are available over v6.
But this is the most sort of interesting graph out of all of them that shows that, yeah, we've had some traffic. You can see that these are totals per month. Because if I was to do this in relationship to what we see over v4, you would never see this.
You couldn't even tell the color of the line at the bottom of the graph. So it's still a very small part of ARIN's traffic seeing v6 transport.
One of the other things that's interesting is the amount of traffic that we've seen over the RESTful interface. Port 43 takes a substantial amount of traffic. You'll see that it takes about 60 percent of the traffic here.
REST takes 39.9 percent of it, which I find very interesting, because this is a fairly new system. We rolled it out about a year and a half ago. But people are actually — quickly started writing APIs against this and are using it in a big way. The amount of people — a lot of people like using the web interface, but the amount of traffic we get off the web interface is infinitesimal in comparison.
Next I want to talk a little bit about the IN-ADDR.ARPA transition. You've heard about this for a great while. What I find interesting about this is here is a core service that's actually transferred from one established organization to another, and this was done in a way that did not affect operations at all.
It's kind of like the transfer of power with our presidencies. It just happens. It's not like some of these things that fall apart after their established leader leaves.
You can see that we've had various dates where ICANN and ARIN got together and said, okay, here's our transition plan, and this was coupled with not only the transition plan moving the generation of IN-ADDR.ARPA from us to ICANN, the test plans associated with it, making sure everything worked, but also coupled with that was moving the nameservers from the root servers, which they had been located on from the beginning of time, to servers that were operated by the regional registries in ICANN.
These moved off in increments from February of last year until the first part of March. One of the other things that happened at the same time is IN-ADDR.ARPA was signed. So you now have the ability to go from the root of the DNS infrastructure, which is signed, all the way down to your individual delegations without having additional trust anchor.
This has all worked and there's hardly — there's been a few issues associated with DNSSEC, but it's been very, very minor.
Here's a graph that shows the transition as it occurred, because these are one of these events that, hey, you're going to have this change; let's go ahead and measure this.
Not only we measured it, but also ORG measured it with all the root servers as well as the upcoming regional registry nameservers.
And you can see that it has — there's a pretty good steady increase of traffic. That big blip that you see about midway through was one of the regional registries actually went off the air for a little bit. We took — that data swung our way, and probably to the other regional registries as well, they came back online, it all kind of normalized out.
What's interesting here is there's a diurnal pattern that occurs on the roots, and it's also occurring now with IN-ADDR.ARPA. So it's just like the traffic, normal traffic that occurs on the Internet. It's diurnal, and it's almost the exact same pattern.
So what has ARIN been doing over the last six months? We've been making lots of improvements to the existing systems. I hope you've taken advantage of billing integration.
We've also had a partial implementation of 2011.3, and I'm going to talk a little bit about that a little bit more here in a minute. Delegations via REST and various requests that have come into the system that we need to have fixed.
We also deployed a new version of the IRR on September 29. What this does is it brings us up to the same sort of playing field as RIPE and the other IRRs in terms of having better authentication as well as notification.
And, finally, RPKI development keeps on going. It's a long slog dealing with the RPKI.
Let me go back to the partial implementation of 2011.3. One of the things that's interesting about 2011.3 is that it allows you as ISPs to give substantially larger allocations.
And one of the things that we've had within our system, we're saying, well, we had this infrastructural implementation that we put in our system that a /20, there was hardly any way that we were going to give out more space than a /20.
And so what we did at that point is we created a zone cut at a /20 level. And so when we created our zones under the v6 tree, what we did is we had our /12, and then we broke it out into /20s, and then your various delegations from those individual /20s were given out to you from within those /20s.
With this potential of having large blocks given out, that could be /20s or larger, we've had to go back and rethink this, and we'll probably end up ripping this code out.
The reason why we wanted to do this to begin with is we didn't want to have a large zone, like .com, a single, large, flat zone with very delegate — size delegations within it.
Sounds like that's what we'll have to go back to. It's doable. You can do it, but there's just additional management pain that one has to deal with in the future as v6 actually increases.
How is ARIN Online being used? We have almost 45,000 accounts. You can see here the number of users who are using it. A lot of growth has come in 2010, but we're still seeing growth in 2011.
Management of POCs. Give you an example. A large number of the creates for POCs are actually done through SWIPs, which are not done through ARIN Online, but what's interesting about this is zero are done through templates or any other means. They're all done through ARIN Online.
Management of ORGs. It's the same thing. All the modifications are essentially done through ARIN Online.
In terms of network management. Here it gives you an idea of how many things are — again, everything is done through ARIN Online on ORG modifies, and it gives you an idea of how many of the requests come through ARIN Online on the various types.
Here's an interesting slide dealing with provisioning. So one of the things that we wanted to do was give you a way of not only using templates, but give you an API, for those people who actually want to code against, closer to our systems.
And we realized that some of our documentation needs to be updated to make it easier to understand. It's essentially dealing with the business practices which are essentially exposed through our API.
We're working on that and we'll come out with better documentation in the future.
Meanwhile, there's an intrepid number of explorers who have actually been using this and actually have created basically their own software on top of it that's using ARIN — using this RESTful provisioning system.
And you can see that it's actually started to uptick here since August and we're starting to see a lot more users against — or a lot more sort of actions going against the RESTful provisioning system right now.
Whois-RWS, one of the things I talked about before. What's interesting is the number of RESTful transactions occurring. Here's where you can actually see how many people are actually using the RESTful interface and what the user agents are against them.
And a large number of them are — well, there's Firefox, of course. But you can see there's a number of people that have written programs against these things.
Andy, wasn't one ColdFusion or something like this at the very beginning? Which was very interesting. And actually it was done against the pilot. So people — they got on this right away.
One of the final slides I want to talk about is the IRR. Typically we see about 2,000 transactions occur over a year with an IRR. Turns out to be 10 templates a day on a business day.
In the end of 2010, 2011, it actually would have gone down a lot, except that we have one large — one user who is very active within ARIN's IRR.
We've actually had decrease of usage dealing with our IRR, even though we've recently improved it. And you can see — this shows through on the lower graph dealing with the active maintainers.
Since 2009, that red line, I want to point your attention to, we really only have essentially 34 active participants within the IRR or organizations.
Whois-RWS releases. Well, we've done a couple of things, one of which was notable and actually made NANOG. But we did improve our CIDR performance. We monitor these systems all the time, making sure we have — we finely tune these things.
We noticed we had some performance issues with CIDR queries that we fixed. We had a couple of CIDR bug fixes that we put out as well.
By the way, that was new, given Whois-RWS going out the door. Before ARIN did not support CIDR searching at all.
And the notable sort of email that went out on a NANOG list dealing with parent /8s being exposed on regular IP address queries, we fixed that as of October 2.
Now, finally I want to end up with RPKI. RPKI has been a huge challenge for us dealing with IBM HSM. The HSM is actually fairly poorly documented, and I'm sure if one of the IBM guys want to come out and talk to me about it afterwards, we can go through the documentation.
There's some fairly bad failure modes. As you're developing against this system, if you make a mistake in your code, you have to reboot everything. You have to restart the OS. You have to wait for the HSM to be initialized. It's a 15-minute process from a developer's perspective of making sure this thing is correct.
Given that it's poorly documented, and the poor failure modes, it's really slowed down our velocity, the amount of time that it takes to actually develop this.
The next thing is this stuff was built in the 1950s. So it's almost assembler-like in terms of what the API is. So it's a very, very hard system to deal with.
Beyond that, it actually chews up our developers. The main developer we had working on this took another job. He's been there for a long time. But it's put us behind.
So we estimate to have first part of production sometime in 2012. You've heard this from John; you've heard this from Andy.
The protocol itself for RPKI is fairly mature, but there's still a lot to do around the edges. Dealing with the global trust anchor, for example, getting that through the IETF. Dealing with transfers once we have policies in place to deal with this.
We also have to write this up on how we plan on doing this within the RPKI system, and that is not going to be a simple task.
And here you can see our upcoming challenges. There's a fairly significant amount of stuff that needs to be done yet within engineering in terms of the number of suggestions that have come through. A lot of really good ones.
Putting transfers a part of ARIN Online, for example. That's currently not there. About the only templates that we have not put in with ARIN Online. This is something certainly we'd like to be able to do.
Identified efficiencies like integrated payments. Bob brought this up. This is something he truly wants to do. And I'm sure many of you who do have to deal with the billing things in dealing with payments would truly understand this.
We also have a number of internal projects that limit liability, reducing inefficiency. We have a number of things that have been hacks that have been there from day one that really need to be — they're inefficient and need to be taken out.
And we also have some thought leadership in terms of Whois-RWS. Andy in particular has been working with IETF and other organizations in actually coming out with a directory service protocol that we can use not only within ARIN but other regional registries as well as the domain registries.
There's a lot of work going on within ICANN outside of the regional registries in dealing with this. And it also affects internationalization. So it's all a good thing.
John Curran: One up here. Head table.
Vint Cerf: So I was fascinated by the graph showing the spikes in queries coming into this system. Were it not for the fact that you're reporting this, it occurred to me that you might have generated those yourself in order to persuade John that you needed more assets in order to build a more powerful system.
Mark Kosters: Oh, the Evil Mark.
John Curran: I guess if it had continued unlimited, I would have to go explore that. Luckily it dropped off, and now we don't have to worry about a whole farm of servers.
Cathy Aronson: Cathy Aronson, ARIN AC. Two things. One, I wondered if you could speak to the suggestion of the Whowas service. And, two, I was wondering if folks in the audience who need that might speak up and express that since this is the Members Meeting where things that need to happen for the members get funded.
So if you're interested in that, I would encourage you to say so. Thanks.
John Curran: I concur. To the extent that people want these new services, now is definitely the time to go to the mics and talk about it.
Owen DeLong: Go ahead, Mark.
Mark Kosters: Dealing with the Whowas service, one of the things that we had talked about early on was actually — well, first of all, you can do this right now by going to — by asking a question to hostmaster and saying, hey, can you give me the records in question. And hostmaster will actually give you a snapshot of the data back.
Now, so there is a temporary fix in place. What we were thinking about doing is actually coming up with a report that would give the history of a particular set of IP addresses. Now, that's all dependent on the requirements. And we haven't really even gotten into that yet.
But that was one of the ideas that we have bantered around and would that be sufficient.
John Curran: In particular, it's — while historical data about Whois may be recorded by some and seen by the community, we still also have to do a legal review. I'm not sure we have a legal or a policy basis that necessarily lets us share historical Whois data for a given registrant.
It's a little complicated. It's one thing if people want a history of a block that they are the registrant of; it's another one for historical information about other blocks that they may not be the registrant of.
I'd like to know what's being sought here, because it may be more than technical. We may have to push out policy so everyone concurs that we can share that information.
Owen DeLong: I believe I was in line ahead of Heather.
Owen DeLong, Hurricane Electric. I fail to understand how something you used to publish would be something that you don't have a continued right to continue publishing.
This is data that was public. It's data that was published; it's data that we should continue to publish. It's been asked for by the community. It has been agreed to by ARIN, and now ARIN is back pedalling. I am annoyed by this.
If you feel you need policy to tell you to publish it, I'm happy to put a policy proposal in. I'm well familiar with the policy process. However, traditionally, I will point out, this is something I would have previously been told was out of scope of policy and was something about how ARIN conducts its business.
I'm tired of the runaround on this issue. We asked for this in 2008. There was broad community support for it. ARIN agreed in 2008 that it was something we would get. We still don't have it. It's 2011.
I don't care whether it's a report or interactive service or how you solve the problem, I want the ability to get the history of records that were in Whois for blocks whether I own them or not.
There is good use for this for abuse. There is good use for this for policy verification. There is good use for verifying how policies are performing.
The community needs it. We want it. Do it.
John Curran: Okay. So let me respond.
John Curran: For the blocks that you're registered, you can get that now by sending to hostmaster. It's a manual process. The development work to create Whowas service is something that's on the engineering work plan. It's part of the strategic plan of the company.
It's a prioritization question for the Board, because we have a lot of things we have to do, and it's a question of just what priority this particular initiative gets.
As part of rolling it out, yes, we will also do a legal review to make sure that we think we have the backing to publish the historical information.
It may not be an issue, but it may be an issue. And, if it is, then we'll cycle policy. But we're not going to do that work until it's time to develop the service. And right now that service is not committed on to even the 2012 work plan. That plan for 2012 is going to the Board next month.
Owen, do you want to respond?
Owen DeLong: Yes. I would actually like to hear from legal if they think this is actually an issue. I believe they're in the room. Because I just — I don't understand how there can be a legal issue with continuing to publish something you used to publish.
John Curran: Owen, we need to write a service description to give to legal to ask the question. We're not even there, because the service isn't even in development right now.
Owen DeLong: Yeah, that's three years late.
John Curran: That's because we have to prioritize. And some of the ARIN Online initiatives have come first. Okay.
Bill Woodcock: John, I'd like you to ask for a sense of the room whether people would like to see RPKI finished first or Whowas finished first.
John Curran: I would be happy to do that. Okay. So we have a question about the relative prioritization of Whowas, which is the historical Whois service versus RPKI, which we'll take to be both the hosted and the up-down one.
And I can ask people to raise their hands, asking only raise your hand if you're looking for Whowas being more important or whether you think that RPKI services are more important.
Does everyone understand what I'm going to ask? You can only raise your hand for one. I'll ask first for Whowas; I'm then going to ask for RPKI services. And this is a prioritization question.
Yes, I need pollers. The polling mechanism is being established as we speak. I see manual people running around.
So in a couple of seconds I'm going to ask for a show of hands. Would anyone like to discuss the relative priority of those two first?
Yes, Marty Hannigan.
Martin Hannigan: Martin Hannigan, Akamai Technologies. I'd like to plus one my colleague, Owen DeLong, and I think this question is not really a productive way to proceed because personally I think you should do both.
Bill Woodcock: I didn't say not both. I asked which you'd like to see finished first.
Martin Hannigan: Finish them both.
John Curran: More people at the mic to speak to this. Do you want to speak to that question?
Heather Schiller: Sure.
Heather Schiller, Verizon, who put in the request three years ago, so — and who is deeply involved in all of the RPKI and BGPsec stuff.
So it's like asking me to choose between two children. And what I would be happy with is if you would respond to email requests for address blocks that aren't ours, which is something that so far — I think that what's really difficult is the response, the public response to the suggestion, is ARIN will respond by email.
But it's disingenuous, because you won't respond by emails to block sets that don't belong to the person who's requesting.
And if you have questions about this, there was a consultation to the community. The time to ask was then. The frustration is about not having an update for three years.
John Curran: So in terms of the question of preference, one over the other, you would say both also?
Health Schiller: I can't.
John Curran: Okay. I will note that one of the reasons we only respond manually to blocks you own is because we could be inundated with staff requests otherwise.
Heather Schiller: I understand.
John Curran: And automate doing that before automation.
Heather Schiller: I have that data. I have that data. It's everything else that causes me a problem. And I think it just — it's that we're bound, right?
So there's data you have that it's just about making it in some ways searchable, but there are other people who have the data who have an interface to look at it who have been gathering some amount of — who have had bulk Whois arrangements for years who can't make the data available to the security community.
And so — go ahead.
Bill Woodcock: Actually, I mean, there are a very small number of us who have been archiving this for a long time from all five RIRs. And across the board we have the ability to release it not in bulk form but in response to individual queries.
But there's a lot of engineering work involved. Right? So, I mean, I'm speaking with PCH hat on here, right, for the moment. So you've asked PCH for things before, and we've done them, right? You're asking ARIN for this. ARIN can't do the other four regions.
Heather Schiller: I'm not asking ARIN to do the other four regions. What I'm saying is, it's not really — I can't turn the firehose on PCH and say, hey, everybody in the security industry, you can get all this data from PCH.
The ideal thing would be to be able to get it from the RIRs themselves because people — you're one of the only people that I know who have been archiving this data for time immemorial.
Bill Woodcock: If you guys figure out whether or not they're going to do it and they decide they're not going to do it, then we can try, right? But that's got to be figured out first.
Heather Schiller: So part of what I'm saying my frustration is over, today is the first day you're saying that you need some kind of policy thing to let you —
John Curran: I did not say that. I said part of developing a service is having a legal review of the service. And as we roll this out, we will do a legal review and see if we need that. We don't know.
Heather Schiller: I mean, that's something we could have been having in the works before.
John Curran: I will endeavor to get that started independent of the engineering work, but there's still significant engineering work to be done. The question before the group that's been asked is priority of that work with respect to the RPKI work, and your answer is they're both important.
Heather Schiller: So a bit of my understanding is that you're taking a lot of the RPKI work from stuff that RIPE's already built.
John Curran: No. Not at all. In fact, because of our nonrepudiation requirements, we have to do signing very differently to make sure that that happens only in the HSM and not within — not within user software. So we have an enormous amount of work to make sure that we can prove that the request actually came from you, from a legal matter.
So again, Heather, on the priorities, it would be both? Is that your answer? Okay.
Center front microphone.
Scott Leibrand: Scott Leibrand for myself first. It strikes me that we have an interesting approach that you have just talked about, but I'm not sure if we're discussing it or not.
You've said that you might open the floodgates to too many requests if you offered to answer them all. If that happens, to me that's an indication that it's pretty important and it should be prioritized above, say, RPKI, because I don't think you're getting quite that flood of request for RPKI. If it doesn't happen, then maybe that's an indication that it's not so important.
So I would advocate that you first accept requests for Whowas information with the understanding that these are going to be answered by humans, and if we get too many of them, they won't be answered quickly and we'll go develop an automated system.
And then based on that feedback, you go ahead and prioritize based on if people really want this stuff, then you should be automating it.
That's the way I do my job, is that I do it, and if it takes too much of my time, I automate it. So I think that's an approach you could take to answer that question.
John Curran: We could do that, but that would also mean manually performing RPKI operations until we're inundated with requests and then relatively prioritizing them. So if you actually want to do that, we can do that.
Scott Leibrand: I was not advocating doing that for RPKI; I was advocating doing that for Whowas.
John Curran: Regarding automation for both of these, do you have a preference?
Scott Leibrand: I would prefer that you start accepting Whowas queries tomorrow and that if you have more than one FTE answering Whowas queries, that you automate that; if you have less than .01 FTEs answering them, that you don't, and do the prioritization based on that.
John Curran: Okay. Far left microphone.
Cathy Aronson: Could we just go to the part where we vote and then come back to me?
John Curran: Well, it was pointed out that we need to have people — the deliberative process: People get to discuss why one's more important than the other.
Unidentified Speaker: So what I would say is there's some folks in the community that already could do this work. Woody mentioned one company. Could we maybe say have them go do that while you guys figure out the RPKI thing and then let's vote?
John Curran: I don't understand what you're proposing.
Chris Morrow: Hi, Woody. Could you make that service available to everyone now, please? Thanks. Bye.
Do you need like perhaps a server to make it available on the Internet? I could help you with that. Also perhaps with some bandwidth and stuff like that.
John Curran: So Woody indicated that there's some engineering effort involved as well.
Chris Morrow: Do you need also some MySQL database or perhaps Postgres?
Bill Woodcock: You realize you're really asking for it here, right?
Chris Morrow: Yes.
John Curran: So rear mic.
Andrew Dul: Andrew Dul. Just a quick comment that other organizations with large data sets often have a resource search fee associated with "can you look this up" and it costs you $10.
If this service is really valuable and is a manual effort, we need to provide some money to you guys to do a little research fee, and that seems reasonable if we really want the data.
John Curran: On the question of RPKI versus this, do you have a preference?
Andrew Dul: Whowas.
John Curran: Whowas first. Thank you.
Far right mic.
Kevin Blumberg: Kevin Blumberg, The Wire. I'm going to reiterate: Are there no other ongoing activities next year that can be used instead of having to choose between RPKI? And that, i.e., are there ARIN Online features like billing features that resources can be pulled off of so we don't have to impact the two things that we can't — that we don't want to prioritize based on?
John Curran: Let me ask a question. Of this year's delivered features for ARIN Online, are there something that you would have set aside to have either faster RPKI or faster Whowas? Recognize that next year's plan, for example, billing automation is the top request, the ability to pay an invoice that they see without going to another system, so it's very hard without input from this floor to hear how to prioritize those.
Kevin Blumberg: I would say based on what I'm hearing and my personal views that I will pay my damn bills the way I've always paid them; that automation of those systems to ARIN Online are far less important than the RPKI and the Whowas service.
John Curran: Okay. Thank you. Good feedback.
Front and center.
Scott Leibrand: This is a remote participant. Michael Greb from Linode said: Just because Whowas isn't a priority over RPKI doesn't mean it shouldn't be a priority. This is a service that's been promised for a long time and always seems to get back-burnered.
Owen DeLong: Owen DeLong, Hurricane Electric. I would have given up template deprecation gladly. I would have given up most of what you added to ARIN Online last year gladly in favor of Whowas, and I would give up the billing change this year in favor of Whowas. I would give up RPKI in favor of Whowas.
John Curran: Good feedback. I know the template deprecation wasn't really a choice because they had to be changed in order to go in an online system, so it was more which templates do we reimplement via the new database versus — you would have dropped templates completely?
Ah. Yes, that would have been exciting. We don't really have a choice on that one.
Cathy Aronson: I have a different different topic, so just...
John Curran: Okay. Prioritization of Whowas versus RPKI automation?
Jason Schiller: Jason Schiller, Google. I had a question: Do you have an estimate of if Whowas was made a priority, what time impact that would be to the availability of RPKI? And, vice versa, if RPKI was made a priority, how far would that push the timeline back for Whowas? And, thirdly, if both were important and both were worked on in parallel, how would that push back both of their timelines?
John Curran: So, yes, the FinCom has a presentation in front of it that talks about the relative staffing levels and what can be accomplished and what can be traded off between them, but it's still work in progress for next year's budget.
Right now the default is we work on getting RPKI hosted out in the first quarter; we end up getting up-down later on in the year; Whowas is a fourth-quarter item; and there's online billing enhancements for ARIN Online and additional functionality in the ARIN Online.
So that's — that's not fully staffed in the current plan. That's what I beat Mark with a rubber goose to get accomplished, okay, with the current staffing level. It might not all happen.
Jason Schiller: If Whowas was done first, that would push back hosted RPKI to second quarter and up-down to fourth quarter; is that what I heard?
John Curran: What we need to have from the community is relative prioritization, because it's not quite as simple. A developer who knows how to work on an HSM and do X.509 doesn't necessarily move to another project. So I need to have a prioritized list, and then I look at the resources that fit.
Presently we are dropping 11 contractors at the end of the first quarter. So we will lose 11 developers who are contracted. We've committed this to the Board. You can see the big surge of people we took on to get ARIN Online done, and those are going away.
So we need to be true to having a very prioritized development plan for next year.
Jason Schiller: I'm still trying to understand timelines. So does that mean we're still going to do hosted PKI in the first quarter no matter what because of the contractors being dropped, and the question is whether or not we do up-down first or Whowas first.
John Curran: They're worked in by different people in parallel. We're going to do first quarter hosted RPKI, at the present plan; ARIN Online enhancements will be done throughout; and Whowas is presently scheduled for the fourth quarter. Whowas could be moved up and we would defer ARIN Online in the instance as a result.
But that's what I need the prioritization from you folks for in order to sit down with the FinCom and work it all out.
Jason Schiller: Thank you.
John Curran: Okay. Other comments on relative merit of RPKI automation versus Whowas automation? Do you wish to speak to that? Yes, go ahead.
David Farmer: David Farmer, University of Minnesota. To answer the question, I think I would probably prioritize Whowas slightly in front of RPKI.
But I just thought I heard you say that the tradeoff is between ARIN Online enhancements and Whowas, not RPKI and Whowas.
John Curran: So let me be clear. Resources have to be used at different points in all of it. We need QA. We need user documentation. We need to actually do a communications plan. We need to actually have help material.
So nearly every department is involved in rolling out a service or an enhancement to a service. There are some key people who don't move around because they only know these bits — or not that they only know these bits; they're particularly good at a particular set of bits.
So the resources aren't 100 percent fungible, but, if we know the priorities, we can slot them in.
Does that answer the question?
David Farmer: I think it does, but I also think the question that's being asked back is what are the tradeoffs, what are the impacts.
And I run into this situation a lot. It's like, well, you know, what you want, well, what can you give me?
This thing just goes back and forth and back and forth.
John Curran: That actually gets done with the finance committee in prepping a budget for the Board.
David Farmer: Gets done in engineering, too.
John Curran: But it can't get done on the floor with a 100-person room. So the floor on the 100-person room has to give priorities.
Okay. Over here on that question.
Yi Chu: Yi Chu, Sprint. Further question. Before we can have the full thing implemented, for those of us who have a burning desire to know, is it possible say, for example, for me to request what Whois was like at the beginning of 2000 and just give me the whole record and I will search it? Is this possible?
John Curran: At present, if you ask us that for particular resources that you're registered to, we'll give that. But we have not been offering that as a general hostmaster research service for all records, no.
Yi Chu: So I heard that the folks on the Board, that they actually have been archiving it. So if I had the foresight, I can start archiving every month or whatever so I have the record. Because if I have to go back and ask you for that, you will not give me that.
John Curran: We don't presently handle requests on a general basis for historical Whois data. We'd like to automate that before we open it up.
But if people insist that we handle those requests, we can, in general, and we'll see what it does to the staffing.
Yi Chu: As to your question Whowas versus RPKI, my preference would be Whowas.
John Curran: Very good. Anyone else want to speak to that question? Closing that question. Okay.
There was a request for a show of hands, one versus the other, and we've just had a chance for people to deliberate on that.
So I'd like to very quickly ask people. I'm going to ask for those people who believe that automation of Whowas is more important, and then you'll raise your hand, and then the alternative is if you believe that automation of RPKI is more important. You raise your hand for one or the other. Not both.
Vint Cerf: It was clear, John, that the number of people I heard asserted that they wanted both, so is — you're forcing a vote for one or the other. Do you want to allow a third thing which says I'm not willing to prioritize one over the other, or are you trying to achieve some prioritization?
John Curran: I actually heard a request for prioritization.
Bill Woodcock: My question was not is one more important than the other. My question was which one would you like to see finished first.
John Curran: Ah, correct. So, to be clear, would you like to see Whowas automation finished first, or you can vote to have RPKI automation finished first.
So, now, everyone ready?
Everyone in favor of seeing Whowas automation finished first, raise your hand now. Whowas automation finished first. Nice and high. Okay.
RPKI automation finished first. Raise your hand nice and high. Nice and high. If you're stretching, I don't know if that's raising your hand or not. Okay. If your elbows are sideways, your hand is not high. Your elbow needs to be up. Thank you.
Thank you. And we're getting the remotes. Poor Mark. You've been like a sitting duck up here.
Owen DeLong: John, sometimes you quack me up.
John Curran: Okay. Number of people in the room and remote, 97. Automation of Whowas finished first, in favor, 16; automation of RPKI finished first, in favor, 8.
This will be provided to the ARIN Board for their consideration.
Thank you, Mark.
Oh, wait. More questions for Mark? Go ahead.
Cathy Aronson: Hopefully this one won't last as long as that one, but I had a question about the IRR. You say that the usage is going down. Do you have any idea why that is? Are people using some other database? Are they just not — because it seems like it's really big in other regions, and I just wondered if you had any idea.
Mark Kosters: If you look at the validity of the data, of the — our— ARIN's IRR — that's a mouthful — you will see that it's not very accurate.
It's less than 50 percent of the data that's contained in ARIN's IRR is accurate at any one point in time. It's actually decreasing or has been decreasing. I used to give reports on that at the ARIN meeting, and I stopped doing that.
My question is — and I'm not really sure how this is being used, but the subtext to this was we spent a substantial amount of resources doing IRR work to make that available. We spent — frankly, a third of our engineering staff actually was working on it. It seems simple on the outside; was not simple on the inside.
And so we went ahead and put that in, and after we finished it the subtext was "nah." We did that, all that work, for a small set of users. Really, was that the appropriate sort of context? Should we have done that?
And so the answer is I don't know why it's going down. Maybe it will go up now that we have better authentication in there.
John Curran: That's probably a question to direct to the ISPs in the room: Why don't you use ARIN's IRR. It's not as if ARIN, we're the users, we're the ones making the service available.
Cathy Aronson: Would it be possible to maybe send out a survey? I don't know. I'm just — you know, to find out if it's not useful, why or...
John Curran: It's a wonderful idea.
Anyone else at the microphones? Okay. I didn't see the order. Scott first.
Scott Leibrand: Scott Leibrand responding to Cathy's question. I haven't touched IRRs for a couple of years, but when I last did, the RIPE database had the IRR populated from the RIPE database and the ARIN IRR was a much worse copy of RIDB — or doing the same thing as RIDB without any real tie-in to the database and didn't have as much useful data, so it just wasn't useful to us.
My question to Mark would be: Have you fixed that? Is it actually populated from all those little nifty fields that we've put in there, like what is your Origin AS and that kind of thing? If so, it might be more useful than it used to be; if not, I can see why nobody's using it.
Mark Kosters: So as we went through this — first of all, ours is not tied. And, actually, that was one of the complications dealing with this. Ours was not tied with our allocation — with our allocation registry at all.
We actually had to rip out a lot of the dependencies that RIPE had put in their software to make all these things work better.
If we were to do this right — and, frankly, we've done it wrong three times now — is we would actually integrate this within ARIN Online. So you would have those features.
But what's interesting about that, I talked to a large number of the major users of the system, the 34 people, and what they said: Do not put any dependencies in that. If you put any dependencies in this in terms of making sure that the inetnum is actually mine, I'm not going to use it.
John Curran: We can go that direction and integrate it, but then it no longer necessarily becomes optional for you to make use of it.
Scott Leibrand: If it's optional, there are better IRRs out there in the ARIN region, and I would support as a member not spending any significant amount of money on improving or maintaining the IRR.
If we as a community, even outside the membership, decide that it's useful to have that information, like the Origin AS and everything that we've asked to be available as a field, put into the IRR, it might become useful. It sounds like you're not doing that for — I don't know what reasons, but...
John Curran: I think this is a case where we need clear guidance from the community. There's a number of strong people — there's a number of strongly held beliefs in the community that an IRR use should be completely optional. There's a number of folks who believe that an IRR is only useful if everyone is required to participate.
And I'm not sure ARIN staff should be reconciling that. I do like the idea of a survey, which is what Cathy suggested, to get these views.
Yes, far left mic.
Ruediger Volk: Ruediger Volk, Deutsche Telekom. Okay. A hint for your question, well, okay, why are there so few users. It appears to me that you haven't been making a lot of publicity about that service. And, well, okay, I'm not a friend of aggressive advertising, but, well, okay, keeping a nice resource hidden is not going to sell it well.
For the further development, I would say, well, okay, if you get the RPKI done, I don't think — I don't think you should and need to put more effort and more resources into keeping this alive.
In the current state of affairs, I guess you just have to keep it living until the RPKI can kick in. I'm well aware that IRR, RPSL is doing a few different things than RPKI, but at least from my perspective the reasons why I have been suggesting customers to go to your root and registry will be moot when the RPKI is there.
John Curran: Good to know. Far right.
Kevin Blumberg: Kevin Blumberg, The Wire. I don't believe that you need to be offering the service anymore. I think it should be deprecated.
If you had a best-of-class service, everybody would be using it, especially if it was free. Obviously that is not the case. Given the amount of resources that you're spending on it, there are commercial and non-commercial options available to everybody in this room, and those are the ones we have chosen to use.
So if it was a mandated scenario where you had a best-of-class service and you tied that to ARIN Online, which was a whole massive undertaking, I could understand it.
But with the numbers that you're talking about here, a handoff is probably more in line with what needs to be done at this point. And if that frees up resources for some of the tough choices previously we were just talking about, that would be wonderful.
John Curran: So there are no reasons for IRR work next year at all. There was none in this year's plan. People who follow the mailing list might notice that we surged to add authentication capabilities in, above and beyond, on top of this plan, because there was some very vehement complaints about it, so we added those capabilities.
I take your input and I think it's very valuable.
I'll note that even when routing registries were pretty much comparable and announced throughout the regions, in North America there was never a take-up that was correspondingly as large as it was in some of the other regions.
So I'm — if it's retire the IRR, that's a good outcome, but we're still having individuals request enhancements to the IRR, we need to understand is that a few individuals or is that a view of the community?
Kevin Blumberg: Given the numbers you're talking about, it would probably be cheaper for you to buy them all commercial accounts and not have to deal with these requests.
John Curran: Good to know. Center rear.
Marty Hannigan: Marty Hannigan from Akamai Technologies. I must disagree with my friend Kevin Blumberg. There's a value when a professionally run IRR — and I would expect that an RIR could run professionally an IRR. In fact, please don't deprecate this effort. And if you plan to make enhancements. We would certainly appreciate that.
And I am speaking with my Akamai hat on. We are actually in the midst of completing an IRR automation function and cleanup because we have objects literally all over the world and we'd like to centralize that between the RIPE and ARIN databases, especially because as transition progresses we see the need to populate multiple RIR addresses in multiple IRRs, and we would really like to be able to rely on them with full operations or people that are responsible for these things that answer to a community. And we hope that you continue to do this, and, if not, you give us a really good reason why not.
John Curran: Depreciating this RIR's IRR will generate ire towards ARIN? Got it.
Sandra Murphy: Sandra Murphy, SPARTA. I wanted to speak to one point about the security in IRR systems. There is a Routing Policy Security System, RPSS, that RIPE follows which says that only the holder of a prefix or an AS can enter things for that prefix or AS.
Some people take advantage of some IRR's laxity in following that and do proxy registrations and all sorts of weird stuff.
If you're going to have any hope that the information in an IRR is authorized authentic, it has to be tied to the people who are authenticating the person's right to the prefix, which means the RIR is the source of authentication for what's in the IRR. That's it.
John Curran: Got it. I agree.
Far right mic.
Kevin Blumberg: Kevin Blumberg. I just want to comment to Marty, because I did say that if it was a best-in-class system that was tied to ARIN Online, it was worth investigating, but the current system was not.
John Curran: Okay. I am going to close the microphones. We're actually well into break and behind in presentations. Anyone else who is going to speak — Aaron, you're the last one up. I'm going to close the microphones. If you want to speak, run up to the mic right now, otherwise I'm going to close them in ten seconds.
Go ahead, Aaron.
Aaron Hughes: Sure. Aaron Hughes, 6connect. I guess this was a follow-up to Sandra's comment, and then perhaps it will spark conversation that I should have outside of this room.
What's the recommended path for with dealing with proxy registrations when you actually implement tools like IRRPT and have no way of getting your customers to register those objects in an authenticated way?
Seems that IRR is an utopian concept to some extent, and a proxy registration is really the best method right now to get it working and move it towards something better than it is today.
John Curran: Understood.
Okay. Thank you, Mark, for your presentation.
John Curran: We have a schedule today and meetings that run all day for some of us, so we can't go too late. I'm going to ask Susan Hamlin to come up and give us a Communications and Member Services update, and then we'll take our refreshment break.
Susan Hamlin: Good morning, everyone. I guess I will zip through these slides. First I'd like to introduce the staff. We're all here and hopefully you've had a chance to meet everyone.
You've heard from Einar Bohlin, our policy analyst; Jason Byrne, sitting right here, our communications strategist and primarily responsible for all of the ARIN websites; Dé Harvey, our meeting planner who facilitated this meeting, and you should thank her for everything you've enjoyed this week in Philadelphia.
Susan Hamlin: Jud Lewis, our membership coordinator and now Mr. Election help desk. So please see him today before you leave if you have any issues with voting.
Hollis Kara, our communications manager, and really a project manager for all we do. She does a terrific job of coordinating our work internally with all the various departments and scheduling all of those activities with our external projects.
And her team include Jennifer Bly, outreach coordinator. Jennifer takes care of our social media and interacts with LEWIS PR, our PR firm. Sean Hopkins, communications writer. And Erin Sellers, graphic designer. You see evidence of her work: slide deck, these lovely sweatshirts you're wearing, and throughout the website.
So taking a look at our membership. This is over the past five years. It continues to grow. We have about 300 new ARIN members. And ARIN members are primarily those who receive a direct allocation of IPv4, IPv6 space.
Moving along. I'm not going to go through this, but this is the list of ongoing activities the department covers. And I've divided them into two groups: those that are communications related and those that are more organization related, such as facilitating the Policy Development Process, support for the AC, consultation process, elections.
The ACSP, we've talked a lot about it this week. It was developed in 2006. I like to give a brief update at every meeting. To date we've had 17 community consultations. There are two currently open. And we've had 144 suggestions.
Of those suggestions, ARIN staff has implemented over 30 percent of them.
These are the projects we're currently working on. One large one I spoke to in April. We hired a firm to develop a content management system. We're hoping to accept delivery of that platform in early November, and then we begin the task of migrating all of the content from www.arin.net into that system.
We also serve as secretariat this year and have provided a lot of support. For instance, we organized the NRO booth at IGF in Nairobi last month, we held a photo contest — I'll show you a slide about that later — and conducted a lot of surveys.
And I'm proud to say next week the NRO will announce the results of the 2011 v6 survey, and the ARIN region had over 20 percent of all the participants, and there were over 1600 folks that took that survey.
So May-June we ran, through the TeamARIN site, a photo contest. These were the winners with the captions. It was pretty entertaining. I hope some of you all participated. And we've now made these into mouse pads and we'll give them out.
Okay. TeamARIN microsite. I would just like to see a show of hands: How many people have been to the microsite and know about it? Not bad. But I'd encourage all of you to take a look. You can get to it off the ARIN homepage.
We are looking for guest bloggers. That would be my key message here. When we began the microsite, it was largely focused on IPv6. We've now expanded into other areas, education topics, and we'd like to open the blogging to community experts.
So if you have any interest in blogging or have content ideas, please drop a note to any of us in the department or send an email to firstname.lastname@example.org.
ARIN's definitely social. Since April we've increased our Twitter followings by 600 people, and we have about 100 new Facebook fans. And I think that largely we have you all to thank for our increase in the Facebook.
Susan Hamlin: Outreach and public relations. As I mentioned, we work with LEWIS PR. They're instrumental in helping pitch ARIN key messages to the media, to the community.
They help us with daily input for our social media. And they continue to look for new audiences for us to address.
This is a list of exhibit and speaking events attendance since April. Quite a few of these are booths. We've had John out on the road. We've had Nate out on the road. A lot of folks out on the road.
And, again, we're always looking for new venues. If you have an idea of a place we should be approaching, please let us know.
And these are a couple of events coming up in the next month.
Outreach. We began an ARIN on the Road program in 2010. We held two events. We held three this year. We're going to hold more next year.
This is a look at the sample agenda. These are one-day programs, 10:00 a.m. to 3:00 p.m. We look for venues or locations where we haven't held an ARIN Public Policy Meeting. Raleigh-Durham. Someplace it's not conducive to bring the general membership but where there is a target audience, and we've been pleased with the participation.
I'll mention there are two community consultations open: one on the Policy Development Process, it's open until the end of this month; and one on the Legacy Registration Services Agreement 3.0, open until November 3rd.
There's a new graphic on the homepage that will take you to a page where you can subscribe to the consult list, and we'd like to hear from you on both of these issues.
Elections. Elections are open, as Jud mentioned. Actually, beginning yesterday, some of the ARIN staff in the office were calling DMRs, and the rest of us, when we get back next week, we'll call. We'll call every registered DMR. And thank you in advance for participating in voting.
Like to welcome you next April to Vancouver where we'll hold the ARIN XXIX meeting sponsored by TELUS. And then in the fall of next year we'll be back-to-back again with NANOG in Dallas, and Terremark will be sponsoring that event.
And I do call your attention to the Fellowship Program. I believe it will open in January for the April meeting, and we are looking for any first-timers to join us. We try to pick someone from all parts of the region: one from Canada, one from the US, and one from the Caribbean.
And that's it.
John Curran: Any questions for Susan?
Okay. Thank you very much.
John Curran: I see some of you looking anxious. Yes, we will have a break. We will go on break right now. We will resume promptly at 11:10. You have a 20-minute break. We will resume at 11:10 with the ARIN Advisory Council report from John Sweeting.
[Break taken at 10:51 a.m.]
John Curran: Welcome back to the ARIN meeting. We're going to resume this morning's schedule by a presentation of John Sweeting, Chairman of the ARIN Advisory Council.
John Sweeting: Good morning. John Sweeting, Advisory Council. All right. Okay. Good morning. John Sweeting, ARIN Advisory Council, giving you a quick report on the activities of the Advisory Council so far up this date this year.
All right. The Advisory Council, it's 15 elected members with three-year terms. So effectively a turnover of one-third of the AC each year, not necessarily a turnover, but one-third of the AC comes up for election each year.
Here's a picture of R.S. on his wedding day looking very distinguished.
John Sweeting: Everybody get a good look at that, because it's probably the only time you'll see him that dressed up. For anybody who recognizes, Mr. Humphrey is there on the right, prior ARIN Board member. Looks like they had a great time at his wedding.
Okay. So 2011 Advisory Council election. As I said before, we serve three-year terms. Five members up each year. This year — the terms ending this year: Dan Alexander; Marc Crandall; Bill Darte; David Farmer; and myself, John Sweeting.
There were ten nominated individuals for the five positions. And you've heard all the speeches and talked to a lot of us during the meeting.
Okay. So the main role of the AC is our role in the Policy Development Process. We evaluate policy proposals. We develop draft policy. We present these policies to you at the meetings and discuss them on the PPML.
We do determine that it meets the community needs and requirements and it's good, technically sound, and whatever the rest of the stuff that Einar always says that sounds so good but I can never remember it, and then we recommend draft policy which meets those requirements to the Board of Trustees for adoption.
So for 2011, up to this meeting, we had 33 new proposals. And, to contrast that, we had 16 last year. And I think that 16 was pretty much the high mark. So we've had a very, very busy year.
Of those 33, four are currently pending; 16 have been abandoned; there were two unsuccessful petitions against those 16 that were abandoned — against two of the 16 that were abandoned; and 13 were moved to draft policies.
Of those 13, four were recommended for adoption, one was abandoned, and eight are pending at this meeting.
So some of the other activities. As the Advisory Council, we participate in meetings and we also help out on the outreach events. So you can see all that there, and if you want to talk about any of those meetings, you can seek out the member that was — the AC member that was there.
They do give reports to us on what goes on there, and we keep up on all the different policies going on in the different regions to see how they contrast with ours and all that.
Let's see. Other things we participate in is the Fellowship Program. We have one member that serves on the selection committee, and then we have three members to mentor the Fellows during the meetings.
The outreach program, again, we participate in the ARIN booth. Focus in on IPv4 depletion, v6 education, and the promotion of ARIN meetings. We have — we participate on the Nomination Committee, the PDP Committee, and virtually any other program that ARIN staff ask us to help them out with.
That's it. And thank you. And please remember to vote.
And if there's any questions.
John Curran: Any questions? Thank you.
John Curran: Okay. Next up we're going to move into the various reports, and the first report is Paul Andersen giving the ARIN financial report.
Paul Andersen: Thank you, John. I'll be brief. Where am I pointing today? Okay.
I'm going to go over three areas, kind of give an update where the FinCom has been doing some work, give an update on how our finances are looking for this year and what we're looking to do for in the future.
This year we've been doing a little bit more focus on the investment accounts. Earlier this year we did do some reorganizations of the three funds that we have and moved some from our long term, which is a little bit more exposed to the market, into our operating account, which is in more of a CD-style space, and we managed to get some money out of the way before the slight weather changes in the market this year.
We had an in-person meeting with our investment advisor to kind of go over the structure of our finances and see if there's any changes.
We've been doing the ongoing stuff that we do, which includes we review all the travel expenses for Board and CEO, going over financials, positions on a monthly basis. We review any large payments. We review the 990 Form filing, which is something we're currently underway, and we take a first crack at the budget before it goes to the Board for approval.
So for this year, we've — so these numbers are through the end of August. Revenue is a little bit stronger than anticipated, 9.5 million. 75 percent of that is IPv4 subscriber fees only. The remainder is IPv6, IPv4, IPv6 subscribers, end users, ASNs, transfers, maintenance fees, et cetera.
Expenses are coming about 9.2 million, so we right now are running at a bit of a surplus.
Unfortunately, the investments, as at the end of August, we're 117,000, which does show a bit of a surplus. Unfortunately, that's at the end of August. If you have an investment account and you saw September, you know that things aren't as well as they were.
So looking at some of the specific numbers I think has been discussed earlier. Our personnel is a little bit under, and that's because of some vacancy positions that have not been filled yet or are not going to be filled.
Travel for the organization as a whole is showing actually under, but we anticipate that will be on budget by the end of the year, because the fourth quarter is actually going to be quite a heavy travel for us.
Other major variances. Maintenance and operations and depreciation is under. That's thanks to the refresh cycle that Mark's group did for the public facing. They managed to be able to find another solution for that, which was significantly cheaper, so both depreciation and that are simply under.
Rent is running a tiny bit under, thanks to renegotiation of our lease and some savings from that.
General office expense is over. And that's, as Bob mentioned earlier, the — we are seeing a significant increase in the number of members paying by credit cards, and, thus, that associates the discount fees.
Our general legal fees are a little bit under, although we do anticipate that by — there's some timing of payments and by the end of the year that will come under budget.
A small note on the legal defense one, obviously that it looks look a variance. That's because every year we budgeted for a few years now zero in the legal defense, but this year we've had a number of litigation matters that we've had to deal with, so that's accounted there.
ICANN Internet support payments are also still showing a bit under, but that's again a timing of issues, and we anticipate that being on target at the end.
Professional fees is down a little bit because of — have to double-check — because of some contractor payments that will be coming later.
So we're right now showing about that — we're kind of estimating that we're probably going to come out about a million under budget for this year, mainly due to the personnel issues.
Give you an idea of a breakdown by the departments. Engineering, of course, being a large number due to the significant investment in ARIN Online.
So some things that we're looking on. We are obviously looking at how ARIN is going to be structured in a post IPv4 exhaustion world and what that's going to impact on the structure of the organization.
We are looking at fees. The Board has had some discussions on it. Staff are right now looking at the framework by which we charge. We are trying to have a good discussion at the Board level whether or not it is time to look at another fee structure.
Not suggesting that we are going to make a change, but there hasn't really been a wholesale look at this in some time. And we'd obviously welcome any community input on that, either at mics or in the hallway or email after the meeting.
A few other things we do. Staff had put a new timesheet system in place. We're trying to get an idea of just what various areas cost to the organization.
We've been looking at how we do airfare to see if there is a more economic way, given that it is our highest — one of our higher budget items. And continue to make sure that the investments are in good shape.
Here's a snapshot. As you can see from a revenue and expense standpoint, we are starting to close the gap from a surplus standpoint. In fact, this year we do expect to spend a little bit more than we take in; mainly, again, as we invest in the ARIN Online system.
We've still been running a bit of a surplus every year so far thanks to investments, the investments in the reserves. As you can see, we continue to see increase in that; although, again, we are right now seeing quite a drop due to the market conditions that we've seen.
And before I get to the questions, the other thing we obviously — the finance committee will be doing will be, as John said, looking at the budget for the coming year. We'll be making recommendations to the Board, which will involve trying to find which items we should be prioritizing.
I would say that my colleagues had a little powwow here during the break, given there was some feedback, and I believe it's our desire to see the Whowas service reprioritized, to see that delivered much faster and, at the same time, see if John can find a way to deliver RPKI without that suffering from a time frame too much. So we thank you for that feedback.
With that, I'll take any questions.
Martin Hannigan: Marty Hannigan, just myself. So, again, as I guess I pretty much bring this up at every presentation that you do with respect to the reserves, again, giant reserves.
What are we going to do about that? I also don't agree that we need two times operating revenue in reserve.
I've done some research. I've checked other like-minded organizations, and I can't really find anybody that can justify two times the operating reserves.
I'd like to know if the Board is going to discuss that in the coming Strategy Session or if we're going to continue to build these reserves.
And I don't think that saying the uncertainty around investments is also kind of a justification to keep reserves high or low or medium or whatever.
Paul Andersen: I don't think there's so much uncertainty in investments; I do think there's some uncertainty as we right now go through the exhaustion phase and all that.
I think there has been — we have had some discussions on the reserve. We've actually been trying to draw down a bit. We've actually budgeted a loss for the last two or three years.
Fortunately — fortunately or unfortunately, we've only drawn down not as much as we thought. So we have been — instead of — when we did the major investment in ARIN Online, instead of raising fees, we started to draw into the reserve.
And I think as we kind of get an idea of what ARIN looks like in a post v4 world from a fee standpoint, from a size standpoint, that we would look to see what is the appropriate size.
So I think I'm in agreement that we have to try and figure out what the right size is. I just would just — or maybe I don't disagree, but the timing now, right now, is not when we want to make a change, but we are looking at...
John Curran: I'll just echo, having been one of the ones recommending to the Board, the Board did have some substantial discussions earlier this year at its workshop. And I think if we look post depletion long-term, we may end up with a different fee structure.
So it's nice to have an ample reserve to get you through that transition, because that could be a very different fee structure with very different implications.
But I agree with you; long term I don't think we need a 2X operating reserve. But the question is: Do you want to start trimming it before you get through the other side of what could be a very different outlook.
Martin Hannigan: Yeah, I'm not trying to second-guess you guys on the reserves; I just haven't heard a justification as to why you guys need a really detailed and clearly understood justification as to why we need two times the operating expense in reserve year after year after year.
And, quite frankly, the discussion with Whohas and RPKI and all these other initiatives with these giant reserves sitting there: Spend them. Give us what we want. Don't resist. IRR, RPKI, Whohas, give it to us. Hire some more staff.
And the only other point I'd like to make is: Did you guys really implement a timecard system? I'm not surprised that nobody wants to come and take a job at ARIN. I hope that's temporary.
Paul Andersen: Well, a few things first. I don't disagree. It's being able to — and as I said earlier, I think there's some commitment that we — we heard that there's a prioritization.
It's not just a matter of, oh, it's throwing money into — no, we have to — we have vacancies right now for positions. That's one of the reasons we're having problems in that regard, but we're working on that.
And I think also — well, I'll let you comment on the timecard issue.
John Curran: I was going to say, so I'm going to give a presentation I'm going to slip in right after him, which talks about —
Martin Hannigan: I didn't mean to make it sound like ARIN is a bad place to work; I just —
John Curran: No, no.
Martin Hannigan: Well, it's 2011 and this is the Internet and that's kind of unusual in the kind of companies we work in.
John Curran: Rest assured that we did receive ample staff feedback on first the paper timecards and now electronic system.
But one of the presentations I'm going to give talks about what that's enabled us to really do, which is drill down on what is the staffing of running the registry versus what is the staffing of the policy process, because we have all these expenses, some people want to know what are all these people doing.
So I'll present on that right after him.
Martin Hannigan: Okay. Give us what we want, or give us our money back. Thank you.
Bill Woodcock: So I'd just like to say that reserves are not something that you have a detailed plan for. The point of a reserve is to deal with unanticipated problems. Unanticipated problems in an era when we are in turbulent change, because we are drawing our current funding from a resource that we no longer have any of to give out or won't shortly.
Turbulent change is pretty much a foregone conclusion. Therefore, it's a really good idea if we have a reserve to deal with whatever the outcome of that is.
The fact that we don't know what the outcome is is irrelevant.
Martin Hannigan: I don't disagree with you.
Justify it, and prove that we need it.
Bill Woodcock: That's exactly my point. You can't justify and prove something that is not knowable.
Martin Hannigan: We got another non-answer.
Vint Cerf: Marty, actually I'm plus one on what Woody is saying. But I have to say your other comment about "give us what we want or give us our money back," what that reminds me of is the guy that goes up to the ticket counter after seeing the first ten minutes in the movie and says: I didn't like the movie; give me everybody's money back.
Martin Hannigan: I would certainly like that.
Vint Cerf: I'm sure you would, but that's not going to happen.
Martin Hannigan: I've been at this movie not as long as you have, but pretty close to it.
Scott Bradner: Just to go back a little bit. The Board back quite a few years ago asked to get a — I think it was a year or something like that — reserve in order to buffer us through potential hard times and crashes or burning down the plant or something like that.
The returns on investment have been significantly higher than we expected. So we didn't ask for two years. We asked for less than that. But the returns on investment have been larger.
And as the treasurer just pointed out, we have been budgeting to draw down the reserves for the last three or four years, at least three years, and each year we were — I won't say disappointed — but spent less and made more, other than one year when we had a real hard time.
So we don't have a justification for the current level other than history. And history got us to where we are.
Despite our good efforts in trying to spend it down, the stock market — our particular investment counselor has been pretty good and given us a lot more money.
But we are trying to spend it down. We consciously — the Board does consciously not try to keep us within the revenue from the members what we are spending — trying to spend the reserve down.
Martin Hannigan: Thank you for listening to my passionate point. And I do appreciate the hard work that you guys do, and I know that it's not easy being on the board, treasurer, CEO, others, and thank you very much.
Paul Andersen: Yeah, I just want to add to what Scott said, too, is that the last two years we've had plans to draw down on the reserve of a million dollars each year, but unfortunately Mr. Stratton is just too good a man in the markets, and the returns have been good. So it's like...
Okay. Mr. Blumberg.
Kevin Blumberg: Kevin Blumberg, The Wire. With the budget surplus or with the overall surplus that you currently have with the reserves, are you looking at continuing the v6 discount rate, or is that coming to an end and there's no plans?
Because with v6 adoption still at, what, less than 50 percent of total organizations within the member community, I would strongly suggest continuing that until such time as needed.
John Curran: At the present time, that schedule, the discount — which was 100 percent, and then 75, and then 50 — will go away unless the Board acts in the next two years.
If I understand you correctly, you're saying it should act and we should continue to discount those v6 fees.
Kevin Blumberg: My suggestion is to reset the counter back to 100 percent.
Paul Andersen: And a plus one from Stacy.
Ralph Bischof: Good morning. Ralph Bischof with SAIC/NICS for NASA. My wife would let you know that I'm as good with budget and finances as my dogs are with calculus.
So one of the things that you had mentioned that piqued my interest was the budget allocations for personnel. You had mentioned that money is budgeted for positions not yet filled or not going to be filled.
So my question is, is why would you budget money for positions never to be filled?
John Curran: So we — so we don't budget money for positions to be filled, but we have had attrition. When you have attrition, you have to decide if you're going to backfill a position.
We made a strategic decision not to backfill certain positions and instead to reallocate the task to other people, because that will let us eventually bring in a lower-grade position and be more cost-effective getting the work done.
So that's just the circumstances. We are in the middle of a budget year where we've lost someone and we've decided not to backfill at that same level.
Paul Andersen: Yes, my apologies. I realize I wasn't as clear as I could have been on that earlier.
Unidentified Speaker: Back on the IPv6 fees, when 2011-3 was put through, there was also a — that's the reorganization of the IPv6 ISP fees — there was also a suggestion put through to restructure the fee schedule to more closely match that.
I wonder if there's been any discussion or work done at the Board for that.
Paul Andersen: The FinCom did discuss when the request came in some time ago, and the initial thing we did was to actually change the fee schedule to reflect that we only had fees for assignments and allocations that we actually offered, because we did at that point.
So we've removed that fee temporarily from the schedule. And what happened, if policy would get adopted, the staff will come and give us a recommendation on what that fee should be. And that has not happened, but would happen in very short order.
John Curran: Thank you, Paul.
John Curran: I'm going to insert a slide deck not on your schedule. Even though we're running late and even though we've had lots of fun, we can have a little more. And this is to answer the question of how ARIN spends money, because the presentation you just saw talks about departments and various line items, but doesn't talk about us delivering on our mission.
John Curran: So at the Board's request we spent a bit of time introducing a time sheet system — first paper, and then electronic — so we could know whether or not Bob was spending his time supporting billing versus supporting the Board with finance presentations, whether I was spending more time supporting one thing or another, and then how the staff were being allocated.
So I'm going to talk about four functional areas, and I want to show you based on the spend through this year of $9 million how that gets allocated.
This might change your perception a little bit of ARIN and how we spend your money, but I think, well, you guys have more information can only be good as far as I'm concerned.
So four functional cost areas. Registry Services. The bare-bones expenses related to keeping the registry running: the Whois database, the reverse services, DNS services, ARIN Online. This is the systems that are doing it. It's also the help desk that answers the phone at Registration Services. It's also a little bit of engineering to keep the servers running.
It is not development. It is not the Policy Development Process. It is not anything to do with changing the services that are out there today. Okay? So if you are talking about any change, they're not in Registry Services. Registry Services is we're just keeping it running as is.
Registry Development is that second category that you think about: improvements to the registry. So that is not just a big portion of engineering, but also the Policy Development Process, since when you guys change the policies, those result in registry changes.
As well as support for the Policy Development Process, the policy meeting itself. Okay? A big portion of the policy meeting is about the policy development effort, so a large portion of that is in here.
ARIN the organization. ARIN is a 50-person — 52-person organization. We have a Board of Directors that needs to be presented to. We have filings we need to do. We need to have a little bit of leadership in at least myself and a little bit of Nate. We have the Board meetings that are required by law. We have an election process that has to elect those people. We have a mail server that we have to run.
And so the little bit of generic organizational overhead of a 50-person organization is what you see in ARIN Organization. It's something that if you were to set up a 50-person organization yourself and had similar tasks you'd have to handle.
And then the last part is Internet Governance. And this is the time we spend that truly is going out to organizations and describing what we do and what our mission is and why it's important. So it's a great portion of the outreach that we do, and almost all of the government affairs activities.
So if we look, I'm going to give a breakdown of the costs in each of these areas.
So just Registry Services. Through August of this year, we've spent about $9 million. We would spend about 2.9 million keeping Registry Services running. That's the staff, the communication, depreciation, Members Meetings, rent, occupancy, everything. About 31 percent of ARIN's spend is keeping the existing registry going. Just steady stream.
Registry Development. This includes the public policy process, the Public Policy Meetings. It includes the engineering staff, doing development and changes, all the enhancements that are being done, ARIN Online, anything we're doing with RPKI.
About 49 percent of the organization is change agents. I mean literally people working with the AC to make new policy, people working on changing the services.
The reason this is important is people don't realize we're in a time of flux. ARIN has had to change more in the last three to four years than we've had to change since the history of the organization.
We're in a remarkably dynamic time, and the costs of how quickly we do those changes, how quickly we do policies, and how quickly we do changes to ARIN Online, ends up being the rate that we spend this money.
At this point half the organization is busy working on changing to accommodate requests that you have, new policies that you have, the Policy Development Process that enables that.
And then organizational overhead. Well, that's not very much, but it's still a sizable amount. A lot of that's me. I'll be the first to admit. A bit of it's Nate and a little bit of Bob for reporting, but it's also just having a generic 50-person organization has expenses.
Then Internet Governance. About 11 percent of our budget, about 1.1 million to date. About 11 percent of the budget is Internet governance. And that's more than we've ever had in the past, because, as I've said, we're dealing with ITU, IGF. A lot of people have decided the Internet's exciting and they want to come help us; we need to engage with them to facilitate their help in a productive way.
So I give this, and I have the breakdown in other columns so you can see it by line item and by functional area.
And that's it. These slides will be online.
Kevin Blumberg: One question or one comment. With registry development, splitting up policy and software development would be a really good idea.
John Curran: We can do that. The challenge is you make a policy, and then engineering development needs to implement it. So what's the cause and effect?
I mean, if a lot of our changes are directly implementation of 2010-X or 2011-X, do you want that in changes for the PDP or do you want that in policy or do you want that also in engineering?
Kevin Blumberg: I think that it is crucial that with 50 percent of ARIN is now a software development firm —
John Curran: Well, it's a policy development and software development firm.
Kevin Blumberg: Right. So how much — I guess what I'm saying is how much of ARIN has become a software development company.
John Curran: Ah, got it.
Kevin Blumberg: And that is actually the crucial — what the software development company does for ARIN is great, meaning you can document that and do all of that, but I think as a member what really interests me is knowing how much of ARIN has become a software development house, how much of that can be outsourced, how much of that can be RFP'd, et cetera.
John Curran: Right. So, for example, in Mark's slides he talked about that. Our core software development — and I'm going to count QA in there because you kind of have to, a few other people — our core team is only about — Mark, you here? — seven, seven FTEs, I think, across the board. That's — exclude operations. Our development team that's in house is seven.
Now, in the last two years we've had contractors for 13 — varying, 11, 12, or 13 people that we've done so we don't end up becoming a permanent software development shop but we can handle the surge of ARIN Online.
So we presently have — as we've gotten through ARIN Online, one of the big questions is how much additional contracting we have. I don't want us to be a permanent huge software development shop, but we always will have some in-house capability.
Does that give you an idea of the sizes?
Kevin Blumberg: It does. But, at the same time, the way I'm looking at it is if things change in the future and ARIN's functions and roles have to be diminished for whatever reason, I would like to know that something along the lines of the software development side of it is 20 percent of your budget overall over the last X number of years and that can be dropped down to 2 percent for certain things, and, you know, that gives me a sense of where the budget is. It helps.
John Curran: I think if you and I sit down and talk about those assumptions, I can try to come up with the cases. But I want to talk about those assumptions, because what you think could go to 2 percent only — it depends on whether or not you let people have maintenance or whether you let them do policy changes, et cetera.
Kevin Blumberg: I agree.
John Curran: Okay?
Heather Schiller: I'm curious if the other RIR presidents, CEOs are here, how many — what is their engineering staffs like?
John Curran: I haven't given these numbers to them. I know some of them are here, but —
Heather Schiller: No, just like how many full-time engineering folks do you have doing software development kind of stuff.
John Curran: I don't know if we have any of them still here. I don't see them. Oh, I see one of them.
Heather Schiller: In particular, I was particularly curious —
John Curran: Axel, would you like to talk about how many engineers you have?
Axel Pawlik: Damn it. Engineers. Let me look it up for you. I actually don't have them broken down off the top of my head.
John Curran: Do you — offhand, what's the total —
Axel Pawlik: Engineers. Oh, we have about 120 people overall. I guess 25 or so. 25? No. More. 30. 30. That includes software and IT and all those guys. But I really would like to look it up.
John Curran: Right. I was going to say accurate comparisons in this area would probably require some Inter-RIR work to make sure we have the same line items.
Heather Schiller: I understand, but I think that getting a good feel for what it — for — it's when other RIRs are doing a lot of work developing resources that are then used by other regions, it's an interesting thing to be able to look at.
John Curran: Sure.
Heather Schiller: And I think some things particularly in RIPE are a little bit different because you have sort of the external working group that helps do database standards and things like that, right? So —
Axel Pawlik: We do other stuff as well.
In about three weeks' time we have a general meeting, and we'll have a very similar discussion there. And I'm looking at your slides, and I think we'll have very similar stuff.
John Curran: Okay. I hope this information is helpful. People have asked sort of where is the money being spent. This is a first cut. It is not a first cut based on theoretical allocations; it's a first cut based on time reporting allocations of what people say, what projects people are attributing their time to, and where those projects fit in the service areas of ARIN.
So I hope this has been helpful, and hopefully this will facilitate discussion.
That's all I have. Thank you.
The last report we have for the day is the Board of Trustees Report, and that will be Tim Denton, Chairman of the Board.
Tim Denton: Thank you, all. This report will be as dry as dust.
Board activities since ARIN XXVII in San Juan. So this is vastly exciting. We revised our bylaws to two effects. First of all, we clarified the process whereby the vice chairman is appointed, and that is to say that the Board has the first dibs on nominating the vice chairman.
Secondly, in relation to Registration Services, we reviewed the draft legacy arrangements and basically increased or clarified the rights of the legacy holder, including the right to transfer his own numbers.
As matters of — because we're required to do this, we have impaneled additional 2011 Board committees, one a nomination committee and, secondly, a fellowship selection committee.
We reviewed the 2012 budget, we've reviewed the long-term financial model, and we've reviewed the functional area cost model.
I just would like to point out that these headlines cover a great deal of work and thinking.
I think the things that are of most importance for you people to know is that we have reaffirmed the strategic direction, which is that we will maintain IPv6 outreach and education directly and through NRO efforts.
That we will continue to promote the current Internet registry system, and both within and external to the Internet community. And in that case that means in certain cases fighting legal cases to defend it.
Thirdly, we will continue the ARIN Online registry automation efforts.
And, fourthly, we will be working with the network operator community within ARIN and other forums.
Acting on the recommendation of the ARIN Advisory Council, we have taken the following action: We have adopted ARIN-2011-3: Better v6 Allocation for ISPs; we have adopted ARIN-2011-4: Reserved Pool for Critical Infrastructure; we have considered ARIN-2011-5: Shared Transition Space for IPv4 Address Extension, which we have taken under advisement pending an IETF consideration; and we have adopted 2011-6: Return of IPv4 Addresses.
We have inserted this in the last minute, but we wish to assure you that we have heard and heeded the concerns of this assembly regarding the priority to be assigned to Whowas.
And that, my friends, constitutes the report.
Would you like to ask any questions? Thank you all very much.
John Curran: Okay. I'd like to take this time to turn it to Open Microphone. This is the opportunity to ask questions on anything that has not come up to date, other matters, policy development discussions that might have gone over.
The microphones are open. I will remind people that some of us are expecting to have other meetings at noon, but we'll entertain questions for as long as we can.
Center rear mic.
Aaron Hughes: Aaron Hughes, 6connect. After listening to this discussion about software development, I thought it would be useful to suggest that at joint NANOG ARIN meetings ARIN host a track or session or working group on the Wednesday where we can have both policy ARIN members and operator needs in the same room, and in a different format than the typical ARIN announces what they're doing, but rather a request for input from the whole community as to what might be useful.
While listening to things like demand for Whowas, which I certainly appreciate, I think that we're missing quite a few things, some of which belong in the open development/open source community and some of which probably should be better written and commercially supported.
I have a short list of things, but I'm noticing that the list is getting bigger and the load is probably high on ARIN and that must be very challenging, and I would suggest a forum for that discussion.
John Curran: I think that's a wonderful idea. We attempted to start that this week. We had a — specifically a user — I believe a user feedback forum —
John Curran: — ARIN Online user forum Wednesday night where we solicited feedback specifically — Wednesday or Tuesday? I'm sorry.
John Curran: Tuesday — Tuesday evening where we told people come and give us your feedback on our automation, our work, everything, our services, and it was lightly attended.
Aaron Hughes: Unfortunately, at least in my opinion, the words "ARIN Online" mean something very different than software development and exclude things like RPKI tools, IRR tools, ARIN REST documentation, et cetera.
John Curran: Good feedback.
Aaron Hughes: Has a negative stigmatism and probably doesn't promote the kind of people that you want in that forum.
John Curran: Okay. Got it.
Vint Cerf: First of all, I really appreciate the suggestion. Secondly, your observation is clearly underscored by the light attendance at that meeting. I did attend that.
One thing I would like to suggest is that if we have discussions about what's needed, we somehow will get that documented in a way that doesn't get lost just in the oral exchange.
The reason is that it's not just ARIN that could be developing some of these things. And I'm a big fan of trying to get in front of people things that the community needs that others might be willing to either develop or help fund the development of. Those ideas could really be helpful.
Aaron Hughes: Absolutely. I just want to make sure that it's not based on squeakiest wheel. In other words, you know, for example, if I'm looking for API documentation, if I'm the loudest, I don't want that to be the highest priority; I want some way of getting input from the community as to what's most important.
John Curran: We've gotten some of that today.
Kevin Blumberg: I've been doing software development as part of my company for 15 to 17 years. During that time we've had a bit of a niche with not-for-profits.
We've received many not-for-profits' RFPs that have come through our place, and we generally try to quote them as low as we can, and in some cases we have sent out quotes that were at cost because we felt that it was important to that.
And we have lost those RFPs to other companies who have said not only are we going to do it at cost, for marketing reasons and for goodwill reasons we're going to do it well below cost.
You need to allow your RFPs to go out to the broad community as much as possible, because you will be amazed at the help and the resources that the community is willing to provide to ARIN for its projects.
But if we don't know about the projects, we can't quote on the projects; we can't help you on those projects.
John Curran: Agreed. May I ask a question just to understand? For the substantial work that we've done over the last two or three years, it's been basically redoing the core of ARIN and including rebuilding the linkages for things like templates and everything that people expect.
While I'm a big fan of contracting and then, beyond contracting, actual outsourcing, there are some things that we probably wouldn't have RFP'd just because the life of the organization is on the line if we get it wrong.
And so are you talking about doing — considering RFPs and outsourcing for things that are identifiable discrete services or for our ongoing internal core?
Kevin Blumberg: As Aaron brought up, there are a number of projects that are not necessarily core projects —
John Curran: Got it.
Kevin Blumberg: — as well as I hope with the redesign you have allowed the system to be modular enough that an external company can work on a component without affecting your core.
John Curran: Now, yes; before, no.
But yes. Thank you. Good feedback.
Open Microphone remains open. Far left.
Bill Darte: Hi. This is Bill Darte, ARIN Advisory Council and Washington University. Three quick things. One is, you know, I was honored to be a mentor of a fellow in the Fellowship Program again. And while I think that's a really valuable program and the amplification of what we do and all of that is valuable, everybody in here knows somebody that they could bring along or encourage to participate in a meeting or on the PPML or whatever, and we'd get amplification well beyond the Fellowship Program if everybody would do that.
So I encourage you all to think about inviting some colleague to be engaged.
The other thing is just a thanks to the ARIN staff on putting a really great meeting together again.
And, finally, to Dan Alexander, who can't be here, our colleague on the Advisory Council, who I'm sure sweated a lot in getting this all going, this meeting here in Philadelphia, our thoughts go out to him.
And thanks to Comcast in general for their support here.
John Curran: I will be closing the Open Microphone session. Microphones are closing. Three, two, one. That concludes the Open Microphone session.
John Curran: This concludes ARIN's meeting in Philadelphia. I'd like to thank everyone for coming. It's been a wonderful meeting, and I look forward to seeing you early next year in Vancouver. Yes. Thank you.
[Meeting concluded at 11:55 a.m.]