ARIN 33 Members Meeting Transcript - Wednesday, 16 April 2014 [Archived]

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

Opening And Announcements

John Curran: Good morning. If everyone will come in and get settled, we’ll get started. I would like to welcome everyone to the ARIN Member Meeting taking place in the beautiful city of Chicago. Everyone should - real city, fun place, lots of good things to see.

We just have 12 more policy proposals to go through today - no, I’m sorry, that was yesterday. We have the Member Meeting today, which is discussion of how ARIN’s doing, our organizational reports. We also have the global reports coming up.

So today global reports: IANA, RIPE, LACNIC, and APNIC. We’ll give a report on developments in their regions.

We have a Fee Structure Review Panel Update, Registration Services Department Report, the Engineering Department Report. We will have a break briefly. We’ll come back and have the AC, the ARIN Financial, and the Board of Trustees Report. We’ll end with an Open Microphone, and that will be it for the ARIN Member Meeting.

Rules and reminders: Again, the chairs will moderate the discussion. Please state your name and affiliation when you come to the microphone. Please follow the courtesies in the program.

At the head table I have our Board: Bill Sandiford; Tim Denton; Paul Andersen; myself, CEO; chairman Vint Cerf; and Bill Woodcock.

Okay. Let’s get started. The first thing I want to say is the global reports, we’ll have Elise Gerich come up and give the IANA report.

Global Reports: Internet Assigned Numbers Authority (IANA)

Elise Gerich: Good morning to those who finished breakfast and thanks for being here. Someone’s raising their hand. No breakfast?

Anyway, this is our regular IANA report to ARIN. And what I’m going to mention is audit, we’ve had a couple of audits this year, and then about our performance standards and where you can find them online.

Also, there’s been the new gTLDs. We’ve more than doubled the number of gTLDs that exist in the Internet right now. And we’ve had our second customer service survey; give you a report on how that turned out.

And finally just mention something about trusted community representatives and how they play a role in the DNSSEC key signing ceremonies.

So basically we’ve been doing this - “we” being the IANA department at ICANN - have been doing this role for almost 16 years, maybe 16 years.

And in the last four years we’ve had an audit of our DNSSEC capabilities. And that’s a SysTrust security audit of the DNSSEC functions that we run, and we’ve passed those successfully. That’s called a SOC 3. Now, if any of you are financial people, you’ll probably know what SOCs are. I didn’t really know that before, but they’re different audits. The SOC 3 you get a report that says yes, you passed, or you failed. Actually, you don’t get anything if you failed.

So we’ve gotten - we’ve passed the SOC 3 reports for the last four years. And we just had this year’s report, and we passed that also. So we’ll be publishing that online.

This is the first year, however, that we’ve done a SOC 2 report for the SysTrust systems that we run for the IANA functions themselves. Those are like our trouble ticketing systems, the root zone management system, the other systems that we use for performing a function.

SOC 2 is different than a SOC 3. The SOC 2 actually gives you a very detailed report, and it’s many, many pages. And it usually is not published. Anyway, we’ve just received that also and we’re going through it. We’re very happy. There haven’t been any exceptions - anyway, no exceptions that we didn’t expect. And we passed that successfully also.

As for performance, one of the things that we’ve been doing for years but we haven’t always published, and everybody always asked, well, how do you know you’re doing a good job. So now we publish these performance reports. And we have a bunch of them, and you can find this on this URL, iana.org/performance.

These performance reports take many different forms. One of them is performance standards. And we did some public consultations about a year ago. In those consultations we asked you all what are the important things about our performance, what do you think we need to do well.

There were two primary things that you came up with. One of them is timeliness; that we respond to your requests and the service in a timely manner. And the other is accuracy. If you ask for something, we give you something you asked for; we don’t give you something you didn’t ask for.

So these are the types of performance reports that we have online. And we put them up there monthly, and this month’s report for March - we’re in April, aren’t we? - the March report should be up shortly, because they’re always done on the 15th of the month.

Another report, which you can’t read at all, is an audit report. We call it an audit report. It’s a monthly report of every change in the root zone that we do.

And so this gives you a little sample of what those changes look like in that long list that you couldn’t read on the previous slide.

So this is an audit report. These three examples show that it’s been completed and what was completed and on what date. There are also line items in this report that says it was withdrawn. It could be withdrawn because the requester withdrew the request, it could have been withdrawn because there was no activity for a certain number of days. Usually it is a lot of days, if we withdraw it for that.

So, anyway, you can go online and you can see exactly what kinds of changes we did in the root zone.

The other thing that’s been going on are the delegations of new generic top level domains. As you all may have known, and it’s not as much of interest to the ARIN community as it is to some of the TLD communities, there are about 1400 applications for new gTLDs that were accepted, and they’re now all going through this process to get them to the point of being put in the root zone so you could actually have domains and query one of the new domains.

So we’ve delegated approximately 220. We do almost 10 of them a week. It was starting out very slowly. We did a couple a week, then four a week. And sometimes we have little spikes. But it’s averaging out to about ten changes a week. And it takes about ten days to do a gTLD delegation. And this has to do - some of them come through in two days and some take up to ten days. So it’s about an average.

But it’s very different than a ccTLD delegation. A ccTLD delegation can take upwards of 120 days, 300 days. There have been some that have taken two years. And that’s because in the gTLDs, a lot of the requirements and criteria are met in the application phase when it’s a contractual requirement that you do certain things. In a ccTLD delegation, it’s starting from scratch, and we have to go through all the documentation and the requester has to start from the very beginning.

Finally, we’ve done two customer surveys. And Leo Vegoda you know very well and is here today has been the lead on these customer service surveys.

We’re pleased with these results. As you can see, we do have a few areas for improvement. We have those little red bars. Timeliness, we said that’s one of our performance standards that we work at.

Well, we were measuring timely based on meeting a certain criteria of what’s timely, within a certain number of days of doing a request or a certain number of hours. Timeliness on this report is about what you think is timely and not what we think is timely.

So obviously there’s still some room for improvement on timeliness.

And then I just wanted to make a note about the trusted community representatives. Whenever we have a key signing ceremony for signing the root, we have representatives from the community who come and participate in that. They’re a very important part of this performance. And these people have done this as a volunteer job for - I guess it’s now over two years. And some of them are finding it to be a financial burden, as well as some of them are ready to resign as volunteers and do something else with their lives.

So what we did is put out a public consultation to see what the community thinks, you all and others in the community, should be the roles of the trusted community representatives and what their terms should be, how often they should be replaced or renewed, and if they should get compensation for their expenses.

So we have closed this public consultation and we are reviewing those results, and we’ll probably be making some changes to the way trusted community representatives are compensated as well as how they’re selected and how long they serve in their terms.

And that’s all there is to say about the IANA functions at this point in time. If you have any questions, I’d be happy to take them.

Vint Cerf: This is not a question, Elise, it’s just a thank you for doing a good job. (Applause.)

Elise Garich: Well, thank you, all. And I want to make sure you recognize Leo and everybody back in L.A. that really makes this all work. Thanks. (Applause.)

John Curran: Very good. Next up we have the report, global report, from RIPE and Andrew.

Global Reports: RIPE NCC

Andrew de la Haye: Thank you, John. Good morning. Here’s my update on RIPE NCC. There’s actually - I just got a couple of slides on topics I’ve seen over the last two days, so here we go.

Busy times. We have a lot of - lot of new members coming in after runout. We have about 10,000 members, even over 10,000 members at this stage.

We’re expanding regionally our presence, and I’ll go into that a bit later. IPv4 transfers increasing a lot. We see quite a lot of transfers happening in our region.

IPv6 gaining momentum as well. We are improving the contact methods and our RIPE website. That is something that came out of our member survey, and again I’ll go into that a bit later. And we see an increasing complexity. That’s actually something that’s quite new for the organization.

We see an increase in ticket load, but those tickets are also becoming more complex. We see more hijackings. We see difficult cases, lots of transfers with difficult business constructions we have to deal with, and that increases the complexity tremendously.

So expanding regionally. We established the office in Dubai in 2011 where we sent Paul Rendek. And actually last week or two weeks ago we opened the office - a new office building in Dubai, Media City. We have two Arab speaking staff members on board, and they’ll facilitate and discuss certain topics in their region, specific to the region.

The idea is to be closer to the Arab community and to fulfill their needs. And it’s not being an operational office; we just do the PR related matters and ER related matters in that office.

We also are hiring two staff members in Moscow, with the same intent.

IPv4 status. Well, interesting enough, we have a last /8 policy which allows new entrants to get a /22 or our current members to get one of the /22s. It’s about a 1,024 addresses, and there’s also a bit of address space which is reserved for Internet exchange points.

About one third has been handed out of this address block. So that means we have about 3,000 /22s we handed out from which two thirds is new entrants and one third is new members. There’s still discussion, and we still see lots people not knowing that they can get this free, so to speak, /22, and we’re increasing the external relations team, the messaging around it.

Our current poll is still similar to what we had when we ran out, actually. So it’s close to a /8, because we’re also reclaiming. The amount of address space we’re handing out is less than we’re reclaiming at this stage.

IPv4 transfers. Now, especially in February we saw quite an increase where we’re at about 50 transfers a month, which is around 500,000 addresses. I looked into the statistics this morning, and for April we’re already on 30 transfers. So we certainly see an increase in transfers, which is actually something that comes out of policy because the policies in our region are relieving many difficulties that were standing in front of on transfers. So that helps.

We also track the mergers and acquisitions which we see in our region to see whether they actually change. And one of the fears we had was that policy was too hard to do a transfer and that we would see more mergers and acquisitions because of that. But that trend is not visible in the statistics, so actually the market is fluid enough at this stage to allow for transfers.

One slide on IPv6. We see an increase, quite an increase. About 70 percent of our membership has an IPv6 allocation or assignment.

We also see - that’s the red bar - it’s about 3 or 4 percent of organizations that only requested a v6 block, but have to admit those are legacy space holders that already have v4.

Then something new to us as well. We see an increase in hijackings. And that is very worrying. So hijackers are trying to obtain control over unused addresses. They mainly focus on legacy addresses, of course, and some PI addresses as well. They’re faking registration papers, identity papers. They’re faking entire websites and domains. And if we see that happening, we go to the authorities and talk to them about it.

But it is difficult. And it’s also difficult for our team to cope with. So we’re even thinking of having a forensics team within the Registrations Services department that certainly deals with these facts specifically.

Another item on this is we have to do our due diligence, and there’s lots of discussion in the RIPE region on how much due diligence we are doing. And for us it’s very difficult to find the right balance between doing due diligence and being overly bureaucratic.

So that is something we’re trying to focus on also at the next RIPE meeting, to explain what’s going on and to also explain that we’re trying to make sure that we secure the resources of our members. And that’s not being bureaucratic for our own sake.

We also make sure that we explain what people can do against those hijackings. And the main thing which we focus on is making sure that all your registration data is up to date, up to scratch; that people can see that you’re actively managing your resources as an LIR. For example, also creating a certificate for your resources.

An additional step we’re making, and we call it Assisted Registry Check. It’s a new process we put in place, is that we actively approach all our members every third year, and we go through registration consistency checks, resource consistency checks, and root and reverse DNS consistency.

The thing we do is we send them an email, give them a call, say: We’d like to discuss something with you about the quality of your information, and we’ll come back to you in a month. We’ll make a report about all these topics.

You can think about legal name and addresses, postal addresses, IPv6 holdings, IPv4 holdings. We provide all that information to them so they can go through it. And then we do a conference call with them after a month. And where we see issues or where they have issues we help them improve in their data set.

One of the things we also do is looking at their network reachability through our Atlas project, which is also an additional value to them to have somebody looking from the outside to their organization and trying to improve their reachability.

RPKI. RPKI is really moving forward in the RIPE region. We have about 2,000 members, which is 20 percent that requested their certificate. Getting a certificate is really easy action. It’s a one-click movement. But what we also see is that we see a lot of ROAs being created. That is something you actually really need to know what you’re doing. We have 1500 unique ASNs with ROA and about, well, in total 7,000 IP prefixes being certified. And for v4, for example, that’s more than six /8s in work around space.

So that’s really, really going rapidly and going well. And we also see people starting to use it in their daily operations. So we had a request from one of our members that said, well, can you please help me going through the process of creating a ROA because one of my peering partners expects me to have a ROA before they allow us.

So that’s actually nice to see that all the efforts we are trying is paying off at this stage.

From a functionality perspective, we make sure that all the address space is eligible for certificates. So we have its issue with PI and legacy resources. PI we finished, actually, and legacy space will after the RIPE meeting, so end of Q2 legacy space will also be certifiable.

Our RPKI software is open source, and we’ll improve that. And we’ll also make sure that’s a standalone package which can be used by anybody that likes to run a CA.

And we’re going to work on the resiliency of the system, so having multiple duplication points, et cetera.

One short slide on policy, because Einar already gave a bit of an update. I think the interesting thing is that the main theme in the RIPE region, if you look at all the policy changes that are currently in the Policy Development Process, are about registry quality and reducing of bureaucracy.

So the aim of most proposers is to make sure that, one, the market is more fluid so that it’s easier to transfer resources, but by allowing that, that is also easier for people to tell the RIPE NCC and the registry that they’re transferring addresses, which then is actually quite good for the quality of the registry and keeping up with the quality of the registry. And these are two policy proposals that are examples of those.

Outreach. I won’t go into too much of outreach because John already had some information on that yesterday. We do a lot of governmental roundtables, law enforcement meetings. Our main focus remains with the IGF, and we have quite a team working on that. And NETmundial, for example, actually going there as well.

Finally some operational improvements we’re working on. We also have a member survey. What we always do - so we do that every second year, we create an action list for the year to come. So we created 50 actions which all focus on making sure that all our processes are being improved and become easier for our members.

So currently a few things we’re doing is investigating supporting more languages. We are a region of 76 countries, or 74, 77, depends a bit per day. But that is something we see where there’s lots of questions on.

More contact with our membership. So small scale events. All our regional meetings and dinners and lunches we have with our members contribute. We also give lots of training, 150 trainings this year in our region in about 50 countries. And next to that we do, for example, 50 webinars. So we’re really very close to our membership, knowing what they want and what their needs are.

We’re working on advancing capacity building, introducing technical hands on IPv6 training, a three- and a five-day course. We’re improving our elearning platform to allow easier access to it. And we have IPv6 road shows, especially in the east of our region, where we talk to governments about v6 and how to implement it and how to support the ISP community to implement it.

And finally we’re collecting input on our website because that is due for improvement.

This is the last slide. Last but not least. We have a RIPE meeting, RIPE 68, in Warsaw. 12 through 16 of May. With a big change. And the change is that our dear chairman, Rob Blokzijl, after 25 years is stepping down. And he will be followed up by Hans Petter Holen, also a very well known and very well respected person in our community, and he’s going to take over. So that’s a big event at the next RIPE meeting.

John Curran: Can I ask for can you go back one slide? Can I ask for a round of applause for Rob and his efforts over the years.

(applause)

Andrew de la Haye: Thank you, John.

That’s it. Any questions?

Discussion

Vint Cerf: Thank you for the report and for all the hard work. I was trying to do a calculation on your assisted registry check, and if you have 10,000 members and you do this once every three years, that’s 3,000 a year, which sounds like 15 a day, which sounds like a really heavy load, is that really what’s happening.

Andrew de la Haye: That is what we’re intending to do. That’s right.

Vint Cerf: Okay. So second question. With regard to RPKI - and this is where I get to show my ignorance - there was a time when RPKI looked like it worked just fine if you were an edge network and you were making announcements and people could look in the RPKI tables and say, yep, it’s okay for you to make an announcement. Then when you get into the middle of the net and you’re announcing stuff that isn’t you, it’s coming from other ASNs, did we get this right so that the RPKI check can be done properly, even if the announcements are being made in the interior of the net.

I don’t know if that’s a well-formed question.

I see an explosion down there at the other end. There’s a levitation. Are you going to respond to that? Is it all right?

Andrew de la Haye: Let’s see what the…

Vint Cerf: This is Sandy from somewhere. Is it okay? I apologize for jumping the queue, but she looked like she was going to explode if she didn’t respond.

Sandy Murphy: Sandy Murphy, PARSONS. The RPKI presently has the information in it necessary to verify the origin of a BGP route. Anyone can check this - at the edge, in the middle, anywhere - can check the origin.

The entire path validation is something that is still under work in the CIDR working group. So right now you can check the origin validation but you have no idea if someone’s added it on to the end of a bogus path.

Vint Cerf: Thank you very much.

Leo Vegoda: Leo Vegoda from ICANN. In your section on RPKI, you said that creating ROAs was difficult. And I know that the RIPE NCC has BGP measurement and it has a very popular routing registry. And at one time there was a service where the RIPE NCC would offer to go and say: This is what we see in BGP, this is what’s in the routing registry; do you know there’s a difference.

And I was wondering if, when you have the tool to create the ROA, you could go and say we see this in BGP, we see this in the routing registry; which of these do you want for your ROA.

Is that how it works?

Andrew de la Haye: More or less. It’s not very complex. And there’s a wizard that guides people through the process of creating a ROA. But getting a certificate, from their perspective, is way easier. It’s just one click; I want a certificate.

If you want to create a ROA, you have to think. And that’s basically what I want to say. Because it is a bit of a difficult concept for many people. So there’s a wizard that guides them through it.

One of the things which is up for Q4 this year is to make sure that we are going to create a link between the routing registry and certification from both sides. So that’s what we’ll be working on in Q4 this year.

Leo Vegoda: Perfect. Thank you very much.

Sandy Murphy: Sandy Murphy, PARSONS. As the CIDR working group chair in the IETF, I really appreciate the fact that the RIPE community is partaking of the certification provided by RPKI. So kudos.

I noted in your discussion of the consistency checks that are done in RIPE, and I was thinking of the discussion yesterday about whether ARIN monitors whether address space which has not yet been allocated is appearing in the routing system, and I was wondering if that’s anything that you’re doing or whether you’re just checking allocated and currently routed.

Andrew de la Haye: The latter, yes.

Sandy Murphy: I’m sorry, say that again.

Andrew de la Haye: The last part.

Sandy Murphy: Thank you.

John Curran: Anything else? Okay. Thank you.

(applause)

John Curran: Okay. In our global reports, next one up is LACNIC and Sergio.

Global Reports: LACNIC

Sergio Rojas: As I think we have five minutes, it will be fast and furious. So my name is Sergio Rojas from the regional service of LACNIC. And here in this slide you can see the evolution of our membership since 2012 - sorry, two. As you know, we have two NIRs - one in Mexico and the other one in Brazil. And included in these NIRs we have right now 3,556 members.

This is the graph of our free space in our IPv4 pool. We have runout points, 72 /8, a little bit more than 12 million addresses, and according to our prediction, we think we will reach the last /9 at the end of this month. And we will reach the next - sorry, the last /10 at the end of May or the first days of June.

So at that moment some policy will activate it. And we will reserve two /11. The first /11 is for soft landing. This, the service space, an organization can request additional space each six months. And in the next or in the - yeah, in the second reserve, or a /11 reserve it, it will be just for new members only, where an organization can receive just only one allocation. And the maximum allocation that - in both blocks, the maximum allocation that they can receive is /22 and the minimum is /24.

So in this graph you can see during the last 12 months we almost reached 2.5 /8 in allocation of IPv4.

Of these 3,556 members, 2,326 members has IPv6 allocations. That’s a good number. And it represents the 65 percent.

During 2012 we have allocated 578 IPv6 blocks. In 2013, so last year, we can see here almost 100 more, 670 IPv6 allocations. And this year, so far, we have allocated 263 IPv6 blocks.

So, as I mentioned, we are reaching the last /10 this year, shortly. And we started this year to visiting our members, especially big ISP and governmental organizations, and we have visited nine countries where almost 15 people of the LACNIC staff were involved. And the object of this project was tell them about the IPv4 exhaustion. Even though we have announced this more than one year ago.

But, anyway, the objective was have a face to face meeting with them, tell them about the IPv4 exhaustion, when it will be and how can we help them in the IPv6 transition.

So some of them were surprised about it: Oh, May? It will be May? And after that, we know that we have received some unusual requests. So asking, for example, big space or the double space that they normally request.

But it was just some of them. My apologies about this picture because it’s not so clear, probably. You can see very good the lines, but we are working to change the color of this slide.

But in this website you can find our complete report about our RPKI project. And now we have 1,105 perfect segments, and the percentage of the total allocation is 70 percent, well, covered by ROAs.

Well, anyway, if you visit the website, you can find many a report about our RPKI project.

Ayitic Program is one of our social programs developed to help to the Haiti island after the earthquake that they had some years ago. They still are rebuilding their country, so that’s why we decided to raise this project. And we organized our workshop and we’re training them in IPv6, network security, wireless connectivity, and YP and it was just for local people.

But these are the people who attended this presentation or this workshop. And for this year we are planning to have a second edition of this workshop. It will be in August of this year.

Our previous meeting was in Curaçao in October. In the Public Policy forum we had five proposals. Just one of them reached consensus, and it was about principles governing the distribution of Number Resources, and it was approved and implemented right now.

Our next meeting will be in Cancun. So in a couple of weeks. So all of you are invited to participate in this meeting.

So great news. LACNIC is ISO 9001 certified company. And in October of the last year, we got second position of the great place to work in Uruguay.

(applause)

Sergio Rojas: And that’s it. Any questions?

Vint Cerf: I can’t resist. This 9001 thing, if you look carefully - and I hope you’ll forgive me for making this observation - what they do is reward you for documenting your processes really well, even if they’re crappy processes. If you do a good job of documenting, then you get a little check mark. I hope your processes are really good, too, on top of everything else.

Sergio Rojas: Thank you very much.

(applause)

John Curran: Our final global report will be APNIC. Guangliang.

Global Reports: APNIC

Guangliang Pan: Good morning, everyone. I would like to give you a quick update on what is happening in the APNIC region.

Recently we reviewed our vision: A global, open, stable, and secure Internet that serves the entire Asia Pacific community.

This is our new vision. And we focus on three areas: serving APNIC members, supporting Internet development in the Asia Pacific region, and collaborating with the Internet community.

So in my update I will highlight some of the activities which we are working on these three areas.

This graph shows APNIC is part of the Internet community. So we collaborate with the Internet community. And we also support the Asia Pacific region, and we service our members by providing restriction service, IN-ADDR service as well.

And here’s our mission. We also reviewed APNIC’s missions. The key point is to function as the RIR for the Asia Pacific, in the service of the community of members and others, and provide Internet registry services to the highest possible standards of trust, neutrality, and accuracy.

And let’s talk about the service of APNIC members first, and I will show you some statistics to see how the resource allocation in the APNIC region.

This is the total IPv6 allocation since 2009. You can see we’re going up. And this is the year-by-year allocation of IPv6. And we have a peak delegation in 2010. At that time we’re talking about v4 running out. So there’s a lot of members that get v6. And then after more members received the IPv6, then the number delegate by years, it slowed down.

And these are the last /8 delegations. We have about over 100 delegations from our final /8 per month. And that will be very interesting to look at the IPv4 market transfer. And since we run out of v4, like head to the final /8, the final IPv4 transfer is happening and you can see the increase.

And especially the inter RIR transfer which related to ARIN region, and so far we have more than 30 transfers from ARIN to APNIC. And this is the AS number delegations and also we have increased delegation of AS number. Means we have more new members.

This graph also is saying APNIC has more like increase of new members after the final /8 and small organizations like if they come to APNIC to get the /22. So we have more new members.

And we also improve our Whois update and Whois service. And MyAPNIC - MyAPNIC is a member portal for APNIC members, and we also improved the service.

And we send a - we have a referral application. What that means is that our members can help their customer apply APNIC membership and resource, because we are like in the final /8 stage. And most of the large ISPs, they don’t have IPv4, their customers, so they can’t help the customer become APNIC member and get a /22.

So in MyAPNIC, we apply the function so allow our members to help their customer to acquire membership and resource. But of course the member - the customer have to confirm that and then become a formal APNIC member.

And now I talk about the support Internet development in the Asia Pacific region. And we have a lot of activity in this area. Policy development, IPv6 support, training, APNIC events and infrastructure, capacity building, and also ISIF.

And in 2013 we have implemented policy that’s changed, APNIC Policy Development Process. And we implement a new policy is called AS number transfer. Actually happened yesterday in Australia time. But today in American time, 16 of April, which we are now AS number transfer between APNIC account holders and also are now inter RIR transfers, if any other RIR have that AS number transfer policy, we can change the AS number between APNIC region to your region as well.

And we’re going to implement Policy 105, is distribution of returned IPv4 address space. This will wait until IANA bill that recover pool. And we expect that happen end of this month, as likely it will hit to /9, that trigger the IANA which build the recover pool. So this probably happen very soon, in the last few weeks.

And policy proposal at APNIC 37, we have three policy proposals, but only one reached the consensus. It’s the one like allocated 1.1.10 /24 and 1.0.0.0 /24 to APNIC Labs for research. That is the one reached the consensus. Other two didn’t reach consensus.

We also provide strong support to IPv6 development. We have a lot of outreach going to different UNs to provide our trainings. And we also - APNIC is a secretary of AP IPv6 task force, and we provide secretary service. And we also have a lot of sessions for like decision makers.

And trainings. We provide IPv6 training and other trainings in our region. You can see the map. We provided many trainings in our regions.

And APNIC UN. We have APNIC 36 and APNIC 37 recently. And also we supported infrastructure building in our region, like those root server IXP.

And ISIF. We also provide some small fund to those projects developed in our region to support the Internet development.

And now we talk about collaborating with the Internet community. APNIC as an RIR, we work closely with other RIRs to engage with the whole Internet community. And we have APNIC Labs to provide measurements to IPv6 developments. You can actually go to the APNIC Lab, they have a lot of statistic, data, measurements that you can check. And we also engage with the community, technical community, Internet governments.

And now the IANA transition is a hot topic. So we will work closely with the Internet community, and we would like to see a good result on that transition.

And, finally, I would like to invite you to APNIC 38. That will be in Brisbane, which is APNIC office located. So you’re also welcome to visit APNIC office if you like to join like APNIC 38.

Okay. Thank you very much.

(applause)

Discussion

John Curran: Any questions?

Scott Leibrand: One comment. Thank you for the updates. With regard to ASN transfers, I think it’s worth reminding this community that we had a policy proposal to allow inter-RIR ASN transfers about a year ago. That was abandoned by the AC because at the time there were no policy proposals anywhere else to support that. Obviously that has now changed.

So if anyone in this community believes it would be useful for us to support inter-RIR ASN transfers in order to be compatible with the recently adopted APNIC proposal, it would be wise to submit a policy proposal. And I would be happy to help anyone with that that is interested.

Sandy Murphy: Sandy Murphy, PARSONS. This is me exposing my ignorance. I know enough about the APNIC region to know that there’s a very strong NIR structure under the APNIC banner. So how does that work in terms of transfers, if ARIN transfers things to APNIC as their designation of which NIR goes to do the inter-RIR transfers process, manage the inter-NIR transfers? This is just plain curiosity on my part.

Guangliang Pan: I can answer that question. Inter-RIR transfer can still happen between NIR and ARIN region. So far only ARIN region and AP region have inter-RIR transfer policies. So if an ARIN member want to transfer a /16 to APNIC NIR members, like CNNIC member, under CNNIC, ARIN still talk to APNIC, and then we talk to CNNIC. And then we transfer to that CNNIC member. Some things can still happen, yes.

Sandy Murphy: Okay. So is the inter-RIR process what governs inter-NIR transfers, or is that something different?

Guangliang Pan: NIR have option to attempt IPv4 transfer policy. This is the only policy that NIR have optional, actually, at the time they proposed the policy. That is some of the NIR actually they didn’t attempt that transfer policy. In that case the NIR is not allowed to do the IPv4 transfer. And that is - they do change from time to time some of the NIR - I think more than half they actually accept that transfer. But still some - only two nowadays have attempted policy. They may change in the future. They discuss it.

Sandy Murphy: Thank you.

Guangliang Pan: Thank you.

John Curran: Thank you.

(applause)

John Curran: Okay. We have next up is the Fee Structure Review Update. I will do that.

Fee Structure Review Update

John Curran: So Fee Structure Review Panel. Last year in April we chartered a Fee Structure Review Panel to consider various long term fee structures that were suggested by the community and to summarize the pros and cons and report back to the ARIN Board and community.

The status is we have an initial draft of that report. The committee is still tweaking it. It’s a balanced document describing each of the various approaches and how ARIN might structure its fees.

They’re significantly different approaches. It’s to be used as a common basis for the discussion of the merits of various approaches. It doesn’t provide a recommendation. It’s when somebody says what about this type of fee structure, okay, here’s what we need to consider.

We’ve also modeled all of these against an actual data set of resource holdings, anonymized from December 2013, so that we can actually see with a specific fee schedule and specific set how does that - what revenue does that produce and how does that spread the expenses across the organization.

It covers seven alternative approaches for recovery of ARIN’s costs across all the contracted parties. And the goal, of course, is to do this in a fair and equitable manner. But fair and equitable is very much a judgment perspective.

There’s 4,500 organizations who are under contract, count 500 legacy organizations, you could take the fees and divide them by just them. You could turn around and say end-users and ISPs should be counted the same and include the 14,000 end-user organizations.

You could say fair and equitable is by address block or fair and equitable is by actual address count. So we all want to be fair and equitable but we actually have to have some way to compare these because different people may have a different view on each.

So let’s talk about what’s in the report. And you guys are going to see it shortly. Not today, because we’re still finishing it. But what we have is seven different proposals, the current fee structure for comparison, and extending IPv4 fee categories proposal. This is so we end up with the - right now our fees top out even if you have the equivalent of - let’s say equivalent of a /9 of total address space. What happens is you hit the maximum XX large category. There is nothing higher. This proposes some more Xs - XX large and huge and extra huge and super huge.

We also have a linear fees category proposal which accomplishes the same thing in some ways. It’s a very straight fee structure all the way up to as high as the possible resources you could hold.

We have a realigning IPv6 category which addresses the fact that at the bottom end of the scale the same fee annual between organizations may imply that a relatively small IPv4 organization either pays more or gets far less v6 resources than they would expect. So we jigger the categories to provide for more v6 resources.

We have one that’s purely algorithmic. Type in your IPv6 holdings look at the log and the square root to the power function and it produces a number. And actually our friends over at APNIC have a similar approach for their fees.

And this, again, is directly calculated off your holdings with a log function involved. We have a membership based proposal, which is very flat, if we include all ISPs and all end-users under contract and we divide out all our costs what would it be, and we have one that’s transaction based. Which is if we take the costs that are somewhat generated by new policies and new requests to ARIN as opposed to sustaining operations and we divide the costs in half and we take the membership and divide the base by that and we charge a transaction fee for you to put in your v4 or v6 allocation or transfer request, what are some typical transaction costs and some typical low level ongoing fees that we could have that apply across the entire community.

Very exciting report. It was an adventure to build. I think it will be useful for discussion. I’m going to talk about how we’re going to use it. But it has been a learning experience for everyone, particularly the modeling of it with the actual holdings. We did an anonymized the data set, as I said, of all the parties under contract and all the holdings so we could do this.

So we’re going to finalize and release the fee structure report. I would estimate that would be the end of May. The panel has to be done with it and they have to give it to the FinCom. We’ll use that. We’ll release that to the community for discussion. We need to talk about where and how we want to have that discussion. We’ll do a fee structure session and discussion at the October meeting here. We’ll actually have a full on let’s discuss the various approaches and do you guys want to change.

If you do want to change, it’s up to the finance committee to take that discussion and recommend do we change from our current approach to some other approach. And then an initiation, whatever the FinCom directs staff and the finance team to develop, that would actually start a discussion after October on the specific direction we take and the specific proposal, just as we did with the last fee change. It took almost a year to take the last fee proposal and finalize it with the community. But first we have to get directional. That will be based on the online community discussion and the on site community discussion that will take place in October.

Panel members. We have the ARIN Board finance committee members, and then we have the at large community members that were appointed to the panel to help work on the various proposals. All these guys have been great. Everyone volunteers. And it’s actually a little bit of hard work to be able to generate these and accurately get them, but we’ve had a very good team.

Discussion

And that’s it. Microphones are open for any questions about the fee structure review panel or the process.

Jason Schiller: Jason Schiller, Google. Mike Joseph isn’t here, so I need to pass on his concern that he always brings up at this point, which is there is a lot of pending development that we would like for ARIN Online.

We’d like to see that be supported and moved more quickly. And if that means increasing our fees, please increase our fees. This work is important to us. We’d like to pay you to do it.

John Curran: Good point. I will say we received that message. We’ll talk about it a little bit more when we talk about the financial report. One thing I probably omitted in this is that the fee structure review, in order to talk about philosophies, these are all roughly revenue neutral targets we’re doing. So each of these structures are designed to generate the same revenue that we’re presently doing.

But I think overall is that the right level of revenue or should we be drawing down the reserves more is a great topic for the finance talk coming up, if that makes sense.

This was predominantly structure, not how big our costs should be, we’re sort of presuming a neutral-revenue and neutral-cost approach. But I got the point.

Any other questions on the fee structure?

Owen DeLong: If the fee structure is to remain in such a circumstance where end-users are being charged more than they were being charged before, in many cases substantially more, I don’t see any reason they should continue to be treated as second-class citizens and subject to a poll tax.

Paul Andersen: I assume this refers to membership.

Owen DeLong: Refers to membership.

John Curran: So noted. Anything else? As I said, our ETA on the report is end of May. I work with a good volunteer team. I can’t commit their time, but we’re in the finalization stage, which is very helpful.

Thank you very much. We’ll now move to the RSD report. I’ll have Leslie Nobile come up.

Registration Services Department Report

Leslie Nobile: I have what I think is a quick update from Registration Services. I’ve entitled it “Trends, Observations & Statistics.” It’s really kind of a mishmash of lots of things we are seeing currently in this pre-IPv4 depletion area, world, if you will.

So we’ll start with some of the trends and observations. The most significant one, I think, is the top one, the increase we have seen in IPv4 requests. We expected this all along with depletion, but it’s now starting to hit. We have seen an 18 percent increase in v4 requests in the past 12 months over the previous 12 months.

We haven’t increased staff, so it’s a pretty significant increase in the numbers. We’re getting over 320, averaging, v4 requests per month at this point.

Like Andrew, just mentioned - I felt like he was doing my presentation when he was up here because so many of the things he had I have in mine, and they’re seeing so many similar things in the RIPE region that we are in the ARIN region.

IPv4 requests are becoming increasingly complex. They’re not the requests of three and five years ago. They’re very complex. This is requiring an increase in the number of back and forth exchanges between the analysts and the requester.

We actually had some numbers - I think that our numbers showed that there was a 16 percent increase in the number of back and forths over the past year. In order to obtain the data that we need to see to validate the requests, we have to ask more questions. And there’s lots of reasons for that, and they’ll come up in this presentation.

We are seeing more potentially fraudulent requests, as you would expect. We see lots of red flags. That makes us ask lots more questions and do lots more research.

An interesting thing is we’re getting more fraud reports from the community through our fraud reporting system that is on our website. And almost all of the fraud reports we are getting now are valid fraud reports. They really concern IPv4 fraud rather than spam and phishing, which is what we used to get. The fraud reports we’re getting are about the requesters that we are seeing currently.

So they’re actually about the open tickets that we’re reviewing. It’s a really interesting correlation. So all of this is requiring more due diligence, more staff time, more back and forth. Just a lot of work to get the data that we need.

We’re seeing a lot more out of region requests. I had mentioned this before in Policy Experience Report. It is difficult to verify the justification for these requests. The obvious thing is language barriers. But there’s more than that.

We have no equivalent way to validate the data that we’re getting. We use obviously Web searches and Web tools, and we can do that with in region requests and we can find what we need about either the requesters, the ISPs, the end users or their customers. We can actually find information about them. We use things like PayPal and even Google Earth. We just use everything available.

But we don’t have that equivalent with most of these out of region requests, particularly those from Asia, which are in a different language altogether. And there’s just no way for us to correlate some of the data we’re seeing or verify.

These requests are coming in frequently. These guys are coming in fast. It’s pretty much every three months, they’re just below three months, and what we’re seeing is rapid growth. They’re requesting more and more space each time they come in.

We are seeing more requests involving new technology and services. Andrew also mentioned this. It’s really interesting. All of a sudden, with v4 depleting, there’s lots of new technologies and new services, new ways of using IPv4 that we haven’t seen before. And some of these are using very large amounts of IPv4 address space.

Transfer requests. We have seen overall between 8.2, 8.3, and 8.4 requests over the past 12 months, a 5 percent increase. Doesn’t sound like a lot. But I probably should have put a graph up, because particularly we’re seeing an increase in 8.3 and 8.4s over the past six months or so and Q1 - a huge increase in Q1 of 2014.

So we obviously expect this continued increase in both transfer and IPv4 requests as we near depletion, and then we expect that increase to just switch over to transfers altogether, 8.3 and 8.4 transfers.

So what’s the service level impact of all this complexity and all this increase in response times, et cetera?

We can measure our response times in our ARIN Online ticketing system; we can’t in our manual system. So when we look at ARIN Online ticket response times, we’ve seen they’ve increased from 1.08 days in 2012 to 1.65 days in 2013. And that’s continuing right now. Some requests, the response times are over two days. Some are under.

We are seeing that the time required to complete an entire IPv4 request from beginning to end is increasing. And when we looked back at Q1 to Q4 of 2013, ISP requests increased. The completion, from beginning to end, increased by seven days. And with end-users, that increase was 11 days.

The end users are a little bit more because they require - include a billing and contract phase, so there’s some back and forth over there that makes a little bit of a delay.

So what are we doing about this? We’re currently reviewing our internal procedures to find ways to streamline processes and procedures. We’ve written a document that identifies everything we do, and we’ve written a recommendation or potential ways that we can improve and streamline and maybe cut some of the bureaucracy while still being able to enforce the policies.

So we have that ready and we’re kind of busy and it’s been hard to really address that, but I am getting back to that. And we will be making changes. We’ve been making some slowly, but we’ll be making more.

So looking at our current IPv4 inventory. Right now we have 1.26 /8s, /8 equivalents. I expect that number to drop fairly quickly, in the next couple of weeks. We’ve got a couple of large pending requests. That number may go down fast.

That’s available. That’s the space that we issue from every day. It’s clean and ready to go to a customer.

We also have reserved inventory. We have 8.88 /16 equivalents in what we call our RRH bucket. That’s basically our quarantine space. Any space we get back we hold for 90 days to clear filters, and then when we are ready to release it back into the pool, we check routing, check blacklists, make sure it looks like pretty clean space, and we put it back in our available pool.

If it’s blacklisted, we actually hold it back and put it back at the bottom of the pile. And a lot of times we’ll contact the spam people, like Spamhaus, and just say: This is claimed space, this doesn’t belong to that person. We just try to clear up the issue.

We have the /10 reserved for the dedicated IPv4 block to facilitate IPv6 deployment, which we’ve mentioned, and there’s also a reserve for the micro allocations, and we have 231 /24s currently reserved still in that /16 that we put aside.

Block size distribution. This is on our website, but to take a quick peek at what our available prefix size is that we have currently. Goes from a low of one /9 to a high of 1219 /24s. We have lots of the smaller blocks, but that’s mostly what we issue. We’re mostly issuing 24s, 23s, 22s, 21s, and 20s.

So our countdown plan. We’re about to move into Phase 4. That happens when we reach our last /8 equivalent. At that point all IPv4 requests will be team reviewed. It will never be a single person reviewing.

The request and the responses are going to be processed in the order that they are received. That’s our version of first in/first out. It’s going to be chronological. Whatever is in the box that day gets processed in order of receipt, whether that be a first time response or a response to an existing request. We have three teams set aside to work this.

We put this into effect about two weeks ago, just to have practice, to make sure we were ready. And we’re actually finding that this team process is very slow. And I’m not sure - we’re not happy with it. I’m sure you’re not happy with it. We’re going to try to fix this if we can.

I need to talk to my RIR counterparts to see if they have any hints because it’s a very slow process, and I know they did team review as well. I’ll try to get something to fix this before we actually move into Phase 4.

The hold period for those recovered resources is going to drop from 90 days to 60 days. So the quarantine space will be held for 60 days before being re released into the pool. And an organization will have 60 days from the approval of the request to complete their payment and/or RSA. If they don’t complete it within the 60 days, those resources will be released back into the pool and made available to another organization.

So those are the changes with Phase 4. Looking at IPv4 churn, mentioning the space that we do get back on occasion, churns up our inventory a bit.

It comes back in three ways. I think you’re all familiar with this, voluntary return, revocation for lack of payment, typically, and reclamation for fraud or business dissolution, which doesn’t get used very often.

Over the years, I guess since 2004, and in the past 10 years, we have received back 3.68 /8s via all three of those methods.

That’s a lot of space. A /8 equivalent was returned to IANA in 2012. So if we’re looking at that burn rate and churn rate, what we’re getting back versus what we’re issuing, you can see in the green and the red, the earlier years we were getting, you know, more than a blip. We were getting significant amounts of space back and we were issuing significant amounts of space.

In the past couple of years we’re issuing a lot less space and we’re also getting back very little space. I bet you can’t see the red lines. I can, but they’re for 2012 and ‘13, but it’s very little. We do get it back. It’s not unheard of.

Our annual burn rate, if you look at this, we had I guess a low in 2003. This is the /8s we’ve issued over the years, a low in 2003 of just over 1.2 /8s to a high in 2009 of just about three and a quarter /8s. At this point, the past couple of years we just leveled off, been issuing just a little over 1.2 /8s. It’s been pretty even.

So moving into how to get IPv4 address space with depletion imminent. We have a policy for an IPv4 waiting list. That starts when ARIN can’t fulfill a justified request. In other words, when we don’t have a prefix size available that someone justifies, they have the option to use this waiting list.

We actually have the software in place. We’re ready to go. It’s all built in. So, anyway, an organization will have an option to specify the smallest acceptable size. If no block is available between their approved size and the smallest size they’re willing to take, they have an option to go on the waiting list.

So filling these requests. We’re going to fill oldest first. It goes back to the oldest request on the list first. So, for example, if ARIN gets a /16 back for some reason, someone returns it or it’s revoked, and the oldest request on the list is for a /24, we will issue a /24 to that organization. We’re going to break the /16, give the /24, and then we’ll have lots of little prefixes to fill, hopefully satisfying other waiting list requests. The policy says you can receive only one allocation every three months.

Specified transfer listing service. This is a service that’s gone into place with the advent of v4 depletion. Currently in existence. Three ways to participate. We have the listers, who have available IPv4 address space; the needers, the people who are looking for IPv4 address space; and then the facilitators who are the matchmakers. They help listers and needers find each other.

Currently we have three listers and nine facilitators and zero needers. What is happening is we have a lot of people coming in requesting to be added to the waiting list and they don’t really know what they’re actually doing. They don’t realize that ARIN has space and that they can actually come to us and apply.

Once they find that out, they drop their request. So we have no needers on the list at this point. I think that will change soon. But for now there are zero.

The major uses are obviously matchmaking, but the thing that isn’t well advertised about STLS is that it’s used as a pre-approval method for a transaction arranged either inside or outside of STLS.

So if you want to prequalify and you think you’ve got your own person, you found somebody that you can get space from but you haven’t really gone through a facilitator and you haven’t really used STLS, you can actually use STLS, the process, to prequalify for the amount of space.

We’re working on the documentation for that. It’s not well documented. We’re actually working - I’m working on creating a separate pre-approval process that we’ll put up on the web page so people can see how it’s done outside of the STLS. Haven’t gotten there yet. That’s something I’m working on.

Pre-approvals are based on the 24-month demonstrated need in accordance with 8.3 and 8.4 transfers. When you come to us and you say, “I want this much space and here’s my 24-month need,” we mark that and we note that, and so that is your approval size. That is your pre-approval size.

Looking at IPv4 specified recipient transfers, I should have done a graph for this, too. This is boring, I’m sorry. But I wasn’t thinking. I know you guys like to see graphs and charts and trends, but I didn’t do that. Right now we’ve completed - since policy inception, we’ve completed 71 transfers to specified recipients, 8.3 transfers.

That encompasses 46,758 /24s and 11 ASNs. What we’re seeing is that these types of transactions are typically arranged through the v4 brokers.

Inter RIR transfers. We show 24 transfers completed as of this date between ARIN and APNIC. I think Guangliang’s number said 30, but I think he’s got some pending on his end. But we’ve completed, between the two of us, 24. That encompasses 2,677 /24s out of the ARIN region to APNIC region. It’s just ARIN and APNIC for now.

The expectation is that it’s primarily ARIN to APNIC rather than APNIC to ARIN, given the early exhaustion in the APNIC region. We actually haven’t had an inter RIR transfer from APNIC to ARIN at this point.

This I mentioned yesterday, I think. This graph is a little out of date. I apologize. It shows the trends; that’s why I kept it in. We actually have 55 percent of our members have IPv4 only and 45 percent have both IPv4 and IPv6. That number has increased. It’s been slow. You can see from 2010 to 2013, Q3 2013, but we are making progress.

And that’s all I have. Are there any questions?

Discussion

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. On the transfer statistics, would it be possible at some point to get a histogram of the prefix sizes transferred?

Leslie Nobile: Sure. Can somebody make a note of that? Because I’ll forget it.

David’s next. Not David Farmer, David Huberman.

David Huberman: In October of 2001, the RIPE community revolted against Axel, Nurani Nimpuno - who was Leslie for RIPE at the time - and the Board. And we revolted because the processing time for tickets was 18 days just for an initial response.

I’m going to come across as a jerk for a minute, and please excuse me, but it’s only because I really care.

Paul Andersen: A minute?

David Huberman: Yeah. Bill, Tim, Paul, John, Vint, Bill, Aaron, I said yesterday the most important thing ARIN does on a minute to minute basis on the network operations is reverse DNS. I stand by that. ARIN does a fantastic job, and has since its inception, doing that.

But the most important thing, I think we agree on, is ARIN provides global unique services to its customers. And right now you aren’t doing it very well. And it isn’t Leslie’s fault and it’s not Leslie’s staff’s fault.

Go back to the first slide, please. I know it’s a lot of slides back. 18 percent increase in 12 months. It was already taxed a year ago. It was already too much. Increase in complexity. Trust me, I know, they were already complex. Fraud, way up. That’s a lot of man hours.

And then please go to the team review slide. This thing is hard. This is very hard. It slows things down considerably. It slows down the initial response. And, most importantly, it pisses customers off big because every cycle ARIN replies, I reply, then you wait five days. Do you know how tough it is to wait five business days in between a response?

It’s not a process problem, in my opinion. I have some experience with this. Yeah, you can streamline a little. It’s a man count problem. ARIN’s got plenty of money. ARIN’s got almost a two-year reserve. You’re looking at fees.

Please, as a member of the community, I implore you: Fix the response times. And if that means more head count, if that means doubling the head count, slightly increasing our fees, as a member of the community, I would love to pay it.

John Curran: So let’s say hypothetically you add head count. Two years from now you’re unlikely to need the same head count. We’re probably not going to go to free pool runout twice. And so we’re really talking about handling a surge condition. The Board beat me up recently saying: If you need to add resources for this, do it.

Leslie knows that that’s an opportunity if we need to use it. But we’re looking at it now. There’s a little bit of a tradeoff here. New staff requires training and ramp-up time. At the same time, the resources are dropping.

So let me say I’m not hesitant to go look for more staff if that’s what it’s going to take to keep these in reasonable ranges. I do think, to some extent, the fraud and the team review imply a level of slower response times even in a very large pool of staff because of the nature of what they are.

So there’s a diminishing recur on adding staff. We will not hesitate to add staff if needed to make this reasonable. We’re not going to let it get out of bounds. At the same time, we don’t want to disfigure the organization for a one-year event. But your message is heard. I just want to point out in some ways we have to take the very best staff we have and divert them to training new staff to make them useful in a period of time that that applies before we get to the point next year where a lot of this may not be applicable.

David Huberman: Real quickly, then I’ll sit down. Totally respect that. Probably should have done that last year.

John Curran: Thank you.

David Huberman: And the problem is right here begins at one /8 equivalent left. All v4 requests are team reviewed. That’s everything. So now that’s a big problem.

John Curran: Right. So let me give you how fast this is coming at us. See that? That’s the actual inventory. And you’ve already got places where there’s a one. You’ve got a places where there’s a few higher counts.

But, realistically, this is coming at us extremely quickly. I do agree we’ll be doing team reviews. I’m not sure if anyone understands we may not be doing any reviews and any processing of new resource requests for very long.

Okay. Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. You mentioned in some of the slides that we’ve seen a large increase in transfers. But when I look at the report that shows the transfers for us publicly, I see five of them in 2014.

Leslie Nobile: Completed?

David Farmer: Requests.

Leslie Nobile: I said there’s been a 5 percent increase over the past previous 12 months of all transfers, two, three, and four, but where we’re seeing a real increase now in the number of requests is Q1. If you look at our stats for Q1, you can see the number of transfer requests in 8.3 and 8.4 have gone up quite a bit. I expect that to continue. That’s a trend that will continue. That’s what I said.

David Farmer: There’s a whole big blob waiting to complete?

Leslie Nobile: Yes, there’s always a big blob waiting to complete. They’re very complex. They take a long time.

John Curran: If you look at the requests, 8.3 and 8.4 requests, in January we had nine and in February we had 11. And March we had 14. That’s going up rapidly. That doesn’t count 8.2s, which often precede and happen at the same time because someone’s trying to validate their resources. We have on a given month 30 some odd 8.2 requests now. That used to be what we got in a single quarter. A lot of documentation review.

David Farmer: Thank you.

Leslie Nobile: Back microphone.

Leif Sawyer: Leif Sawyer, GCI Alaska. On that last slide about the IPv4 and IPv6 net blocks, it may be a little too early to ask this question, but have we seen any IPv6 only - or do we have any IPv6 only?

Leslie Nobile: I used to report on this. I would break it down into IPv4 members with just IPv4, ARIN members with IPv4 and IPv6, and then ARIN members with IPv6 only. I actually added that number. It was 6 percent of the total. I actually added that number into those that have both v4 and v6 because those were in actuality legacy space holders who have IPv4; they just don’t have it directly from us. So you can’t really discount them. It sort of threw them into the 45 percent. Made the numbers look much better.

Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. With all due respect to Mr. Huberman’s comments, I’m of the belief, and Leslie can certainly correct me because I’m sure she knows far better than I, that it probably takes three to six months before a new resource analyst is up and fully processing requests without somebody looking over their shoulder and basically doubling the man hour effort to do so. And we’re probably going to see this surge come to a relatively abrupt end not much further out than that.

So I think we’ve kind of gone past the point where we could address this with more manpower, and I don’t really see a lot of point in throwing money into it.

Leslie Nobile: Could I make one comment? What we’re expecting is increases in v4 requests will shift over to 8.2 and 8.3, so that’s all v4 requests, and there’s going to be a lot of them. That number doesn’t go down for quite some time.

John Curran: There’s two things. One is one thing I would be very concerned about is under no circumstance should this IPv4 slogging get in the way of an IPv6 request, and bringing someone up to speed for IPv6 might be significantly easier and we should probably pay attention to that and make sure that everyone who wants v6 can get them doesn’t need to wait in line because the whole team is busy going through team review of a v4 depletion. We’ll double check on that to make sure.

Leslie Nobile: I think we’ve got it covered. We’re good.

John Curran: The second point, though, is that this is going to move into transfers, and the amount of time it takes to process a transfer is significantly up to the policies set by this community. And so to the extent that that’s something you’re worried about, yes, we will reapply resources if that’s what it takes.

But, at the end of the day, I want everyone to remember that the policies for transfer are not protecting the free pool; they’re doing something else. And you need to decide on the cost benefit tradeoff of whatever else that is that you think you’re doing with the policies.

Leslie Nobile: I think Kevin is next?

Heather.

Heather Schiller: Heather Schiller, Google Fiber. Having recently, last week, been through the process of getting more address space, I wanted to comment that it was timely and it didn’t - it didn’t appear to take any more significant time as long as you have your stuff together and know what you’re doing. So that was fine.

On the other hand, all the other kinds of tickets seem to be taking a lot longer. Like a week to get SWIP approved. Somehow it got flagged for manual processing or something. Things like that. Those are falling by the wayside, and that is frustrating and it shouldn’t take multiple emails and multiple calls.

Leslie Nobile: Next time send me an email directly because I can’t audit that. I would love to know that, if you wouldn’t mind.

John Curran: That’s along with the v6 requests. I don’t intend to have the non-v4 slogging get held up. So we’ll have a discussion about that. That’s something that - you should not have the other ticket category slow down. If you’re seeing that, that’s good to know.

Leslie Nobile: I wasn’t aware of that and I audit every day, so it’s interesting. Good to know. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. You have an ice cream, I want an ice cream, I’m willing to mutually buy this ice cream. I’m confused about the technical complexities of 8.2, 3, 4 transfers. And if they’re extremely complicated right now, how do we simplify them? Because it sounds like you have to ramp up not for end of days with v4, you have to ramp up for the transfer market because every transfer is going to be complicated.

John Curran: Let me touch that one. I want to talk about 8.2 completely different than 8.3 and 8.4. 8.2 is hard. It’s going to stay hard and it needs to be hard.

If you don’t want your resources hijacked by someone, it is important that the 8.2 transfer process is diligent. Because the alternative is that we accept verbal assertions over written documentation regarding what someone claims is their rights to transfer resource.

So but that’s also something, folks, if you are interested, you can do that at any time. If you have records that are out of date, you can come to ARIN and get them updated, even without doing an 8.3 transfer. 8.2 is used predominantly when you have resources in the wrong organization name and gone through one or more things and you haven’t kept up the record keeping.

I’m uncertain of the tradeoffs in 8.2 processing. 8.3 and 8.4 processing are significantly impacted by something called needs assessment. Some of you are familiar with it, and we’ve talked about it over the past two days. And the needs assessment aspect of that is something that the community has indicated it values.

Therefore, we do very much the same processing that’s required for an allocation, and we’re doing it for a transfer.

And you say make it efficient, but we have a very rich, deep, chewy policy manual which people apply to have their need validated against.

Short of a much more streamlined way of evaluating need, as long as there is need assessment and transfers, we are left doing the same processing we were doing before, and you can’t get your ice cream without showing the rest of us that you needed it.

Bill Woodcock: So obviously there’s something that you guys can do to streamline this process and reduce the number of man hours necessary, which is to simplify the policy document.

If the rules you’re applying are more simpler, more straightforward, harmonized and uniform and concise, then fewer hours are necessary to hunt around in them to find something that gets people what they want.

Kevin Blumberg: Just to comment on that. Because one of the things we’ve been discussing over the last two days is operational versus what should be in the NRPM, what should be out of the NRPM.

I believe that over time the community’s view of need, as a word, and ARIN staff’s implementation of need have become more stringent, and I think maybe that needs to be looked at, because I think we are - because of end of days of v4 being too pedantic when it comes to requests in 8.3 and 8.4.

John Curran: We would welcome guidance there.

David Conrad: David Conrad, representing confusion. So I’m actually quite interested in the uptick in the fraud aspects of all of this.

You indicated that you were receiving a large number of additional fraud reports. Can you characterize sort of the distribution? Are you seeing a small number of people reporting a large amount of fraud, or is it a large number of people reporting a small amount of fraud?

Leslie Nobile: It’s actually interesting. It’s not huge numbers, first of all, but it’s an increase in valid requests. So it’s anywhere - I can’t remember my numbers, but 10, 15 a month, something like that. And we’re seeing like three or four reports about the same organization from different people. That’s what we’re typically seeing.

Most of the fraud we’re seeing is reported by more than one organization that appear to be completely separate organizations doing the reporting. I don’t know if that answers your question.

David Conrad: Actually it does. It helps. I would think that in the future, tracking the fraud reports, the distribution of the fraud reports would actually be pretty important because of the likelihood that they are going to increase. I think that will probably inform hiring decisions. And unfortunately my suspicion is the folks you’re going to need to hire are more in the forensic side of things which actually means you have to understand stuff which means they’re going to be expensive and this community is going to probably need to pony up additional money.

Leslie Nobile: Thanks, David. David.

David Huberman: Two fast comments. I wanted to respond to Heather’s comment. It’s not personal or anything. The people in this room, we’re really good at working with ARIN. A lot of people here have come to many ARIN meetings, have done lots of ARIN requests.

If we can’t do it fast, nobody can do it fast. I did a request, too, last week. Staff did fantastic. It was completed really quickly.

But if you can go back to your actual statistics. You have lead-time statistics, completion time statistics, right there, second bullet point. From Q1 to Q4, last year end-user tickets, request tickets increased 11 days to complete them. ISPs increased seven days to complete them. Those are hard statistics that show a considerable slowdown.

So there is a problem, even though we in the room can get - when you know what you’re doing, you can get some things done fast, definitely.

Secondly, I want to respond or make a comment in trying to be helpful to Mr. Curran. 8.2 transfers, you know how maybe we can make them faster? Let’s stop having people from this community who are engineers and with engineering background being the primary responsibility for reviewing legal transactions.

I don’t understand why the ARIN staff doesn’t have paralegals or some type of properly trained staff doing the 8.2 transfers and may be used to this type of things rather than folks who worked at UUNET and global crossing as engineers.

John Curran: Just to be clear, Dave, the problem is not in reviewing documents, it’s in explaining to someone, yes, you need to provide them. And I think you have been through that cycle before and you’re aware.

Our challenge isn’t can we get one of the documents on the list. We have bright staff, and it doesn’t require - in the rare case, where the document we’re getting does require legal review, we now have in-house legal counsel and he’s pretty good going through such documents quickly.

The vast majority of these are just we need to get the paper. And it’s not on our side. It’s how can the network engineer who thought he was doing a network request find the transaction paperwork which is over in the legal department in his business unit.

When it’s not us reviewing, it’s them getting it and supplying it, where we’re generally held up on.

David Huberman: Finally, we talked about fraud. Mr. Conrad came up and talked about it; you talked about it. Leslie asked five years ago for a fraud team and four years ago for a fraud team and three years ago for a fraud team. And if fraud is significant, can maybe we get a fraud team so the hostmasters can actually work on people who need space and need SWIPs and need all that?

I hear a lot of - I hear a lot of we could do this, but maybe we can’t do that; we could do this, but maybe we can’t do that. Lead time is slower. Completion time is slower. It’s just going to get worse with transfers, worse with fraud. Please do something.

John Curran: I hear your plea. I want to make sure you understand - I want to be very clear. So the lead time you’re seeing, we’re seeing an increase in end-user lead time because we’re seeing a lot of first-time requesters show up. And our response time, yes, our ticketing response time has gone up a little bit because of volume. But the total return and going up increased to 11 days is because we go back and we have to educate them in the process of getting the materials.

So I think a fraud team is great. I actually think we’re staffed for a fraud team right now in 2015. We have a great staff for a fraud team. But it’s 2014. We’re in the middle of a year of significant transition.

So that’s - I don’t want to try to do too many things at once when the composition of what we’re facing two years from now could be entirely different than what we’re facing today.

Leslie Nobile: Tina, I think you’re next.

Tina Morris: Yes, I had a remote question from Christoph Blecker from Disney Interactive. He asked: When you receive a pre-approval, how long do you have to complete that transfer with pre-approval still active?

Leslie Nobile: That’s a good question. I can’t remember the process. How long is your pre-approval good for basically is what he’s asking. I can’t remember if - we have this written in our procedure. It’s new. We haven’t used it much.

Cathy, do you know by any chance - Cathy, do you have it down there somewhere? Because she has the document written in front of her.

Cathy Clements: It’s currently 90 days.

Leslie Nobile: Good for 90 days.

Cathy Clements: We won’t go back to you to redo the approval.

John Curran: I am going to be closing the mic, so if there are any other questions to Leslie before the break, approach the mic now.

Leslie Nobile: I think Andrew was next.

Andrew Dul: Andrew Dul with my AC hat on. First comment about streamlining the policy. This is an admonition to the people in this room.

The AC has tried a number of times to make large scale policy changes to the document through what people have called omnibus changes, and this community has balked at those changes because they have been unable to digest them.

So if we want big changes, you’re going to have to digest them. And that means not calling out every single nit that is your favorite thing that you don’t like every single time. It’s okay to make a comment once, but not every single time.

So I personally would like to see us make some big changes. If other people would like to talk to me about that, I’m happy to talk to them.

The second comment about that. I had some conversations with people yesterday about a little bit more looking at strategic policy for a five year from now ARIN, what should our policy look like five years from now. R.S. and I talked about this. If you would like to talk with us about this and what you’d like to see in an ARIN policy five years from now, please come and find us and we would be happy to talk to you. Thank you.

Leslie Nobile: Thanks Andrew. Front mic.

Lu Heng: That’s me, right? Lu Heng from OutsideHeaven. There’s a few things I want to make a comment regarding the registration service. I’ll call this also from the experience we had with the registration service so far.

The first thing I’d like to mention regarding the technical need. I believe that the registry is about evaluating the technical need of each technical company and it’s purely based on the net operation, of course.

We had experience with - which is quite unique, especially with this registry, we’ve been getting a lot of involvement with autonomy, which is lawyers. And my network operation team are based on the technical need. We don’t really talk to the lawyers that often.

So we’d appreciate ARIN, actually, when evaluating tickets, if there is a question, if there is a problem, please bring into the technical people and we discuss the technical problem instead of bringing attorneys.

Of course exception would be checking legal documents. But aside from that, we’d appreciate every time when we’re talking about problems, we should talk about technical need only and that’s a technical community here.

The second thing here is the - we’ve been hearing about some business practices from ARIN instead of strictly obeying the policy. While we’re listing in our tickets regarding each of the policy sessions, we’ve been refusing to discuss the policy in session, instead we’ve been told it’s a business need.

So we would like to ask ARIN if the business practice - is there a document for that? Has it been posted somewhere on the website? Or on the discussion of the understanding of each policy and we like ARIN to clarify on this.

And the last point I have here is to make more efficient evaluation and to encourage the deployment of v6, we wonder if there’s a technical check when people start - the new member coming to ARIN, ask for v4, the new member would you ask them to actually - ask them to apply for v6 at the same time, like to tell them, hey, guys, do you want v6 at the same time, promoting the tickets as well.

That’s all my comments, thank you.

John Curran: The last question, Leslie, when someone comes looking for v4 resources, do we advise them or ask them do they also want v6.

Leslie Nobile: We don’t ask. But we do point out that v4 is depleting very quickly and that they should consider applying for IPv6 now. So we kind of encourage it, but we don’t require it.

John Curran: Regarding the other questions, I actually clarified on the PPML list at length ARIN’s practice, because ARIN’s service is the RIR for this region, so we issue resources for this region.

With respect to utilization, if you have additional equipment in this region, it’s very easy for us to determine your additional need and issue additional resources.

If you don’t have additional equipment that we can go on but you only have additional customers, it is our practice to verify those customers, and we generally are looking for things like customer names and street addresses. And some people are put off by that, and I’m very sorry. Until the community gives me a better policy to use, I’m going to look for something we can verify. Because otherwise need would be entirely asserted and unverifiable.

This means, in particular, when a party says I have no additional equipment in this region but I have a need for a great number of additional addresses and I want to supply you with only the email addresses of our customers, I actually - at this time I have no policy to support that, and the staff position is that that’s not verifiable in any form.

And we’re happy to take policy, if you want. The AC members all have badges. I’m happy to consider an email address to be a new customer if the AC will give me policy that says it.

Lu Heng: That’s not my question actually here. My question here is when we discuss - when the registration service comes to new member, or old member, doesn’t matter, come to a ticket, the technical need should be the first being verified, regardless the way of - method of verifying, but instead of bringing attorney into verification process, that is very hard.

John Curran: I understand. Unfortunately -

Lu Heng: That’s all the questions I have. It’s not about any detail.

John Curran: Before we can actually deal with an organization, the first step, because we’re going to have to enter into a contract with them, is to verify legally who they are. So, yes, it does become a technical discussion but first we have a legal discussion. That’s also required if we’re going to sign a contract with someone on the other side.

Lu Heng: I understand that, but the problem is between the technical discussion being heard from Registration Services that the need to talk to us unless they have a lawyer standing next to them, that is not very nice to a technical community. That’s basically my suggestion here.

So if - of course as legal things needs to be checked and documents to be signed, that’s completely fine. But when doing a technical need evaluation, that should be purely technical. And if there is need for additional technical information, sure, you can request it. But that is not my question here.

John Curran: I’m unaware of ARIN asking someone to have a lawyer present for their discussion. I do know that we have had occasions where we say we’re trying to verify your material and we are looking at things that appear to be fraudulent, and we advise people of that.

So perhaps you should approach me during the break and we can talk about it.

Lu Heng: Sure.

Leslie Nobile: Louie.

Louie Lee: Hi, Leslie. Thank you.

John Curran: Microphones are closed so we can actually get a break.

Louie and then Jason. Thank you.

Louie Lee: Louie Lee, Equinix, chair of the ASO Address Council. I apologize if you don’t recognize me without my hat.

Back in September of 2010, this community, along with the rest of the global community, passed a global policy, the policy about ASN 32-bit versus 16-bit. The relevant excerpt I want to address is: This means that until December 2010, December 31st, 2010, RIRs can receive two separate ASN blocks; one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs and will operate the ASN allocations from an undifferentiated 32-bit ASN allocation pool.

So the ASO AC has received a request from IANA to clarify this policy. Before we do so, we want to ask Leslie, we want to ask the other RIR RSD managers and also perhaps IANA to clarify the question for this community: Is the goal of the policy being met? If I recall correctly, the goal was to set a date to which we can tell our hardware vendors and our SDN vendors that this is the date you have to support 32-bit ASNs. If we have people - customers or registrants - asking to return their 4-byte and their equipment is still not supporting it, then do we need a change of policy.

Maybe I’m getting ahead of myself. I want to hear what the experience about that is and also what the run rate of the 2-byte is.

Leslie Nobile: So we have met and talked about this. The reality is that 2-byte - that 4-byte ASNs have not taken off like they should have. The expectation was everybody would be able to accept them, they work.

I think there’s people in this room - I think Rob Seastrom is one - who would comment: It doesn’t always work and we are having lots of 4-byte ASNs returned to us.

So we have a limited supply of 2-byte ASNs at all of the RIRs, and we continue to have to use them. We’re all running out.

When we go back to IANA, the policy says we don’t distinguish between the two, but that’s crazy because we do distinguish between the two. We have no choice. The reality of the market is - the community is that they’re not working well for the community.

I think that RIPE said they’re issuing about 70 percent 4-bytes and 30 percent 2-bytes, even that’s a big push, but they’re still issuing 2-bytes because they have to.

LACNIC, it’s the same thing. APNIC, the same thing. They’re trying to get the 4-bytes out there by default, but they get them returned frequently.

So when we go back as RIRs to request additional ASN blocks from IANA, there’s a formula and there’s a policy. And it applies to all of your ASNs, all of the ones that you have in stock. You have to have used 80 percent. That includes your 4-byte and your 2-byte.

The RIRs are thinking: We need to reserve. We need to keep our 2-bytes. We don’t want them to count against us when we go back for more 4-byte ASNs. We need to reserve them for those customers who need them.

So we’re in a rock and a hard place. We have a couple of problems right here. Maybe someone can explain it better. Andrea, do you want to kind of pick up.

Andrea Cima: Andrea Cima, RIPE NCC. I just wanted to confirm the numbers that you mentioned. The RIPE NCC, we issue about 150 ASNs per month out of which almost 70 percent are 4-byte ASNs. So only 40, 45 percent are 2-byte ASNs.

Leslie Nobile: Did that explain the problem, Louie?

Louie Lee: That was about 45 issued in that month? In about a month’s time? And what’s your pool looking like, projecting how long that will last you.

Andrea Cima: With regards to the pool lasting, we should have 2-byte ASNs for another couple of years.

John Curran: I don’t want to get into an extended discussion of this because we’re wrapping up Leslie’s report.

To the extent that we’re going to move on, we have an open mic at the end if folks want to revisit the 2-byte/4-byte ASN topic.

The microphones are closed.

Jabber, go ahead.

Tina Morris: One remote comment before the microphones are closed. Marla Azinger, Frontier Network: I disagree with Andrew Dul. The community should never stop rejecting nits that they see affect policy in a negative way. What I see as the issue is we have complex policy based off of fear. Loss of the fear mode of IPv4 running out and everything will become easier. Lose the fear mode. Sorry.

John Curran: Heather, you want to respond to something?

Heather Schiller: Yes. So how do I say it politely? The Policy Experience Report is the place where staff can come to the community and say: We’re having this difficulty with a particular policy; can you please consider another way and look into this.

Instead of staff deciding to change how ASNs are allocated without telling the community, you should have come to the community and said: We’re having this problem.

The opportunity is there.

Leslie Nobile: Can I comment on that? I brought that to the Policy Experience Report three times over the past five years.

Heather Schiller: And that’s how we got to the - yes, it is, because we - and I looked at it yesterday. That’s how we got to the policy we have now, because in 2009 it was different, and we changed it in 2010. And that’s what the current policy is about going in order from lowest to high.

Leslie Nobile: Right. We made the decision to do lowest to highest. Correct.

Heather Schiller: And that’s what’s in the policy. That got implemented and changed in 2010. That’s what I’m saying. Like I looked back. I was not aware - and I can look again, but that anyone came back in the last three years and said this is still a problem.

Leslie Nobile: They have.

John Curran: We can verify it.

More 2-byte/4-byte at the open mic, because we do have to finish up the Engineering Report. And then when we get done with that, we’ll come to a break. Then when we get back, we’ll have two more reports, and then we’ll have an open mic.

Leslie Nobile: Can I go now?

John Curran: Yes, Leslie, you’re done now.

Leslie Nobile: Thank you.

(applause)

John Curran: Because that’s where the rubber hits the road with the actual numbers, you’re always going to be popular, Leslie.

All right. So we’re going to defer the engineering report until after the break, because the break started 25 minutes ago.

You have a break. It runs 20 minutes. I will see you back here at 11:15. We are resuming at 11:15. Quickly.

John Curran: Welcome back, everyone. It is 11:15 or so, and we’re going to resume with the Engineering Report. I’ll ask Mark Kosters to come up.

Go ahead, Mark.

Engineering Department Report

Mark Kosters: So based upon the RSD presentation and seeing the queue afterwards, I thought that was the engineering report.

So I’ll go through this really, really quickly. One thing I’ll mention about our staffing is that we’re pretty much at full strength. We have one QA position open right now. Most of the staff - I was reflecting on this - has been there about two to five years. We have a few long timers, but there’s been an overturning of staff within the last six or seven years.

Year to date efforts. We’re working on the ACSPs. Work is underway for sharing ticket information, which is important for transfers. And that’s one of Leslie’s highlights.

RPKI, we’re mopping up the remaining work. The last thing to be done is migrating from our HSMs from a 4764 to 4765. It’s because you can no longer get parts for the 4764.

We’ve migrated Oracle to Postgres, and I’ll talk about that a little bit later. And we’re moving away from EMC to NetApp for our SAN. And the reason for this, and I mentioned this before, is that we’ve had problems with both those systems, both Oracle and EMC. So we’re getting rid of these problem children.

What we’re working on now is we’re working on DNSSEC, making updates near real time. So you put in your - your changes in ARIN Online, they should be almost immediately reflected in DNS. Hardening of our key management systems associated with it.

We have some fault tolerance improvements that we’re putting in. We’re going to be moving our production systems from ARIN HQ to our colo out in Ashburn. And we’re moving back-end systems when merited from virtual instances to actual hardware because there are times where it’s inappropriate, and we’re finding out why. And of course we ran the member meeting here, the network, and so on and so forth.

Let’s talk about OT&E. So OT&E is operational test and evaluation. It’s a place for people to test code and to test process. So if you want to go ahead and use that environment, please do so.

We’ve replicated most of the core services. The only thing that’s remaining that I don’t think we’re going to do is we’re not going to be doing template processing because it’s, frankly, just too confusing for an end-user and we’re worried about people putting things into OT&E when they meant to put it in production.

Everything here is very visual in terms of, hey, look, you’re in the test environment, as opposed to being in the real production environment. And there you can see we have all the major suites there available.

We’ve had a security audit by Foreground Security. I’d like to thank the community for bringing this up as a suggestion at the last meeting. This was a good suggestion.

We took the challenge. We had Foreground come in. The sort of preliminary report from them is our external services are very rock solid. They did also look at our internal services, and they had a number of suggestions that they would like us to actually entertain.

IETF. We’re participating very heavily in IETF, mainly in a bunch of different working groups. We’ve talked about some of these before. SIDR - which is really RPKI - RPKI GTA - global trust anchor; that was brought up a couple days ago, actually yesterday - and RDAP, which is a replacement to Whois.

There’s also a lot of ICANN participation that’s done by engineering staff. There’s the Security and Stability Advisory Committee, which is SSAC, there’s the root server committee, and there’s a technical advisory group, all of which ARIN staff participates on. And these are important in the global community.

What I’d like to talk about now is we’ve had a real successful conversion from Oracle to Postgres. As we went through the conversion process, we wanted to make sure that our data - there was 100 percent validation of all the data that crossed the wire from Oracle to Postgres, because data integrity is paramount to us as well as you.

We did put in high availability into the system. We were invited to give a talk at one of the most premier Postgres conferences. The people who gave that talk, the feedback received was they were rock stars in that they really liked the stuff that we’ve done. They would like to see us open source some of the tools that we have put into place.

We did have an instance where we exercised high availability within the first week because we had a hardware failure on the primary database server, and it went without any sort of implication to you as end-user.

We did have one failure, however, that required - well, that resulted in a couple of unplanned outages. And it was because we were trying to put in centralized logging and we had our syslog which it took us a little while to figure out, actually caused some issues that made Postgres go wonky. We have actually identified this and got this all taken care of.

Here you can see our ARIN Online usage. We have almost 82,000 people - or accounts - I shouldn’t say people - accounts that have been activated. Pretty great.

What’s interesting about this is active usage of ARIN Online. You can see one of the things that’s interesting as I was building this is the number of people that have come in over 16 times is really starting to increase. So there’s getting to be more and more usage here.

Here you can see templates. People are using Reg RWS. REST is in red, which is Reg-RWS; templates are in green. And what’s interesting about this is that REST is really overtaking the templates. Templates are increasing, but the Reg-RWS is increasing even more.

Reports via REST. Here you can see the requests from inception through Q1 of 2014. And what’s interesting about this is the number of reassignments and especially WhoWas requests. What’s interesting about this is that there’s been almost a quarter of a million WhoWas requests exercised against the REST interface in our system. That’s very interesting.

RPKI usage. We’re having slow uptake with number of organizations. We have 108 today. There’s a number of people who are actually putting up ROAs. What’s interesting about this is that there’s been zero people who are actually using up/down or delegated. So we have not seen any requests come in for that at all yet.

Web delegated, the second from the bottom, we’re going to deprecate before it gets any usage.

Whois. We’ve had this spike we talked about a couple of days ago. What’s interesting about this graph is that the RESTful interface on this has been consistently higher than the Whois interface in terms of number of queries presented and answered.

This graph shows the percentage of v6 traffic on the Whois cluster. And it goes up and down, mainly going up, which is a good thing, but lately has been coming down a little bit. I don’t understand why. What are you guys doing with v6?

IRR maintainers. It increases at a gradual rate. We’re seeing some steady usage here. Here is the number of routes and route6 objects. Route6 is increasing a little bit higher, kind of flat. But given the number - this is the logarithmic scale. So you can see there’s just not very many route6 objects in our IRR.

IRR InetNums. You can see here we’re having some in here, but it’s essentially flat as well. Interops. We’ve been doing lots of interops both with RPKI and RDAP, a replacement for Whois. And ARIN has been instrumental in these tasks. Admittedly we’re behind with RPKI at the beginning, but we’re up to speed with every other regional registry now in terms of the capabilities that each of us has.

In RDAP we’re actually leading the charge on making this available. Andy, who is back there, is really championing this, has one of the few RDAP clients, actually the only one, and we have a public test bed of the standard that’s coming out this summer, we hope, on Whois replacements.

RDAP. What I’d like to bring out also is that we really started this at ARIN. And I kind of want to toot our own horn about this, because everyone else has found this very, very interesting. All the other regional registries have been a part of this.

But what was really interesting is ICANN said: We’ve gotta solve our multilingual problem; ARIN, can you help? And Andy and I sat down with our tech people and said, hey, we have an idea, here’s a way of going forward.

They loved it. They’re actually putting this in all their contracts with all of their registrars and registries to go forward. So this work is actually important and it’s going to be global.

(applause)

Mark Kosters: Thank you.

So one of our focuses is we’re a real small engineering shop. We don’t have a lot of people. They’re really, really good engineers. And we have lots of demands, and we’re attempting to provide exceptional service.

That’s one of the things that we’re stressing within ARIN. To that effect, we’re creating APIs to core services which allows you to create the tools you want and you won’t have to be dependent on us for all the knobs.

Andy talked about this two days ago, but I want to follow up and reassert that, hey, we’re making these APIs so that you can create the tools with your development teams for the specific needs that you want.

If you find these tools really useful and you want to give back to the community, we have a site that you can, actually, a code repository, based on ACSP we did years ago for you to put your code into place so others can use your tools as well. I encourage you to take advantage of that.

So what are we working on? We’re working on finishing up as many ACSPs we can, DNSSEC on the forward zones, which are underway, making DNS changes in real time, moving RDAP pilot into production, which we plan on doing this summer. Further automation on transfers. This is one of the areas that’s pressure point on Leslie; it’s also one of the things that requires a little bit more automation. Moving core production from ARIN HQ to colo and moving our SAN from ECM to NetApp.

So are there any questions? I know I went through that really fast.

Discussion

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, a frequent, I think, over the years person who has come up during this portion of the thing.

I would like to applaud ARIN and your staff for having the guts to go out and get an external audit.

The only thing I ask is: I don’t want to know the content of the audit, but I do want to know a grade. That would be appropriate, I think, moving forward. And I would ask that your external auditor at least provide a grade or a roadmap for ARIN in that regard.

If you can go back a couple of slides, in regards to the external -

Mark Kosters: Tell me when.

Kevin Blumberg: Keep going to the external organizations you’re participating in. What I don’t see there is ARIN having its own that external can come and help ARIN. And I just sort of wanted to mention that operationally you are participating in a number of areas, and maybe it’s worth ARIN itself having something where people can come and contribute into ARIN as well and be able to use the brain trust.

As well if you go to your - if you look at the RESTful information, the one piece of information that would be very useful, especially with the number that you’re talking about of RESTful queries going on, is the number of unique IPs or number of unique users that are using the RESTful system, because as a member I’d like to know are three organizations dominating the resources for their system, do they need to be throttled, or is this an across the board kind of thing.

Mark Kosters: I’ll answer the second one. The first one we’ll take back. Dealing with - there’s really two parts of the RESTful interface system. One is the provisioning interface, which is Reg-RWS, and of course there’s a more limited audience associated with it.

The other one is the public interface with the directory service, Whois-RWS. And that is actually pretty widespread. And we can look at specific numbers, but it is - based on looking at the logs, it’s pretty widespread in terms of usage.

What’s interesting when we did a pilot of this a number of years ago, a person actually created a flash instance client within days, and we were really excited about that, seeing that sort of behavior occur, because that means that people are sort of glomming on to this. They like the idea of seeing structured data coming across the wire that they can actually go ahead and use more appropriately internally than the scrapers that we have today.

Kevin Blumberg: I was actually more thinking of the WhoWas number, which was I believe a quarter million requests which would be authenticated, and that was the uniqueness related to that.

But I’m glad the rest is evenly distributed; that no one company or organization is abusing your resources.

Mark Kosters: Understood. Thank you.

Ralph Bischof: Ralph Bischof, SAIC, NASA. One thing that noticed is your acquisition from a 4764 to 4765 IBM, now, with the System x and other lines that are sold to Lenovo, I take it that ARIN doesn’t have the requirements like some of us do to purchase from companies with US based presence.

Mark Kosters: IBM is a US-based company.

John Curran: ARIN is US-based. We serve a large region. We’re not required to purchase from any one country within the ARIN region or otherwise.

Ralph Bischof: Thanks.

John Curran: Questions for Mark before we move on? After R.S., closing the mics.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council and Time Warner Cable and a very small ISP that does friends and family stuff so I use ARIN Online periodically, and I don’t use two-factor authentication to talk to ARIN Online, but in light of events of these last days, that would be an awfully nice thing to have.

And I would like to - I’m sure that people have expressed that to you privately, and I’d like to express that to you publicly and add my voice to that.

John Curran: Can I - just an informal poll of the room: Raise your hand if you would use two-factor authentication on occasion, like when well known public crypto libraries were compromised globally, or other occasions. I don’t know.

All right. So it would get used. I know people would not - a lot of people said they would not use it day to day, but it’s nice to have for the occasion when it’s nice to have. Okay. Thank you.

Mark Kosters: If I may, there’s two things here. One, there’s the SMS-based authentication, two-factor authentication system that Andy brought to the table, and there’s also an RFC standard TOTP that Google Authenticator and others are using.

Which of those two would you prefer.

John Curran: Could we have some folks at the mic help Mark out with some directional guidance.

Rob Seastrom: So there’s good and there’s better and there’s great. And any kind of two-factor authentication, even the SMS stuff, which is an extraordinarily low bar, raises the bar that somebody has to pass to mess with you exponentially.

In a previous life, Mr. Curran and I had a talk about RSA stuff, which is widely known to be vulnerable, and yet the value that was provided for those little tokens was huge. And so we continued using them even though it has the problems with it, sure, but it raises the bar.

John Curran: People at the mics solely for commenting on two-factor authentication and possible implementation options. Go.

Scott Leibrand: Scott Leibrand. I use primarily Google Authenticator to do my two-factor auth with other organizations. If that’s trivial implementation and RFC compatible and all that good stuff, great, do it, but, as R.S. said, just go ahead and do whatever you can do cheaply. It’s not like my interactions with ARIN are going to result in somebody draining my bank account. It’s probably not even the case that somebody getting into ARIN Online is going to mean there’s an irrevocable loss of number resources that couldn’t be fixed when somebody realizes it’s messed up.

So go ahead and do whatever you can do easily, and I will be perfectly happy with that.

Owen DeLong: Owen DeLong, Hurricaine Electric, ARIN AC. I’m all for two-factor authentication. I am finally down to carrying one hardware token and everything else is now an app for that.

I think I’m presently using about six two-factor authentication apps.

Please, if at worst, make it another app; please do not do a hardware token-based solution.

Google Authenticator would be okay, though all my data are belong to Google is not my favorite thing in the world.

Mark Kosters: To that point, Google Authenticator is not the only one. This is a standards-based solution of which you can use Google Authenticator, but there’s many other providers you can use as well.

Owen DeLong: That would be fine, too.

Mark Kosters: Great. Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I believe I originally brought up the two-factor. Both, and then keep going. Whatever makes it easiest for people to access and that is easiest for you to turn off when there is a compromise.

My greatest concern with SMS, as an example, at some point a malware attack takes an SMS message and then redirects it. So any one two-factor authentication method is not good enough. Anything that relies on email is absurdly bad idea into itself because the email is the first thing that gets compromised.

If you guys - the TOTP and SMS is a great start. The other thing is if you’re not comfortable, go with a third-party company to provide an alternative mechanism so that I can have one of 12 different ways instead of you trying to code one of 12 different ways. That is another solution as well. I don’t want to go into specific company names, but there’s a number of outsource solutions for this.

John Curran: Rear microphone regarding two-factor authentication.

Microphones were closed. We’re here to comment on helping Mark with two-factor authentication options.

Martin Hannigan: Martin Hannigan, Akamai Technologies. Mark, I have to apologize. We had a conversation about this I think two days ago, and I said, oh, yeah, no worries, don’t worry about it. After I thought about it a little bit more, it actually is a problem.

I’m concerned with things like social-engineering based on somebody modifying an email address in a Whois database and using that to cause some additional damage.

I think that our recommendation would be to do whatever is most secure. And this is the one area where we would say if we had to pay extra we would. Not necessarily in fees. I’m not in that bucket, by the way, but if I had to pay for a token or an application or something, we would like to see this as secure as possible. And thank you very much.

John Curran: Thank you.

Mark Kosters: There’s one final thing, and then I’ll leave, and it’s dealing with Heartbleed. We put out an announcement yesterday: All our certs have been rerolled and we are all good across all our systems.

I was amazed with the number of certs that ARIN has within its organization, and we have multiple companies. So it did take us a little bit. And we had to deal with some of the SLAs of some of our CA vendors. But everyone was really busy. We got it taken care of. So thank you very much.

John Curran: Thank you, Mark.

(applause)

John Curran: Okay. We’ll get back on track one way or another. John is going to help me. John, AC Council Report.

Advisory Council Report

John Sweeting: Good morning, everyone. I’ll make it real quick to help John get back on track. Quick picture of the AC. I want to take this second right here with the picture up there to thank each and every one of the AC members for the great job they’ve done over the last year.

(applause)

John Sweeting: We had a turnover, four new members last year, dealt with a new PDP, and we’ve also dealt with adding in the PPCs at the NANOG, the Public Policy Consultations at the NANOGs, and we’ve had a large increase in the number of proposals being submitted. And we got all 15 in the picture, as Paul pointed out. Thank you all for that.

Stacy Hughes: Thank you for being an awesome Chair.

John Sweeting: Thank you. I’ll pay you later.

We’ll go through this quickly. The proposals come in. The AC makes sure there’s a valid problem statement, works with the author on ensuring all that and some other things that’s in scope and that it actually makes sense and it’s addressing a problem.

Then it’s moved to Draft Policy where we gather input from the community through PPMs, PPCs, PPML. If it all is going well there, we move it to recommended Draft Policy, present it at Public Policy Consultation or meeting, send it off to last call and then recommend it to the Board.

Of course, anywhere along the line it could get abandoned, and also anywhere along the line it’s open for petitions from the community.

For this year, for 2014, our current on docket status, we have 14 proposals, which we’ve gone through in the last couple of days. Four recommended. Ten Draft Policies. The AC will be meeting right after this meeting to evaluate what we’ve heard here and what the next course of action is for each one of these 14 proposals or recommended policies.

In comparison, last year we had nine proposals received over the whole year. One was remanded and closed, one remanded back to author for clarity and then it was closed, one was implemented as an editorial update. Seven moved to Draft Policies where three were abandoned, two moved to recommended, one was abandoned, one was discussed - I didn’t clean that up - and two drafts were discussed. Sorry about that.

Advisory Council. These are some of the things that the Advisory Council does. We do a lot other than just proposals for ARIN. We volunteer a lot of time and a lot of effort. And luckily we have - most of us have employers that allow us to volunteer our time with ARIN and support them in all their outreach and other - whatever else, really, that ARIN reaches out and asks us to help them with.

That’s it.

John Curran: Any questions for John?

Paul Andersen: I’ll jump into it. I’m Paul Andersen. I’ll be giving the treasurer’s report.

Financial Report

Paul Andersen: I’ll jump into it. I’m Paul Andersen. I’ll be giving the Treasurer’s Report.

So today - so I also chair the finance committee of the Board. I’ll be giving a relatively short update today. I’m going to report on our audit for the last fiscal year.

Our fiscal year is the calendar year, for your information. Give you a little update on our first quarter and talk about reserves.

So the audit committee and the Board have now reviewed last year’s auditor. We had a clean audit. There were no issues brought by our auditor.

Registration revenue came in just shy of 16 million. The largest category of revenue is IPv4 - IPv4 registrations, but, for clarity, that’s what would have been called the subscriber revenue before or the ISP v4 renewals, and then there’s another 5 million that breaks down.

Expenses were about 15 - just over 15 million, so we were $453,000 to the good.

Until you add our investment result, which we continue to have strong returns on, of about $3.8 million, meaning that we netted to our reserves about 4.3 million, which I’ll touch on in a little bit.

To give you an idea of just some of the major variances we saw last year over 2012, 2013, we had an increase in salaries. That was due mainly to some new hires in engineering. Depreciation was up, but that was anticipated based on the continued capitalization - depreciation, sorry, of the ARIN Online work we did a few years ago.

Communication has increased a bit. That’s mostly due to some - as Mark pointed out earlier, some of the stuff they moved out of ARIN HQ into colocation. That’s increased costs. However, in good news, equipment support has dropped about $130,000 - is it pressing?

Owen DeLong: Are these columns here reversed, or are these actually decreases?

Paul Andersen: Those are correct.

Owen DeLong: Because you were saying increased.

Paul Andersen: Communications increased. Equipment support decreased $130,000 thanks to the successful migration to Postgres, which means there’s a lot less Oracle licenses going around.

John Curran: Salaries decreased.

Paul Andersen: Yes. I’ll double check on that because notice salaries increased. I’ll get back and double check that one.

John Curran: Salaries decreased even with new hires.

Paul Andersen: Salaries decreased even with new hires. My apologies.

Legal has dropped significantly due to a lot more work being taken on by our in-house counsel as opposed to using our firm for a while. I was going to cover that one in two. I can be difficult if I want to, David.

General office was down. That’s mainly due to deferral of a software project and the communications department. NRO was up quite a bit percentage wise but not a lot numerically, and that was due to the NRO bringing on a full time secretariat staff.

Outreach expense and travel were up due to a large increase in the number of ARIN On the Road programs, which have been hugely successful. And I know there’s no Communications Report, but just if you haven’t had a chance to attend one of those, they’ve been a great success. But there was an increase due to that. Also some increased costs due to the IGF attendance.

And all other items were - that’s about 45,000. That covers all the major that we saw from last year.

First quarter returns were exactly where we anticipated them. Revenue has been about 4.1 million, expenses 3.8. We’ve had a modest return on our investment. So we are looking right now at a $680,000 net to reserves.

Speaking of those reserves, just to give you a bit of a history on where it’s been since almost inception, we’ve generally had very good returns except for when 2008 - not many people had many good returns, but our negatives were not bad, and we actually managed to recover most of that over the past few years.

I get the question quite a bit about what are we planning to do with that. And I know that I’ve said several times the organization is going through some transition, and we haven’t yet - we’ve drawn down on several times whenever we’ve had software projects, a lot of the ARIN Online development that was contracted out a few years came from that.

We’ve also generally had more positive returns because the Board has generally not budgeted for returns from our actual investments. We’ve been very conservative on any return there. We generally like to continue to draw it back down to one year.

Our hope is to start looking at that I would say next year after we go through, A, the fee policy review that will happen at the end of this year and see what our fee structure is going to look like, also looking at hopefully then - not hopefully, but having a better handle on what a post runout may look like if we’ve hit that point by then. Because that is one of the things we’ve been holding off quite a bit on, to see what the organization looks like in a post runout both from an expense and just a subscriber count.

And with that the only thing I’d like to add is to thank Nate and Val and John and the entire finance team who make this so, so easy to do. So thank you very much.

And with that I’ll take your questions.

John Curran: Questions for Paul on the Finance Report. Thank you.

(applause)

John Curran: Vint Cerf, Chairman of the Board.

Board Of Trustees Report

Vint Cerf: Good morning. I guess it’s still morning. This will be brief. You just heard what the financial report was. We went through and adopted the budget, which I’m sure you’ve all seen. And, second, we accepted the audit, which was very clean. It’s one of those things where you hang on fingertips for a little while and when you get back an audit that said no problems, there were no issues and the staff was very cooperative, it’s a big point of relaxation.

We also extended the charter of the ARIN fee structure review panel. You could tell from the comments that John made that there are quite a few different alternative possible fee structures, and they deserve significant amount of attention. When the report is released, I hope that you will also pay a lot of attention to that, because we need good feedback from you about what seems to work and what seems to make sense.

We also reviewed the Registration Services operational audit. You’ve heard a report about that. That went well as well.

With regard to the Number Resource policy actions, we adopted the ARIN 2013-4 RIR principles. And we suspended NRPM 4.6 and 4.7 and engaged the AC, which discussion took place yesterday.

I keep wanting to ask for the next slide realizing that I have the control over that. And this is the last slide, by the way.

We also reviewed the election process and nominations process. And we’re still in the middle of trying to evaluate how well all of those processes work. And so to the extent that you have opinions about candidacies for various positions that have to be elected, that feedback would be quite valuable. We’ve also been looking at the engineering efforts, and we hear people asking for acceleration of some things and maybe slowdown on others.

Our concern is to make sure that you get the services you are expecting and you pay for, so the Board is very sensitive to that.

Accountability question is actually important in several respects, not the least of which is that your members and you - we should be, all of us on the Board and staff, accountable to you, but more important, I think, this accountability question will be under the spotlight as we go through the debates on Internet governance.

And not to overload this report, I do want to say that there are two aspects of the debate going on. One of them has to do with the question of the IANA contract from the Department of Commerce, but the other is a much more general view of what Internet governance means.

And we have our feet in both of those places. We have a relationship with ICANN, which is related to the IANA functions and therefore that contract, but we are also part of this broader Internet governance ecosystem.

And for me this was emphasized by the observation about the staff’s need to be worried about fraud and hijacking and other kinds of abuse. It tells me that the process of dealing with Internet addresses is not purely clerical; that in fact this is an issue that involves actions by parties and that these need to be evaluated, and it takes staff time.

So it just shows you that even though we have what should be a relatively clerical function, we still have these issues to deal with, and that’s part of the broader Internet context.

We’ve also been looking at - promotion of IPv6 is a personal campaign for me since 1996 and a great disappointment that we haven’t seen much more instant uptake of that protocol. However, I have hope because I have the impression that we are - my God, we’re at 3 percent. What’s not to like about that? I’m hoping that’s actually the seed of an exponential curve. We’ll know better, of course, in a year’s time.

With regard to the ARIN Board and the AC, first off I want to say that the Advisory Council has done an absolutely amazing job this year with all those things that you had us process in the last day or two and all the other things that seem to be piling up. I’m very impressed how well the organization is led and how well it performs.

The Board, I have to leave to your discretion to decide whether we’re functioning okay or not. But I can tell you feedback is welcomed, even negative feedback. It’s more important if you’re not happy with what we’re doing.

And, finally, that last bullet having to do with Internet governance I’ve already covered.

Discussion

Vint Cerf: So I think that’s the last slide in this report. I’m happy to respond to questions if I can. Otherwise, I’ll let you go

Paul Andersen: Would you mind if I correct - so my confusion, apparently, not reading - yes, on my report I said salaries increased yet the number was decreased.

I think it’s actually an important clarification because we did have an increase in the raw number of salaries but I had forgotten we had changed, when we had reviewed our policies, that a lot of our engineering and Q&A efforts are now depreciated as opposed to showing on that. Even though there was an increase in head count, there was a decrease in the salaries item because some of the payouts of salary is now showing up in the depreciation.

I just thought I’d clarify why I looked like I was crazy up there for a second. Which is normal, I know, but…

Vint Cerf: I wasn’t going to say anything about that.

Sir.

Scott Leibrand: Scott Leibrand, ARIN AC. Question for the people who are involved with the NomCom, which may or may not be you. I got the impression at one point that we were targeting two candidates for each open position.

I would like to hear what the current thinking is there. It seems to me that limiting to two, if we have been doing that - I’m not sure if we have - would be problematic. And I’m wondering if a lower limit of two and an upper limit of three candidates per open slot might be more appropriate, if that’s -

Vint Cerf: Wow. So the Board governance committee has in fact been talking about this. The Chairman is over here, but I’m going to take the prerogative of trying to respond. Finding qualified candidates is really a challenge, and so two to three would be a real challenge.

Scott Leibrand: I guess what I was saying is try and find candidates until you have at least two, but if you happen to get up to three, that’s great.

Vint Cerf: Do you want to say anything? Because Bill has something to say over here. Bill, would you like to respond? This is the job of the Chairman, is to get rid of any questions as quickly as possible to somebody else. So you should rate me very high on this.

Paul Andersen: Bill, you can go first, if you want. I’ll follow up.

Bill Woodcock: This is a matter that the Board has taken up before and came to a conclusion on and implemented, I believe, in one election cycle, and then one Board member, who is not a Board member anymore, became incensed over it and it fell into disuse.

So specifically what we came up with was N plus 1 to 2N for each open is seat. So if there were two open seats, which is normal for the Board, for instance, the requirement for the NomCom would be to provide at least three and no more than four candidates for those two seats. If there were five seats open, for instance, for the AC, the requirement would be six to ten candidates.

Vint Cerf: Scott, would you like to react to that.

Scott Leibrand: My observation has been if you limit yourself to ten candidates for five AC positions and then you have a vacancy and/or someone who was a candidate drops out, you end up in a situation like we had the last election where you’re closer to N plus 1 than you are to 2N. And I believe that up to 3N would be fine if we have that many qualified candidates.

Paul Andersen: I think, commenting on that one, that was a situation and we did get some feedback and we are looking at that, because when the nominations closed, we had the ratio, but then due to a variety of interesting scenarios that there was a potential that there would be a resignation post due to Bill Sandiford running for the Board, there was a - and then we had several dropouts and people not in the application.

So I think we’re looking at how can we address that throughout the election cycle so we can keep that ratio. Because I do know we ended up having much less than that ratio by the time the ballot came around.

Vint Cerf: In the back, please.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, only speaking for myself.

My question is: Is this an input issue or an output issue? I.e., the names go into the NomCom and the NomCom goes out and gets things and gives a list, but from what I remember, the list is the same list, what goes in and what goes out.

Is it predominantly or very rarely different, and should there be a lot more scrutiny of the people that are not coming in but the people that are coming out of the NomCom?

Paul Andersen: Are you saying you want more scrutiny of what filtering takes place, for lack of a better term?

Kevin Blumberg: I would like far more filtering on what the community is seeing; that the NomCom is actually going off and critiquing incumbents, as an example, because they have an advantage to some degree. But you know what? Let’s see what you’ve done over the last three years. And really do their job verifying with the community or with employers about potential candidates - are they available? Are they really available? We know they say they’re available, but will they actually show up? Things like that. And having a much better selection that people can be comfortable with.

Bill Woodcock: I think it’s important to understand that the NomCom has two distinct and important critical functions. Number one is to recruit as many highly qualified candidates as possible so that the membership will have a really good choice to make so that ideally the membership cannot go wrong in its selection.

The second is to make sure, as you’re saying, that every candidate that is put before the membership is someone who is capable and will be able to serve. So ideally we need a solution that encompasses both of those things.

Putting a maximum limit on the number of candidates put before the membership is a nondiscriminatory way of putting in a threshold without necessarily singling out any particular candidate as being not worthy of consideration. Instead, if you have a whole lot of good candidates, if you’ve done your job really well as a NomCom and gone out and found a whole bunch of really good people who are willing to run and are qualified and you have a specific target number to put forward as the selection to the membership, then to me that seems like the best of all possible worlds.

But it’s a really opportune time to hear from you guys as to what process you’d like.

Vint Cerf: If I could jump in just for a second. It seems to me what I’m hearing is a couple of things, which I welcome. The first one is giving good guidance to the NomCom about what is needed in terms of Board membership and quality of members and diversity and all these other elements that are important to membership.

The second thing is making sure we do a great deal of due diligence on any candidate that might come out from the other side.

But we do - “we,” I should say the NomCom will rely greatly on the people in this room and others who are not to show their willingness to serve. And that, I think, is still a big challenge.

Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I remember most years, and some years I’ve served on the nominating committee, but most years we’ve had some difficulty getting N plus 1 and some years we had no difficulty getting N times 3 or more. I remember one year we had a veritable plethora of AC candidates in particular.

Given that in general an AC member who gets elected gets elected with 100 some odd votes, having a 15 way slate strikes me as being a recipe for being more for confusion than correction in election results. Or more confusion than correctness.

Vint Cerf: Could you say 15 way means? Just having 15 people on the -

Owen DeLong: Yeah, 15 people on the ballot.

Paul Andersen: If I understand, you’re saying that the problem is you’re concerned with too many people on the ballot that it could make the threshold too low -

Owen DeLong: I’m concerned when you’ve got a six person race or seven person race for six slots, you get elected with 100 some odd votes. If you split those votes across 15 candidates and the result is a little bit less uneven than it has been in years past and you get 15 candidates all of whom got somewhere between 30 and 42 votes, saying that the top five won becomes much more interesting and much less of a mandate.

Vint Cerf: Could I just make sure I understand. This is actually a voting procedure question as opposed to the number of people on the ballot.

Paul Andersen: His concern is that if the NomCom puts 3X, 15 - on the AC you’d have 15 candidates, and with the - without the tens of - with the number of voters we have, you’re starting to get a much lower threshold because you’re diluting amongst the number of candidates. I think that’s a valid concern that we’d have to look at.

We may have to look at different thresholds between the Board where it’s a smaller number of seats where 2X only means four and maybe between the AC where it’s a larger number of open seats.

Vint Cerf: Good input. In theory I’m not supposed to call on you until Mr. Seastrom -

Paul Andersen: There’s also a front microphone where you could all line up too.

Rob Seastrom: I’ll move with alacrity. If the issue is figuring out who to vote for out of an extremely large slate of candidates, we could simply do STV and allow people to vote for all of them.

For people who are not familiar with what STV is, it’s the Scottish system where you rank all the candidates in the order of your preference. So there are no wasted votes, as people complain about. It has some advantages. However, simplicity and ease of understanding how it works are not one of them.

Vint Cerf: Is this similar to preferential voting? It’s the same kind of thing, I believe. You’re right. It creates confusion for people who have never done that before.

Let me take the front of the room first.

Cathy Aronson: Cathy Aronson. I wanted to comment quickly that there are 4500 potential voters in these elections and maybe we should focus more on getting more of them to vote as opposed to having fewer candidates.

John Curran: One clarification point. There are 4500 possible electors. When you remove the ones who aren’t current at any given moment, and there are some of those who don’t have contact, it’s about 3900.

We get a participation of about 600, which is about 15, 14, 15 percent. Now, I’d love to have that as a higher number. I will say 15 percent is remarkably high for some organizations. So if you look at some other trade associations, they would do back flips to get 15 percent.

As one of the people who grabs a sheet of paper every year and calls - because we do call you folks and remind you the votes are going on - I’m interested in ideas, but a lot of people are like: I just want my resources; I don’t care.

Cathy Aronson: Right. I’m just saying if we’re looking at reducing the number of candidates because we want them to all have more votes, the other option to that would be to have more votes.

Paul Andersen: I don’t think that’s the only reason we’re doing that. I think that was just a concern with such a large number. But it’s not the only reason we were looking at that. I would have no opposition to looking at ways to get more voters.

Vint Cerf: I would like more votes and I would like more qualified candidates.

Back of the room, please.

John Springer: John Springer, Inland Telephone, ARIN AC. I’ve noticed that the Board has also been considering the subject of term limits, and I would certainly recommend personally that if the Board and the nomination committee noticed that there’s a situation where there’s a hard time finding two N candidates, that that provide an input to the deliberations on term limits.

Vint Cerf: We’ve had discussions about that.

What happened? Did you decide not to -

Kevin Blumberg: No, I was just waiting until more people came up.

Vint Cerf: Thank you for that.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I’ve been involved in organizations that have had very bad, bad election processes, complicated election processes that caused major strife. I am - even well before I was involved in the election process, I’ve been incredibly happy with how ARIN has shown and done their elections.

People understand them. They have gone out and actively polled their members to let them know about it. And I’m very proud as an ARIN member of the way you as the staff and Board have handled elections over the years. I have comfort in that.

Any changes that we suggest are improvements to what is a good process overall, but over time you just need to revisit and relook at the options that are available to you.

So I just wanted to comment that anything that I’ve said personally I applaud what you are doing overall as an organization.

Vint Cerf: We thank you for that. And I’ll reward you with your bottle of wine after we get to the end of this meeting.

I see no more questions. Let me ask if there are any online. I think we’re done. Thank you very much.

(applause)

Open Microphone

John Curran: Okay. So there’s one item left on the agenda, and then we adjourn. The one item is called Open Microphone. It sometimes runs a minute and a half; it sometimes - well, it can be a challenge sometimes, I guess, interfering with lunch and other things.

But the microphones are open. This is your opportunity to ask questions to the Board, ARIN the organization.

Please come up and approach the mics.

Paul Andersen: I actually have one that Marla Azinger sent in that was meant for the Finance Report, what was the increase in revenues since the billing fee change was.

Now, we haven’t had a complete cycle, but our revenues were up about 4 percent of 1 percent we’re actually attributing to a better collection of some past due amounts that we had.

And it’s important to note that we don’t necessarily mean the fees - we’ve also have had more activity in registration. So that’s to attribute. But to answer her question, the increase over last year was 4 percent.

John Curran: Center front mic.

Chris Tacit: Chris Tacit, and I’m just making these remarks in my own personal capacity.

Having been a member of this community now for three or four years and been very well accepted by it, I just wanted to express my appreciation to staff who sometimes I think are undervalued by the community.

And I know we’re heading towards very difficult times with the shortages in numbering resources, and I hope that everyone will take into account the fact that staff have to do a very difficult job in the next while, and we should treat them with respect and consideration as they do the best they can under difficult circumstances. So thank you very much.

(applause)

John Curran: Thank you. I would like to say that ARIN has an exceptional staff. I feel the same way about the staff at ARIN. It is their efforts below me that is making this a success. I’d like to take a moment for a round of applause for ARIN staff.

(applause)

John Curran: Back microphone.

Jason Schiller: Jason Schiller, Google and the NRO NC. I wanted to talk about 2-byte and 4-byte ASNs. If you don’t care about that, go back to reading your email.

For those who do care, I want to hear what the community thinks in terms of how we should go forward. Specifically, we decided that we would not distinguish between 2-byte and 4-byte ASNs as a community. We made it very clear as a community that we wanted to send a message to operators and vendors that they need to be able to support 4-byte ASNs. We did it by having a pool that was undifferentiated.

At that time, ARIN staff decided that they would start issuing address space from this undifferentiated pool, from smaller number to larger number, meaning they would run through the 2-byte ASNs first and then the 4-byte.

The four other regions decided to implement this in the inverse where they decided to start with the 4-byte ASNs and only give the 2-byte. And we heard recently that ARIN changed their operating practice to start with the 4-byte and then issue 2-byte if needed.

John Curran: To be clear, in Phoenix, at the Policy Experience Report that Leslie provided, she noted that in May 2013, last year, we provided notice to the community that we tell people - when they ask for 2-byte, we tell them about the availability of 4-byte ASNs.

But it’s their choice. We did this because when we were just issuing 4-byte ASNs, as the rest of the world was, the vast majority of them were coming back, effectively duplicating work. We figured it was better to apprise them in advance so that they know. So that was announced in the Policy Experience Report.

There hasn’t been a change since that announcement.

Jason Schiller: So there has been two Policy Experience Reports, in which case this community has been informed that 4-byte ASNs are still a problem and people are still shying away from them.

And it’s my impression that this community has said let’s stay the course, let’s send the same message that we were sending. There’s no technical reason why they shouldn’t work. People should upgrade their equipment, blah, blah, blah.

We are still hearing that 4-byte ASNs are a problem for some. And I would like to know if this community thinks that we should still stay the course or not.

This is complicated by the fact that when you start assigning 4-byte ASNs and try to keep in reserve 2-byte ASNs, that once you deplete your 4-byte ASNs, you have to go back to the IANA for more space.

In order to qualify for more ASNs, you have to show that what you’re currently holding is 80 percent utilized.

If you’re holding a swath of unused 2-byte ASNs, you don’t qualify for additional ASNs because neither the IANA nor the RIRs distinguish between the 2-byte pool and the 4-byte pool.

As a result, in order to qualify, you have to burn through 2-byte ASNs, giving them to organizations that potentially could use a 4-byte ASN in order to get your utilization up to 80 percent in order to qualify to get more space.

John Curran: Right.

Jason Schiller: Is this the desired behavior? Is this good for the Internet community?

John Curran: Excellent question. It is true that the inventory available when you go to an RIR, because of the IANA faithful implementation of the policy we gave them, says that an RIR might be in the process of trying to burn through ASNs to meet utilization.

And that results in a very unpredictable status for someone going to get an ASN. And either the policy that we gave the IANA is something that we want to revisit, or people need to accept that practice, or some other outcome.

Jason Schiller: And if we do consider revisiting that policy that we gave to the IANA, that global policy, there’s an additional question. IANA is holding less than 1024 2-byte ASNs. Our policy says that ASNs are given out in 1024 sized chunks, blocks.

When someone last went back to the IANA and asked for space, they asked for clarification from the ASO AC the NRO NC and said: We have this fragment of 2-byte ASNs. What should we do? Should we give just the fragment? Should we strand the fragment and just give 4-byte?

We had some discussions in our various communities, and the consensus was that we should not stream the 2-byte; that we can give a block of 1024 that consists partly of 2-byte, partly of 4-byte.

The RIR requested a block of 1024, and they requested that half of it be 2-byte and half of it be 4-byte. We now have just under 500 2-byte ASNs. If we’re going to revisit our global policy so that we can differentiate between 2-byte and 4-byte, if we decide that’s good, should we also revisit the policy for what IANA does in terms of giving out 2-byte and 4-byte? Should we divide the 2-byte up equally and give each RIR 99 and the balance of the 1024 ASNs in 4-byte? Or should we give the next requester N all of the available 2-byte and then the balance in 4-byte to round up to 1024?

So I think the first question here, coming back to my original point, is do we want to stay the course and is that good for the Internet community; second question is should we be able to hold 2-byte in reserve and still qualify to get additional 4-byte ASNs; third question is what should we do with the 2-byte ASNs that the IANA is holding.

John Curran: Okay. Microphones are open. The topic is 2-byte/4-byte ASNs. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Given the relatively low number of 2-byte ASNs remaining in the IANA inventory, it would seem to me that if we could somehow get through the global policy process, while this still matters, which would surprise me, the sane thing to do would be to simply distribute the remaining 2-byte ASNs to the RIRs and then stop counting their 2-byte ASN inventory when reviewing their applications for additional 4-byte ASNs and move on.

John Curran: Okay. On the topic 2-byte/4-byte ASNs, microphones are open. Want to stay on this topic. Microphones are open on 2-byte/4-byte ASNs. Anybody else in the community want to speak? Jason has asked specifically for input on a number of interesting questions. I can’t imagine people don’t have views on this. If everyone believes that Owen is right, you can just hum now. I mean, that is another option, because we haven’t heard any alternative.

Look, people at the microphones. Go ahead, center rear.

Leif Sawyer: Leif Sawyer, GCI Alaska. Actually I’m going to extend on what Jason was saying. With 4-byte ASNs, we have a lot more ASNs that we could hand out. So why not increase the number from 1024 to something more so we’re not having to go back to IANA all the time.

John Curran: Okay. Good point.

Topic remains open. Center rear mic.

Kevin Blumberg: Kevin Blumberg, The Wire and ARIN AC. In regards to 2-byte, divvy them up, get it over with, get it done, give them out as you need them. Don’t hold people back.

And I think that’s what the community overall has been saying for a number of years, and I think I feel the same way on that.

As far as global policy to get it out, let’s do exactly the same thing we just did with the IPv4, distribute it out evenly, not make a big deal of it and just get it done. Totally agree with that.

And these are ASs. The other thing to consider is make 4-byte really, really easy for people to get. Let’s make the barrier for 4-byte click button, get as required, show use, be done.

This constant thing - or buy one get ten free so that you can just go off and keep doing it. Maybe there’s some options there that we can look at as well.

John Curran: Can I ask two questions about your guidance? You said get it done. Get them out, get it done. I understand for the IANA get rid of that last half block and make it go away, that would certainly simplify their life because there’s not like any are going to show up again and then they can really not worry about it, ASNs are ASNs.

When it comes to the RIR, I think you’re suggesting that ARIN take all requests, consider them 2-bytes, burn off its 2-byte pool plus whatever it receives and then be in a similar situation; is that what you’re suggesting?

Kevin Blumberg: I’m saying that, yes, the IANA should burn off its pool leaf and leave between the RIRs that actually want the 2-byte, because some might not actually want them. Just burn them off, get them to - back like we’re doing with the IPv4 where it’s coming back to the RIRs.

And as far as ARIN, I’ll be honest, there are two types of people: Those that understand the difference between a 2-byte and 4-byte and will request a 2-byte and those that - or they will request a 4-byte; those that have no idea. And guess what? Those are the ones who needed a 2-byte in the first place and are the problems to begin with. They just don’t know.

So from a staff point of view, just keep going the way you were going, which is the 2-byte, give out the 2-bytes and let them know 4-bytes are available, but don’t make it difficult. This whole justification thing, equipment thing is -

John Curran: Recognize 2-bytes can’t be held as a pool unless the IANA practices change because they’re counted as in the general utilization level. So pretty much ARIN has to not distinguish itself in its issuance or needs a policy that doesn’t inhibit a pool of 2-byte from getting its next 4-byte. So that’s why I’m asking you that. Because if we have a pool of 2-byte that we’re holding for someone who would ask for a 2-byte, we may not be able to get the next 4-byte.

Kevin Blumberg: I’m not saying to hold a - I’m saying to get rid of 2-byte to use it as people need to deplete that -

John Curran: That’s what I wanted to clarify.

All right. 2-byte/4-byte ASN, open. Yes, Aaron.

Aaron Hughes: Aaron Hughes, operator hat on at the moment. So as far as I’m aware, there are actually no hardware limitations to upgrading to using 4-byte ASNs. It’s only software. In my experience, operators are generally concerned about stability and to that extent don’t upgrade routers without good reason to do so.

On occasion people have routing gear that is up for very long periods of time. If there’s an option to get something like exchange your 4-byte AS for a 2-byte AS, they have absolutely no reason to disrupt their router or reboot it or any other customers or infrastructure on that gear.

When it comes down to a time when there is no other option, the upgrades will be taken. There’s no question. It does happen. Exchanges get renumbered and customers of transit providers can create demand such as I have no option; you need to upgrade your infrastructure.

It will just happen. With my operator hat - on - and you can certainly validate this at NANOG with a very simple question - I would say we just do nothing. Everything will be just fine.

John Curran: Microphones remain available. I see Leo at the back mic.

Leo Vegoda: Leo Vegoda from ICANN. Can I just clarify one thing. When you refer to IANA practices, our practices are informed by policy which you set. Well, not you personally, but you the plural you. And we don’t really just click our fingers and pull it out of the air. We are doing what you have told us to do and in fact you have told yourselves to do.

Because the global policy says the RIRs will not distinguish either. And so the global policy seems to set RIR policy as well, which is a little bit odd. But that being said, when we discuss this in the room and people come to the mic and they go and say never mind about the people who could make do with the 4-byte AS number and give them a 2-byte anyway and just get rid of them, everyone in this room probably works for a company that already has an Autonomous System Number and is doing fine.

So we are - we are the incumbents. So when discussing the policy, I think there is no policy proposal. So I’m not advocating a policy. But when discussing the policy, I think it’s really important that it’s not just the people who are already the incumbents who discuss the policy about this, because some of the people who come to some of the RIRs and say we would like to use a 4-byte AS number but our upstream will not allow us to for whatever reason, they are going to be disenfranchised if there’s no pool of 2-byte AS numbers for some period in the future.

And the policy that you have given, ICANN is the IANA’s functions operator, is that we cannot distinguish and we are forcing you, ARIN or LACNIC or APNIC or whoever, to burn through 2-byte AS numbers that some people would find especially useful.

And it could be - you’re essentially sacrificing future customers when you don’t necessarily have to. And that is really the policy problem that you need to decide, is that a problem or not and do you want to come up with a policy proposal. But it’s future customers who are being sacrificed.

Thank you very much.

John Curran: Thank you, Leo. I want to say it is recognized IANA global policy is RIR community set policy. And IANA’s faithful adherence to that may be inconvenient, but it is what we have asked for. And so now we are facing what we asked for.

Center front.

Jason Schiller: Aaron Hughes, I wanted to ask you, you said do nothing and the problem will solve itself out. I’m sorry to be pedantic, but I want to know exactly what you mean by “do nothing.” What should IANA do and what should ARIN do.

Aaron Hughes: Sorry. That was my personal opinion of carry on with the existing process, and it doesn’t really matter - I will rephrase. In my opinion it doesn’t really matter. I don’t think that the ones who have not upgraded their routing infrastructure yet will probably not do so until they have to. That’s all I’m saying.

However we get to that point, whether we extend the time period or reduce the time period, I’m not sure is that important, and I think that can be easily validated in the operator community.

Jason Schiller: So ARIN should give out 4-byte ASNs unless a customer specifically asks for a 2-byte?

Aaron Hughes: I’m saying you can validate that in the operator community.

Vint Cerf: I’m sorry. If you don’t mind my intervention, I think that what Jason is trying to get is a very precise statement of what - let’s take ARIN, in particular, what policy should ARIN adopt in the assignment of ASNs. And I think he wants you to say something more explicit than carry on, that’s all -

Jason Schiller: What does carry on mean.

John Curran: If I can say the present practice, he can say if carrying on is good. The present practice is when you ask for an ASN, if you ask for an ASN and you say I want an ASN, we go - we send a message to you saying you know that there’s runout and 4-byte ASNs are available, okay, and do you want to use a 4-byte ASN. But if they come back ask for a 2, we give them a 2.

So that’s the present practice. There’s an implication behind the scenes that that 2-byte pool that we’re holding doesn’t get in the way of requesting another block from IANA. That’s the present practice.

Aaron Hughes: So in my opinion, the current practice is fine. In my personal experience, when I have applied for ASNs, I simply in the initial request ask for a 2-byte when I need it and ask for a 4-byte when I need it, so I’ve always received the response that was expected.

Jason Schiller: Do you feel we need to change global policy such that ARIN holding a pool of underutilized 2-byte ASNs does not prevent them from getting additional 4-byte ASNs.

Aaron Hughes: I don’t have an opinion on that. I think that the operator community is the best place to find out if the timeline is really important.

Jason Schiller: Thank you.

John Curran: Microphones remain open on the 2-byte/4-byte situation. Remote.

Tina Morris: Yes, remote from Andrew Koch, TDS Telecom: In reply to Aaron, there are some operational issues. One of the troubles with 4-byte ASNs is that when they are used as part of the BGP community setup, there are limitations to the BGP community field size. There are IETF drafts to expand this, but I’m not aware of any implementation.

John Curran: Any last comments on the 2-byte/4-byte? Yes, rear microphone.

Gaurab Upadhaya: This Gaurab from Limelight Networks. I was just going to try to answer to Jason’s - follow up on that. I don’t think you’ll get support on changing anything like this on a global policy. At least not from other regions where even the data that was presented yesterday by Leslie, so that other regions are doing fine with huge number of 4-byte ASNs, and if this region is lacking in that, then I’m not seeing this policy being passed as a global policy.

So you need to do something to promote - just like we to promote v6, maybe it’s time to say that 4-byte ASNs are what we need to do and not distinguish between the two.

John Curran: Get to the microphone for 2-byte/4-byte ASN. I am closing the mics on that topic. If you need to speak about 2-byte/4-byte, you need to be in a queue now.

Yes, front, Andrew.

Andrew Dul: Andrew Dul, ARIN AC. I do not support changing the global policy regarding this at this time. If there’s a definitional question of how to interpret the policy, I would interpret it as using an undifferentiated pool and if an RIR requests a certain number of 4-byte or 2-byte that the IANA comply. But otherwise the IANA is free to issue however it likes out of the undifferentiated pool.

John Curran: Thank you.

In the back we’ve got a queue. Is that 2-byte/4-byte.

Sean Kennedy: Yes, Sean Kennedy, XO Communications. Something very quick. As far as the buy one 4-byte get ten free or the click flow through on getting ASNs in general, the operator community has been very clear that we want people to show that they need a multi home, that they have multiple providers, and they need an ASN.

And so making it much easier to get an ASN or buy one get ten free could influence the routing system, and it would be a policy change. If you want to refine the policy and the operational systems, that’s great. Do that within what the community has already asked for, which is to show that you need a multi-home. Because there will be always discussions.

There’s concerns in the operator community about multi-homing, about multi-homing with IPv6, which was set up as provider based addressing.

John Curran: 2-byte/4-byte ASN, keep going.

Sean Kennedy: So there’s some discussions we may want to have in the future about how to number those people in multi home to make it easy to proxy aggregate and so on. That’s out of that. But don’t change the policy without a policy proposal.

John Curran: Okay. Got it. Next, Matt, 2-byte/4-byte.

Matt Pounsett: Matt Pounsett. To expound on what Aaron said, I think ARIN should continue with its current procedure until you’re forced to just hand out 2-byte ASNs and then do that.

John Curran: Got it. Okay. Next, Jason 2-byte/4-byte ASN or different topic.

Jason Schiller: Same topic.

John Curran: Keep going.

Jason Schiller: Sounds to me like what I’m hearing is stay the course. Can I have a show of hands? Is that what the community wants?

John Curran: I think you need to judge it yourself unless there’s a concrete proposal to change.

Jason Schiller: Sounds like to me to stay the course I would compel anyone to get to the mic right now if they disagree with that because that’s what I’m hearing from this community.

John Curran: All right. Thank you, Jason. On 2-byte/4-byte ASN or something else?

Microphones are open for all other topics. Go ahead.

Kevin Powell: Good afternoon, everyone. Kevin Powell here from the University College of the Caribbean, ARIN Fellow, and let me get my two bites in.

I’d just like to thank the ARIN Board of Trustees, the Advisory Council, and all the staff members at ARIN for affording me and as well as the other two fellows this awesome opportunity to come, to learn, and to just share in this wonderful seminar conference.

I have learned a lot over the last three days, and I really want to go out and just do some more outreach work in Jamaica about the Internet, Internet governance, and many of the other things I learned here this week.

So on record I want to express my appreciation to everybody. Thank you for the scooter here. It has come in handy. And thank you again.

John Curran: Thank you.

(applause)

John Curran: Open mic remains open. I’m going to close the mics in a moment or two. If you want to talk about any other topic, approach the microphones.

I’m closing the on site microphones momentarily. On site microphones are closed. Remote?

Vint Cerf: Does that mean if you’re on a laptop and you link somewhere that you can still say something, because you look like you’re remote?

John Curran: I’m looking - no, no one tried it, but probably. You might have had a window. That’s open mic loopback.

Thank you for the open mic session. Round of applause for everyone.

(applause)

Closing Announcements and Adjournment

John Curran: It’s my honor to bring the meeting to a close.

I’d like to take a moment to thank our sponsors one final time, ServerCentral and RCN Business.

(applause)

John Curran: Some other sponsor on this page, yes, Google. Thank you -

(applause)

John Curran: - for the webcast, very nice.

And don’t forget your meeting survey. If you have the application, it’s directly in the event app. You have until 23rd of April to fill it out. There’s also one available online.

Recycle your name badge. They’re plastic. We reuse them. They don’t end up in landfills. Give them to us rather than throw them somewhere.

Thank you for being a part of ARIN 33. We’ll see you in Baltimore in October for ARIN 34, October 9th and 10th. Mark your calendar. Thank you very much.

(Meeting adjourned at 12:38 p.m.)

Network Sponsors

Webcast Sponsor