Table of Contents
- Opening and Announcements
- NRO Number Council Report
- Internet Number Resource Status Report
- Feedback @ ARIN
- Draft Policy ARIN-2017-2: Removal of Community Networks
- Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers
- AFRINIC Update
- LACNIC Update
- Specified Transfers at ARIN
- Reflections on the Internet and the US Government
- Address by ICANN CEO
- IANA Update
- IANA Numbering Services Review Committee Update
- RIPE NCC Update
- APNIC Update
- Addressing 2016
- Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers
- Software Development Update
- Open Microphone - Tuesday
- Closing Announcements & Adjournment
Opening and Announcements
John Curran: Good morning. If people will come in and be seated, we'll get started.
Welcome. I'm very happy to see everyone up at such a bright and early time for New Orleans. Hopefully everyone enjoyed themselves last night.
I'd like to start our second day of our Public Policy Meeting, remind everyone that we have remote participants, and, therefore, we'll be seeking questions and comments from remote participants as we go. They have access to all the materials and the transcript.
We have--time to thank our sponsors. A round of applause for the network.
John Curran: Also for our webcast partner, Google.
John Curran: And our break sponsor, Avenue4.
John Curran: Okay. We will have public policy discussions today, and we'd like everyone to have an opportunity to participate. To that end, identify yourself when you're at the microphone. Please be clear. To the extent that you can speak slowly -- that's not my forte, as it turns out, but if you can speak slowly, somewhere there's a wonderful transcription person who's working on this who I'm sure would be appreciated.
So clear, slow--say your affiliation. Please be polite. If you've spoken on a topic, let everyone else speak before you jump back into the line.
Okay. At this time, I'm going to go through the first item on the agenda, which is the NRO Number Council Report.
Oh, sorry. Download the meeting app. Didn't say that. And one more slide. We might be losing this up here. Can you advance me one slide? There's the agenda. Yeah, we're losing this.
I'm going to put this in Jason's capable hands to recharge it.
So today's agenda. We're going to have the NRO Number Council Report. We're going to have Internet Number Resource Status Report, which will be given by Leslie.
We have two policies in the morning block, Draft Policy ARIN-2017-2: Removal of Community Networks, and we have the Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers.
We'll get RIR updates in the morning from AFRINIC and LACNIC. We will then do an update on specified transfers at ARIN given by John Sweeting. Then I'll give a little talk that I gave at NANOG, "Reflections on the Internet and the U.S. Government."
So that's our morning block until the break.
I'll start right in on the first one, the number community report. Come on up, Kevin.
NRO Number Council Report
Kevin Blumberg: Good morning, everybody. My name is Kevin Blumberg. I'll be presenting the NRO NC or ASO AC, depending on which organization I'm speaking with, and we'll explain that in a little bit.
So the ICANN ASO AC, Address Council, not Advisory Council. In the ARIN region, the AC is referred to as the Advisory Council; and when we're talking about ICANN, it's the Address Council.
We are 15 members from all of the regions. There's three members per region. Two are elected. One is appointed. So in my case, I was one of the appointed. Jason Schiller -- wave, Jason -- and Louie Lee are both of the elected members for the ARIN region. And it's on a staggered three-year term in our region. So we have all of the different regions on the NRO Number Council.
One of the main focuses of the NRO Number Council is to provide people to serve on the Address Council, the ICANN ASO AC. That is our main focus.
We meet monthly by teleconference. We meet annually at the first ICANN meeting each year to have a face-to-face meeting, workshops, et cetera, and that just concluded in Copenhagen ten days ago or so.
So here's a list of all of the people that are on the ASO AC and their terms that are coming due. This year was actually a little bit of a change. For the first time in nine years, we had a new chair, and it switched from Louie Lee, who's been the chair for many, many years, to Filiz.
Louie, wherever you are in this room, I'd like to actually thank you for your nine years of service as a chair.
Kevin Blumberg: Yes, and your hat. And eight years of your hat.
As somebody who's been on a number of volunteer bodies, herding 15 people is difficult. Herding 15 people from around the world is monumental, and it's quite an achievement.
Okay. So as I mentioned, we do a meeting every month. The meetings are all minuted. So you can go to the website, which will be -- we'll have later on, and actually see the types of things that we are discussing.
Since the last ARIN meeting in October, we've had four teleconferences and our face-to-face meeting. We also have a number of procedures in place to allow for emergency meetings if they're required. Thankfully, that has not been the case for quite a while.
So we don't develop policy. It's a very important part of what the ASO AC does or doesn't do. The main point of the ASO AC is to make sure that, when there is global policy, it is handled appropriately and correctly and by the procedures for each of the regions.
And then that goes up towards ICANN, and there's a nice little slide that's going to come up in a minute. But we aren't there to write policy. No policy wonking goes on at the ICANN meetings. That is done at the RIR level.
We have the technology. Just -- there. So there's a wonderful graph that we put in showing how the workflow goes. If anybody in this room can have a great elevator way of explaining that, I would love it. Please come to me. Because it does take a little getting used to, all of the different sort of interactions between the aspects.
The most important part is we're here to make sure that global policy is taken care of. The specifics beyond that I wouldn't be too concerned about. If you do want to see the slide, it is on the web site.
Okay. So the most important part, there are no global policies currently in process. It's been, I think, four years since the last global policy, and we are always looking out for that next global policy that might come along. But the good news is there are no global policies at this time.
What we wanted to do was sort of show you the kind of day we have at an ICANN meeting, at a face-to-face. So we do updates. We talk about the transition. In this particular case, this year it was the post-transition from IANA, and I'll talk about that more.
The NRO does a report like the NRO did yesterday. There's sometimes talks -- in this case, I think it was Nurani did a talk on accountability work that's being done at RIPE.
We do open mic. We have a face-to-face meeting. We meet with the Board, the ICANN Board, and that's actually a public session. So the world can see us interacting with the ICANN Board. They will have questions for us. We will pose questions to the Board, and then they will pose questions to us. And the community can see the type of interactions that go on in that regard.
There was an ASO's chair with the GAC, the Governmental Advisory Committee, and Aftab Siddiqui did a presentation to the Fellows trying to explain the number side of the world to a bunch -- or a very large set of ICANN Fellows that had come. So it was definitely a long, fun discussion, just like we have with the Fellows here. We did that for the Fellows in Copenhagen.
Okay. So one of the other tasks that the ASO AC does is two ICANN Board seat selections. We've got to prepare for the next one, which is, I believe, a year away, give or take. So we've already started the process of setting the procedures, the timelines, reviewing the procedures that we have in place already towards the ICANN Board seat selection. There's a significant amount of work that goes into a board seat selection -- interviews, written questions, verifications.
We take it extremely seriously, and there's, from what I can see, a huge amount of work that goes into that seat selection. As was mentioned yesterday, there's a review of the ASO that is currently in progress. That's done once every five years, I believe.
We're looking -- I believe we just had our voting procedures updated. So one of the things that we do -- now, I'm new. I started in, I believe, August, give or take. So I'm new to the whole process.
One of the things that I see we do a lot of is make sure that the procedures that we have are tested and tested and tested, even if they're not used, because you never know when they're actually going to be used. And if you don't know how they work, it makes it very difficult when you actually need to use it.
So what we realized was there was an issue with how the voting procedures, when it came to seat selections, et cetera, were done, were many people on the advisory -- Address Council, so we actually came up with a whole new way.
We then tested it. We ran it through -- was it football players that we used as an example? Rugby players? Soccer players. To run through and see was the procedure, how we were going to vote, actually going to work the way we thought it was going to work?
You can put something on paper. You can implement a policy, but until you actually work through that procedure, you're not going to know. That's what we did there.
I'm going to leave the best for last, the post IANA transition and community powers and a whole bunch of other things related to the transition.
Everything that we've done -- didn't change in October, wasn't supposed to change in October, but that doesn't mean we don't review and revisit everything and how we do things and were there any changes.
So there's a lot of things that are going on. The one is community powers, and the NRO EC, or the Executive Council, is going to hopefully be giving us some information on the community powers.
But post-transition, the ICANN bylaws -- and, John, if I say it wrong, please let me know. The ICANN bylaws required a substantial number of new things to happen, and we now need to just figure out how they're going to happen and who's going to do those things.
So it's, again, revisiting how we have done things in the past, and in regards to the community powers, it's a whole new set of things. And who handles them and how they get handled now need to be figured out. So that's the community powers side of things.
Are there any questions? Wonderful. Enjoy the rest of your morning, everybody.
John Curran: Okay. Thank you, Kevin. Next up we have Leslie Nobile, who will give the Internet Number Resource Status Report.
Internet Number Resource Status Report
Leslie Nobile: One second. Okay. Thank you.
So this is the NRO joint stats report, as we like to call it. John mentioned it in his presentation yesterday. This is one of the documents that the five RIRs produce together, and it shows our IP number resource statistics in a side-by-side format.
We update this four times a year, quarterly. So this is a little bit stale. It's from 31 December 2016. We haven't prepared the first quarter of 2017 as of yet.
Another thing to note is this presentation, I think we first put this together in 2002. Richard was one of the people, myself, Nurani, a bunch of us in the early days.
It's still the same presentation, same data. So we are in the process of revamping, revising this presentation. We hope to have it out before the end of this year, and we're adding a lot more data, a lot more relevant data to today's sort of Internet. So this may be one of the last times you see it. Yay.
So the first slide might be one of the more interesting ones. This is the entire IPv4 address pool, and it shows how it's been divided over the years. So looking at the large pie over to the left, that's the total space. I'm going to sort of start to the right with the not available space.
There's 35 /8s that are being used by the technical community. They'll never be available to use by the RIRs. You can see how it's broken out -- experimental, local ID, loopback, private use, and multicast.
If you go below that, you'll see the IANA reserved is 0. So the free pool is completely gone. And I'm actually skipping back up, sorry, to the top.
The central registry, 91 /8s were issued prior to the establishment of the RIR system. So these were the predecessor registries to the five RIRs. It was -- IANA was issuing space way back when in the '80s, and then it was the SRI-NIC, then the DoD NIC, and then the InterNIC. So 91 /8s were issued then, most of them to the ARIN region because that's where the early growth of the Internet was.
Then you'll look in the blue space, the RIRs have received altogether from IANA 130 /8s. Looking at the blue circle below, you can see how it's divided. APNIC received 45; ARIN, 36; AFRINIC, 5; LACNIC, 9; and the RIPE NCC, 35.
So this one is definitely out of date because things have changed recently, in case any of you are on mailing lists, but this shows the available IPv4 /8s in each of the RIRs, and I'll start on the left with AFRINIC. It says they have 1.27. But they made an announcement yesterday that they've actually reached their last /8.
Let's see. APNIC has .44; ARIN, 0; LACNIC, .018; and RIPE NCC, .84.
The thing to note about this is these numbers fluctuate based on whether or not the RIRs get space back from their customers. Sometimes they reclaim space due to nonpayment of service fees. Sometimes people return space. And we all get space twice a year from the IANA under a global policy. But that supply from IANA is dwindling, so there's a few more allocations yet to come, but that does make those numbers fluctuate.
And the other thing to note is that in these numbers you are not seeing the space that all five of the RIRs hold in reserves. We have reserved space for particular policies, and we don't reflect that as available space.
In the new slide that we're doing, we're actually going to account for every single address space, and we will tell you what's reserved and what's held and what's available. So it will be more interesting, I think, in the new slides.
So I'm going to run through some of these pretty quickly. There's not a lot to say. This one, the thing to note, at least in my opinion, is the growth in the APNIC region starting around 2006, 2007, '8, there was a real surge of activity, and the IPv4 address space went quickly.
In 2011, that is when the IANA ran out of space.
This shows -- so we only went from January 1999 to 2016. We couldn't fit any more. And, quite honestly, in the new slides, we're even going to make this less of a time span because we can't really fit every year. But this is cumulative, and it shows the total amount of space in that amount of time that each of the RIRs have issued to their customers.
This is not as good as the other one.
This shows ASN assignments to customers. And again, it's just the growth trends up and down. Initially, ARIN was issuing more Autonomous System numbers than any of the other RIRs, and somewhere around 2002, '3, '4 -- wait, '5, RIPE NCC started issuing many, many ASNs, and they continue to do so today.
This is the cumulative total in that time frame, how much -- how many total ASNs each of the RIRs issued to their customers.
And we broke out the 4-byte ASNs. We were tracking this separately because initially they were not being accepted by the community. ISPs were having a difficult time, so we broke them out to show that early on we were not issuing very many of them.
And then as we ran out of 2-byte ASNs, we had no choice but to issue the 4-bytes by default. At this time, most of the RIRs are issuing 4-byte ASNs, and we hear very few problems from our community about the 4-byte ASNs.
And this is the cumulative totals for the 4-byte ASNs. This is the IPv6 address space. It's the total pool, /0. A /3 has been broken out as global unicast space for the IANA to issue to the five RIRs.
There's 506 /12s left in the global unicast space. One /12 was set aside for technical purposes, documentation, miscellaneous purposes. And then each of the five RIRs received a single /12 in October of 2006. All of us are still working from that original /12, 11 years later.
I think some of us are probably able to qualify under the global policy for additional space, but none of us have gone back yet to the IANA.
This just shows the IPv6 allocations, and again you can see, much of the growth is in the RIPE region.
And that is shown very clearly here, when you look at the cumulative totals of the IPv6 allocations to ISP customers.
So this is IPv6 assignments to our end-user customers. Early on, ARIN -- I think ARIN and APNIC were the only two RIRs that had end user IPv6 customer policies, and so that's in the early days it was just the two of us issuing to end users. And then the other three RIRs adopted the same policy.
It was interesting to me to note that, in the APNIC region last year, they issued more end user v6 assignments than any of the other RIRs. That is the first year that I've seen that. And these are the cumulative totals, RIRs to end users.
And this is -- we are looking at the percentage of our members who have both IPv4 and IPv6. And these numbers have grown pretty drastically. We're really happy to see this. 34 percent of AFRINIC's customer members now have IPv6. Almost 53 percent in both APNIC and ARIN have gotten their IPv6. LACNIC, over 87 percent of their members have their IPv6 allocations. And in the RIPE region, about 75 percent. So those numbers are good.
And those are just links to the statistics, if anyone is interested in doing a little more digging. And that's all I have.
John Curran: Questions for Leslie?
Chris Tacit: Hi, Leslie. Chris Tacit. I'm always curious about, when we do the IPv4 report, we always accept this thing that IANA has 35 /8s that are reserved for some purpose that are never available. Can you elaborate a little bit on why that much space will never trickle down?
Leslie Nobile: I'm going to -- John's the techie, but I will tell you that space is actually in use. It is in use by the technical community, IETF, et cetera. It's not just sitting there. If John wants to say anything else, he can give you some history.
Chris Tacit: OK, thanks.
John Curran: Which specific allocations are you talking about?
Leslie Nobile: The 35 multicast and testing.
John Curran: So the IP address space is a big thing, and some of it is unicast space, global unicast, and that's what the RIRs get to administer.
There is a lot of other space that isn't ours to administer that the IETF uses for other purposes, including some space that they use for other purposes like -- category of space, like class E that they define for future use and then never -- you're going to correct me, Geoff? Go ahead, Geoff. Some of the space may be dead forever. Some of it may get redefined. And then the question is: Can we update all the communications? Go ahead, Geoff.
Geoff Huston: Geoff Huston, APNIC. There was an allocation made by IANA reserved for future use, which was, as I recall, an eighth or a sixteenth of the total space, which is a large amount of space.
We looked at this as a community in the IETF back in 2008 and 2009. Paul Wilson and I wrote a draft. Vince Fuller wrote a draft. The problem that we found was that you need to recompile almost every piece of running code in both routers and end systems because there is a code block that says if the address has these bits set up in class E, ignore that packet.
Now, we then thought this could be done, or we could work on v6. There's not an infinite amount of energy in this community. What do you want to work on? And the pragmatic view was leave it alone, let it rot. You're only going to alter exhaustion by a few months at most either way. It ain't going to make much difference. Go work on v6.
And that was kind of the background as to why there's that class E space reserved for future use that is never going to get used in any future we understand. Thank you.
Leslie Nobile: Thanks, Geoff. Yes, hi.
Brent McIntosh: Brent McIntosh, Cable and Wireless. Leslie, to start off your presentation, you mentioned that you actually were looking to put new data in that presentation. Do you have any idea what that new data is going to be?
And also, do you request feedback from other entities other than the RIRs on what data we would like to see? Would you reach out to end customers to ask?
Leslie Nobile: That's a good question. I like that. If you have any ideas, we'd like to hear them. We always welcome ideas from the community. So that goes without saying.
But as far as the slides, we're going to add a lot more data about transfers. There's so many varieties of transfers going on in all of the regions.
So we're going to add a lot of transfer information, and we're just going to re-represent, if that's a word, some of the data that's there already to add more details. So --
Brent McIntosh: Okay. Great. That's exactly what I'm looking at. And also would this report share breakdown by region, for example, allocations done in the U.S. for example, by state, China, Canada? Would you get that deep into the data?
Leslie Nobile: We could. It's something we could look at certainly, sure. Thank you. Owen is in the back.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. One of the data that I think would be interesting would be to see how the increases and the mobility of address space through transfers, especially inter-RIR transfers, is affecting the fragmentation of the routing pool.
Leslie Nobile: Okay. We'll take -- this is being recorded. So we'll remember. Chris?
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. If you go back to the IPv6 allocations, you had a slide that showed that each RIR has so far received one /12, and then there's a subsequent slide that counts the number of allocations that each RIR has made.
I'm curious what percentage of each /12 those allocations represent. If you have any information on that.
Leslie Nobile: It's a good question, and I don't have it off the top of my head. I do know that several of us are well over the 50 percent mark of the original /12, which I believe is what the global policy says that -- when we can go back to IANA. But I don't have those numbers right now. If that's something we should consider for the future slides, we will note that.
Chris Woodfield: Thank you.
Alain Durand: Alain Durand. To answer Owen DeLong, I started a study to look at the cost of the number of entries into the RIR database, the delegated files. And the request to go off into the BGP table. So it's an ongoing study that I've started.
Leslie Nobile: So you have that available data. Great. Thank you for your attention.
John Curran: Okay. So the policy block starts at 9:35. It's 9:29. I don't want to start early. I'd rather start late than early. So I'm going to wedge a little presentation in here.
Richard, come on up. I'm going to have Richard give a presentation in ten minutes about input, how you can give us input. Go, Richard.
Feedback @ ARIN
Richard Jimmerson: Hello, my name is Richard Jimmerson. I'm going to talk to you about how we get and how we process feedback inside the ARIN organization. I think a lot of you are familiar with some of the ways we get this information because you've used the facilities that we have. But you might not be familiar with all of it.
First, a bit about the importance of feedback to the ARIN organization. It is important to us because it identifies service improvement opportunities inside the organization. It highlights things that might need immediate attention inside the organization.
One of you might give us some immediate feedback somewhere and say this particular service that you have is not working properly and allows us to quickly respond to that and fix that.
It also helps with determining project priority for future improvements inside the organization. At any given time, we've got about two years of work lined up that we can do inside the organization to improve our services for you, and the feedback that you send us actually helps us prioritize that work as we move forward and get things done.
Also, it helps assist in the monitoring of our service quality. It alerts management of customer service issues. If you have a negative experience with the ARIN organization and you give us feedback about that, I guarantee you that is immediately heard inside the organization and it is addressed.
It also helps us better understand how well we're doing or how well we're not doing, and we use this on a rotating basis, on an ongoing basis to help adjust our services and make sure you're getting the services that you deserve.
And it also helps us improve performance. If you send positive feedback to the organization about a particular staff member or something that you like that they were doing, that helps us do more of that. It also helps us reward that staff member.
If you send us information about something that a staff member did that you didn't like, we have a conversation with that staff member, and it helps them do better next time and motivates them to go on a corrected path and provide the services that you like.
And also, it helps us learn from you with the things that are important to you.
These are the feedback sources where we get information from, the people that give us the feedback. We have 5,000-plus member organizations at ARIN. And in addition to those 5,000 organizations, we have 15,000 fee-paying, non-member organizations. So we have over 20,000 organizations who pay fees to the organization each year. They send us lots of feedback.
We also have the legacy organizations that we service. Those organizations are over 16,000 that don't fit into one of the categories above. We provide services to them throughout the year, and they give us lots of feedback. And we continue to listen to them.
And ARIN online users that have web accounts that use ARIN online, there are over 123,000 user accounts there.
In addition to that, we have the general Whois user population that may not fit in one of the above categories. And people who were referred to ARIN by the security software: "Hey, somebody's port scanning me or hacking me or something like that." They think ARIN is like the Internet police or some sort of enforcement agency, and they reach out to us, and they have conversations with us about that.
Our feedback channels inside the organization. Of course, we have the feedback button that allows you to provide instant feedback from anywhere on our site. We have transaction surveys. Anytime you come in and you request Internet number resources from ARIN, we have a transaction survey that you can go fill out, and we receive feedback from you when you do use it.
We have documented feedback from telephone calls and tickets. We have a help desk that runs from 7:00 a.m. to 7:00 p.m. all week, and we get lots of feedback over the telephone and VR tickets. We have an internal system where all of that is documented so that it can be used in other places inside the organization.
We have the ARIN Consultation and Suggestion Process that a lot of you have used. It's a formal process for us to consider your suggestions.
We have a customer satisfaction survey that we did in 2014 and the Board has approved again for doing in Q3 of 2017.
And we get direct feedback at meetings -- in the hallways, from the microphone, and things like that. And, of course, you give us feedback on mailing lists and via social media.
How we process the feedback inside the organization, is we have internal review and discussion about all of this. We collect all of this information. We have weekly management team meetings where this information is featured. We have scrums in meetings throughout the week with our teams where this information is featured.
And we have biweekly customer experience review meetings, where we look at all of the feedback that we've received to see what adjustments that we might need to make with our services.
We turn your feedback into change and action inside the organization by taking this documented information, making changes to our public web site, where there might be additional training material or guidance material that needs to be updated.
We'll update our procedures inside the organization when it's necessary, to streamline things for you. And, of course, we use the information you provide to us to help with the improvements we're making in our applications in ARIN Online and in our user interface.
We continue to review and monitor this information throughout the year every week as we get it. We also take major items of feedback that we get, where we have a lot of people telling us the same thing that might actually be a big change inside the organization. We do community consultations on those, and we send them out to all of you so that you can comment on them and let us know if that's something you think we should do or not.
And also for larger items than that, we now have the Services Working Group where we can send large changes for services for review by the community.
Our continued commitment to you -- and this has always been true, and it's true today. You are our number one priority. That's why we're here. That's why we're doing these things, is to provide the service that you trust us to do.
We value your feedback immensely. It's a key element to our decision-making process, as I described, and we can't do our job, we can't function as a registry, without getting your feedback on a regular basis.
I wanted to share just one quick excerpt from the ARIN Staff Values Statement that we created in 2014. We asked the ARIN staff and the organization, without prompting or guidance, to just state what their values were, why they were there and what they were doing, and here's an excerpt from that. This is what they wrote.
Inside of that, you can see their interest in providing their service to you and getting your feedback so that they can do a better job.
They came up with four statements, and we put those on the wall. This is how they conduct themselves every day. They see these things. They pay attention to these things. They're actually rated on these things when they get reviewed every year. And we have this right next to ARIN's annual strategic direction and separately our organizational objectives that are created and approved by the Board of Trustees each year.
Just a quick quip. Some ARIN staff member has a great idea about something they would like to do inside of a management team or otherwise, and Curran or Nate's response would often be: "Can you go outside and tell me if that's on the wall?" And if it's not on the wall, we don't do it.
So he keeps us -- Nate and John keep us very closely in tune and in line with our strategic direction and the organizational objectives given to us, passed down to us by the Board. And the staff conduct themselves on a daily basis providing services to you according to the value statements that they put together, and your feedback is very important to them.
So thank you very much.
John Curran: If folks have questions or feedback, hopefully, that will help guide the process in terms of letting you know how to get ahold of us. Yes, go ahead.
John Sweeting: John Sweeting with ARIN. I wanted to just give Chris his answer on the IPv6. It's been issued. 3.89 percent has been issued, 10.98 percent is reserved, and 85 percent is free of our /12.
John Curran: So we've got lots of room.
Draft Policy ARIN-2017-2: Removal of Community Networks
John Curran: Okay. It is now time for the Draft Policy ARIN 2017-2: Removal of Community Networks. It is 9:38. So we are in the block. Very good.
This is a draft policy. So I'm going to ask Alyssa Moore to come up and give the presentation.
Alyssa Moore: So we have a pretty straightforward one first thing in the morning here after the social, which is nice.
The problem statement: Community Networks section of the NRPM has not been utilized since its inception in 2010. So there are special provisions for Community Networks in NRPM, none of which have actually been put into practice or ever used.
Last year there was a policy proposal to expand the scope and loosen the requirements around what constitutes a Community Network. But, the Advisory Council abandoned it because there was not enough feedback, and we did not have enough information to move forward with it. So this one came up this year.
So I just gave a little bit of background there. But I did want to read out the exact definition, which defines a Community Network in Section 2.11.
So any network organized and operated by a volunteer group operating under the fiscal support of a nonprofit or university for the purpose of providing low-cost connectivity to the residents of the local service area. To be treated as a community network under ARIN policy, the applicant must certify that the community network staff is 100 percent volunteers. So that equates a tight definition there.
And then further down in Section 6, which deals with IPv6, we have the explanation for the rationale for why this is implemented in the first place.
So I think we can all agree that community networks are kind of a special case in the ISP landscape because they depend on volunteer labor largely and very tight budgets. So that was the explanation for the rationale for why this was instituted in the first place.
So the policy statement basically just moved all mention of Community Networks in the NRPM. So this definition that I just read out would be coming out.
This clicker is a pain.
John Curran: There's a half-second delay.
Alyssa Moore: Again, so further down in Section 6, this would come out, and then it's continued here. So this goes into the details of the qualification criteria. And I have a couple notes here. Come on.
So it's important to remember that this deals only with IPv6 resources. It doesn't apply to v4 at all or to ASNs. So there's no special provisions for community networks around those resources, and if this policy were to go through and pass, organizations who were previously eligible under this policy but have never used it, they'd still be eligible for v6 resources, but they would just qualify as an ISP rather than an end user.
So I have a bunch of questions up here, and I know we actually have some community nets at the meeting today, which is awesome because we'll actually get some feedback here.
Most of all, I want to know why hasn't this been used in its current incarnation and are there networks that could qualify who fancy themselves community nets but don't fall under this definition. Is there any future harm that we could foresee from removing the section entirely, and is current policy sufficient without Community Networks specifically mentioned in the NRPM?
So I can open it up to discussion now.
Marita Moll: Good morning.
Paul Andersen: I didn't even have to incite you, and you're already lining up. Normally post social it takes a little stirring to get people going.
Okay, draft policy. You guys know the drill. Same as yesterday. Rear microphone, please.
Marita Moll: Good morning. My name is Marita Moll. I'm here for Telecommunities Canada, which is a loose coalition of community networks and community networking advocates in Canada.
This is the first time I've been to an ARIN meeting, and I'm here with the NARALO group. Thank you so much for allowing us to twin with this meeting.
Obviously, we're a year late because we would have been speaking at this last year. So glad to be here because, when I flipped through the things that were going to be discussed here, I saw Community Networks, and, obviously, that quickly got my eye.
I sent out a note to our list, which contains a handful of community networks and other people who work in this area, about what they thought about removing this particular policy piece. And the response I got, just to bring another voice into the room, was: It doesn't hurt to leave it in, does it? It could be useful if community networks knew about it, which I'm sure they don't.
So that's one thing. We need to -- reason why it hasn't been used, people don't know about it. And the other reason why it hasn't been used is because the definition of Community Networks is really pretty onerous for this day and age. Thank you.
Paul Andersen: Thank you for your comment. Front microphone, please.
Scott Sullivan: Scott Sullivan, various Toronto technical communities. I volunteer with the Toronto Free-Net, Toronto's oldest ISP and run by its members. They are a volunteer organization, but I know they have plans to include paid operators if they grow enough to be able to afford it.
The 100 percent volunteer requirement makes that onerous and dangerous to their growth because they could lose that status.
I haven't looked into this policy enough to understand the implications, but I wanted to make that comment. Thank you.
Paul Andersen: Thank you. Rear microphone.
Shelley Robinson: Hi, I'm Shelley Robinson. I'm executive director of National Capital FreeNet. It's a not-for-profit ISP, but we would also consider ourselves a community network.
I definitely don't fit the definition. So I started two years ago, and we had four staff, and now we have eight staff, and that's actually enabled to do our mission better.
So when I started, we were trying to do low-income services in a loosey-goosey way, and now we have an official program for all community housing tenants in our city, and that's because we have more staff capacity to serve them.
I would want to make sure that people aren't struck off the list because of this. I think the definition bears re-looking at.
That said, I do have my IPv6 space because I could afford the $1,000, and I did find out about ARIN, although relatively recently. So I would echo Marita's comment that the reason there wasn't much discussion on the PPML about this is because folks don't know about it. So I feel like there's an outreach piece, which I'm happy to help with in the future now that I know, but I think there is more that can be done around this.
I wouldn't want to see this happen and then disqualify people who didn't even know it could apply to them.
Paul Andersen: There's been a lot of comments about how it's not used -- are you against removing this and perhaps looking --
Shelley Robinson: Correct.
Paul Andersen: It sounds like a lot of these comments are about changing the policy, which is different than what's being proposed here.
Shelley Robinson: I am against removing community networks. But I don't know the text of the one that was proposed last year, but like Marita said, I think that was probably something I would be keen on. I would suggest I'm against this, removing community networks entirely, and then maybe looking at them afresh through a new policy development. Does that clarify?
Paul Anderson: Yep, thank you. Front microphone.
Celeste Anderson: Hi, Celeste Anderson, University of Southern California. Got 30 years of experience of taking non-profits and making them into networks, and there's always a point at which you have to hire somebody to do some functions. So I will absolutely say that the definition is too narrow to get started.
I'm against removing it because we took a lot of effort to put it in, and instead I'd like to improve it so that it could actually be used for people to create them.
And I think the one thing that's missing is when do you transition from being a community network to a regular one? And I think there's something there that, if you start as a community network and you grow, we haven't really defined what happens and whether you get recategorized at some point.
Paul Andersen: Thank you. Yes? Sir, one second, please.
Dan Alexander: This is Dan Alexander, ARIN AC. I just want to kind of interject some thinking as to why the AC is looking at this that might help some of the previous comments.
One of the main reasons why this section was actually created in the first place was under older fee structures it was intended to give a special category for these type of networks so they would fit into a different fee category and pay lower ARIN fees and make it more affordable to them.
With the new fee structures that are in place, those -- these special requirements were essentially removed because community networks have the ability to choose whether they would want to be treated as an end-user organization or an ISP.
So because of the fact that the fee structures were changed and the flexibility was added, the AC can -- was considering this as kind of a redundant piece of information. It wasn't -- we weren't thinking of removing it to exclude community networks from anything. It was just because the special categorization wasn't required regarding fees, we just thought it would be a matter of cleanup and just removing this.
Paul Andersen: Thank you, Dan. I think we have remote participation.
Alison Wood: So Kevin from Flying Penguin Technologies would like to say that he's all for simplifying the NRPM, but he doesn't support 2017-2. And he says just because the community network designation has not yet been utilized, it doesn't mean it will not be in the future, especially given how nascent IPv6 deployment unfortunately still is.
John More: My name is John More. I'm from the DC Chapter of the Internet Society. I'm here for their NARALO meeting. I've been heavily involved in community organizations.
Even with the -- on the first point, even with the fact that the fee changing, I think there needs -- you don't know what the fee is going to be in the future. So I think this should be kept as some sort of guarantee for continuing recognition of community networks.
The second point is that the requirement that there be no -- that it be pure volunteer runs in the face of any effective community organization. To be really effective and then make the volunteers effective, you need to have a paid staff. So I really reject that point. Thank you.
Paul Andersen: So you oppose this policy?
John More: I would keep the -- I oppose removing it, yes.
Paul Andersen: Thank you. Front microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. So I'm the author of both of the policies, the policy from last year to clean up the community networks and make it actually reasonable, and the author today to remove the community networks.
I've dealt with a number of small community networks over the years, and I don't know one of them that would fit under the criteria of this. This is a policy that everybody said we needed but has never been used and actually makes it harder for community networks to get space because they look at this list and go: This is unbelievably complicated. I can't do it. When, in fact, they would fall under a very simple definition today, a very simple criteria today. They would pay significantly lower fees than what it was nine years ago, and they would have their space in almost an instant.
So by having this, we're actually harming the community networks because we're making it unbelievably complicated when there is no complication in the current IPv6 policies. So that is why I wanted it removed.
Paul Andersen: Thank you. I will assume you're in support since you authored it. Okay. Rear microphone. That's not always the case, actually. Rear microphone.
Owen DeLong: Owen DeLong, ARIN AC, Akamai, and the author of the original Community Networks policy that is still on the books and the author of the recent modifications that did get applied to it to remove HD-Ratio.
I've worked with and been actively involved in a number of community networks with varying degrees of effectiveness that did actually fit this definition. The reason they weren't able to use the policy is that they were not able to afford the fees that existed at the time that I was involved in those community networks.
I do think that there is some adjustment to the policy that needs to be done. I do think the 100 percent volunteer criteria should be loosened. I don't think removing the entire policy at this time is useful.
I think we've got overwhelming feedback from a number of community networks that are present here today -- fortunately, through largely the involvement of NARALO in this meeting, which is, I think, a very fortunate coincidence for this policy discussion --
Paul Andersen: Yes.
Owen DeLong: -- because we might not have reached them otherwise -- that have overwhelmingly said removing it is bad, and we should look at fixing it instead.
I don't think the proposal that we abandoned earlier did fix it. I think it did more harm than good. That's just my opinion. We didn't get a lot of feedback one way or the other about it. There certainly wasn't any support expressed for it except from the author.
Paul Andersen: Thank you. Dan, quickly?
Dan Alexander: Owen, can I ask you a question? I'm just curious, if we leave this in, it's -- essentially the point of these sections is to categorize them as end users versus ISPs. There's not really any necessarily special allocation aspects of the policies.
So if we leave it in and they already have the choice to be categorized as one or the other, what are we trying to accomplish with the proposal? Because we were talking about we should leave it in and we should fix it, but what is the goal of the fix? I'm just curious for your opinion.
Owen DeLong: Well, in my opinion, community networks are -- while they may not need special status today under the exact fee structure we have today, they certainly needed relief in the past. Fee structures are subject to change. They're not under control of policy.
And so I would want this preserved as a safety net for whatever may happen in the future. And I think that maybe there are other things that can be done to better serve community networks that should be explored.
I admit I'm not currently actively involved in community networks, and the status and situation that they're in may have changed, and I think we need to get more feedback from that community on what changes are useful and necessary.
I think now, as a result of the discussion here today, we're likely to get that. I encourage everybody here who's involved in a community network to join PPML and to also do outreach to the community networks that you're involved in and familiar with and talk to as part of that community to encourage them to get more active and more involved in ARIN policy through the PPML as well.
And if anybody's got any questions about how to achieve that, please feel free to approach me or any other AC member or ARIN staff member, and any of us will be able to help you with that. Thank you.
Paul Andersen: Thank you, Owen. Front microphone.
Cathy Aronson: Cathy Aronson. I just wanted to echo something that Owen said. It took us an insane amount of time to pass the first Community Networks policy.
Paul Andersen: I think three years. Three or four years, I think.
Cathy Aronson: Like years. Yeah, it was insane. And I think part of that was the lack of -- really, participation from people from community networks.
So I wanted to echo what Owen was saying about getting your help, the folks that are here that manage community networks and your communities of community networks, because if you really want to see this changed -- I mean, I'm in favor of removing it and writing something that will actually serve the community, and if you could help the AC and those of us who are willing to help make it happen, that would be amazing.
Paul Andersen: Thank you. Front microphone. Microphones are still open, so please approach.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I have a quick little favor to ask of staff. Could we have a little table sign for lunch for community networks? And if there isn't one, find me, the table I'm sitting at, and let's have a conversation.
Alison Wood: You got it.
David Farmer: Cool, thank you.
Paul Andersen: There you go. Staff always taking feedback in real time.
Approach the microphone if you'd like to speak on this topic. Kevin, are you approaching a mic, or are you exiting? Okay. Wasn't sure.
We'll be closing the microphones in a few seconds. Going once, twice, three times. Closed. Just check with the remote participation. No, no comments. All right.
Thank you very much, Alyssa, for the presentation.
Paul Andersen: No poll on this issue, but as you just heard, there will be a lunch table topic. Hopefully, we can get those questions because I think there's a challenge on this one that we need to understand what are the challenges that community networks are facing so that the policy can be tailored, because obviously the current policy, given its zero usage, is having challenges.
With that, I'll turn it back to John for the next policy. Thank you.
John Curran: Okay. I have a phone.
Paul Andersen: Oh, that's mine.
John Curran: Okay. Yes, sir.
Paul Andersen: It's my clock while I'm up there.
John Curran: And here I thought we got a good price, but no. Mustn't sell the chairman's phone.
Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers
John Curran: So next policy, Recommended Draft Policy ARIN 2016-9: Streamline Merger & Acquisition Transfers. This is a Recommended Draft Policy, and as such the AC has found it to be suitable for inclusion -- potentially suitable for inclusion in the Number Resource Policy Manual.
They could, after this meeting, send this to last call, and it could end up in the policy manual before the next time we see each other. So it's fairly important to comment if you have a view on this.
I will do the staff introduction, since the Recommended Draft Policy.
It was proposed in December 2016 as ARIN Policy Proposal 234. The AC Shepherds are John Springer and Leif Sawyer. Yeah, still -- something defective up there.
Has not been presented at a Public Policy Meeting or Public Policy Consultation. It advanced to Recommended Draft Policy status based on discussion on the Mailing List and the work of the AC. It's in your Discussion Guide. This is the Discussion Guide. You all have it.
Okay. So. Staff understanding. Draft Policy 2016-9 allows for organizations to submit an 8.2 Merger & Acquisition Specified Transfer without the expectation that any other resources will be revoked due to lack of justification for the resources continued use.
This draft policy eliminates any wording that might suggest that resources may have been divested by the organization seeking to update their information through the 8.2 specified transfer policy.
Staff comments. If the intent of this policy is to ensure that the Internet number resources will not be subject to a needs-based assessment, then staff suggests it say that plainly in the text.
It could result in a higher bar for approval of transfers. The original text had the language "independently verifiable," and that and the previous comment have both been adjusted. So I don't think that's now a relevant remark. Nor the first one, for that matter.
And then the third comment was we noted that it would be more accurate if the policy language was slightly reworded, and these have been all incorporated.
That's the legal assessment. Does not create material legal issues, presuming the staff comments are accommodated, as they have been.
And then resource impact. It's a fairly routine resource impact. We can do the policy within three months should the -- after ratification by the ARIN Board of Trustees. We update as usual the typical things for small policy, updated guidelines and internal procedures and the staff training.
So this concludes the staff introduction. And I will now have the presentation by John Springer.
John Springer: Okay. Well, hello, everybody. I'm John Springer. I'm here to present the AC version of this.
I have a slide that emphasizes that the staff and legal review, as part of our procedural activities, we have to go through a number of things.
So in your book, all this stuff is written down in plain English on page 10, 12, and 38. 38's the NRPM, 10 is the actual policy text that we'll be talking about, and 12 is the staff and legal review.
I have a tendency to want to read this all to you. So I'm going to be going through this on a kind of a paraphrase basis. But I did want to emphasize we have taken into consideration all of staff's concerns and that they have been incorporated into the text, and you can follow along in that process in the manual.
So. Merger -- this is strictly about Merger & Acquisitions in the 8.2 section. The assertion is as part of the process of doing a Mergers & Acquisition, organizations involved in this process end up having to rejustify addresses that have already been justified once. The net result of this is an undesirable thing in that some organizations are electing to leave the records in the registry in a now incorrect state, mainly in the name of the defunct organization.
There used to be good reasons for this, but there don't appear to be any such good reasons anymore.
Supporting points. Again, there's some more formal wording for these things in the manual, but they have -- the resources have been justified once by both parties. Other than in this case, ARIN doesn't require justification unless an organization is asking for more space, which is not really happening when an 8.2 Merger & Acquisition is taking place.
But as has been stated, this does result, seemingly, in bad registry data. We're going to -- I'm going to be going through some operations upon the policy text here in the next slides, but just as an introductory comment, the way that the previous policy text was worded, it had the effect of making the environment really murky. So, hopefully, this is going to clear this up.
Also, I will offer for your consideration the idea that chain of custody, particularly when we're talking about registry data, may be more important than auditing before addresses.
Okay. So if you flip to 38, the first effect of the new policy text is that we're going to delete the fifth bullet point in NRPM 8.1, and it essentially says, show that you've acquired the assets that use the resources that are about to be transferred.
The previous text also includes a requirement that ARIN maintain a list. We're going to throw that out.
As part of the staff and legal -- so further on in the effects, we're going to be deleting the final paragraph in 8.2. This has the effect of doing a number of things that are not quite clear. So this is past policy that we're proposing to delete. It essentially says that ARIN will proceed with processing requests even if the resources of the combined organizations exceed what can be justified under current policy.
This was modified in February of this year, as part of the addition of the 8.5 transfer wording. So the whole business has just gotten completely unclear. It doesn't say that ARIN will finish processing transfer requests until some bar has been cleared. So anyway, we're going to be getting rid of that.
Staff requested that we insert this statement that one effect of the policy is that no additional needs-based assessment will take place during the scope of this 8.2 process. Rationale, obviously, being that they've already been assessed previously.
It is stated in this way because we didn't want to preclude -- another way we could have said this is that these resources will receive no further needs-based assessment. We didn't want that. We wanted to be able to have it so that, if these resources get transferred later in a context where somebody else is receiving additional resources, that they would still be subject to a needs-based assessment.
Our Policy Effect 1 was to delete a bullet point saying that you had to show that you had acquired the assets that the resources were attached to. We're adding that back in, just without the other criteria that you need a list, that ARIN's going to maintain a list.
And this is in a section that's a list of conditionals, and we're adding an additional conditional, which is an "or," to the effect: show that you acquired the whole organization.
So you either show that you acquired the resources -- the assets that are attached to the resources -- or you show that you acquired the whole organization.
And Policy Effect 4 is to remove the final cited paragraph from 8.2, which may have had -- it's unclear entirely -- I'm John Springer, a member of the ARIN Advisory Council. I am not speaking for the Advisory Council, and I'm not speaking for ARIN staff. But in my opinion, it is unclear where ARIN derived the authority to be conducting the needs assessment that was taking place during 8.2 Mergers & Acquisitions, but if it did occur here, then we're removing it.
Here's the paragraph that's being deleted for your convenience. It's also on page 38 in the NRPM in your manual. Questions?
Paul Andersen: So this is, again, a Recommended Draft Policy. This may be the last time it is discussed at a meeting before potentially being adopted, which is why it's very important to get feedback in now. I know you're all rushing. It's the second policy after the social that gets a little bit of -- rear microphone, please.
Joe Olivieri: Joe Olivieri, Root Level Technology. I agree with the policy. Just want to put it out there.
Paul Andersen: Perfect. Thank you. Side microphone.
Dani Roisman: Dani Roisman with SoftLayer, IBM. I agree with the policy as written, and I appreciate the efforts to streamline the transfer process, 8.2, and to help make the database more accurate. Thank you.
Paul Andersen: Rear microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I support the policy as written. The explanation, I think, was a bit confusing, but the policy is actually pretty straightforward. We're basically deleting the additional needs test that was occurring on 8.2 transfers and deleting the text that says you may have to work with ARIN staff about returning, transferring, or otherwise disposing of excess space.
It doesn't seem that that text was doing much good lately, and the unintended consequences of transfers not getting recorded, I think, was doing more harm.
So even though I'm one of the people that wrote the original language and I'm a strong proponent of needs based, as everyone knows, and not in favor of completely eliminating it at this time, I do think, in this particular case, it makes a lot of sense, and we should move forward.
Paul Andersen: Okay. Side microphone.
Marc Lindsey: Marc Lindsey, Avenue4. I've got a couple of comments on the draft text and then a broader observation. One is you say no additional -- I'm in support of the policy generally. It's a good policy, good direction. I like it.
But two areas of improvement, I think. One is the additional needs-based justification. Why the word "additional"? Why not "any"? Additional, I think, adds a little lack of clarity. Had one already, this is really just about doing any more needs justification for 8.2. So I think an improvement would be any needs justification in the processing of 8.2s.
The other one is you say recipient must show they have acquired the entire entity. So I want to explore that a little bit. Why not say the entire entity and a controlling interest, because every M&A activity isn't always a full acquisition. It might be a controlling interest, which in every other context is sufficient to demonstrate an acquisition of a company.
So think about expanding a bit to reflect a true acquisition, which is a controlling interest, and not just the entire set of shareholder interest.
And the third point I'll make -- I got one more point to make if you want to address those two.
Paul Andersen: Why don't you go with the first two before you get too far behind.
John Springer: So additional. The original request from ARIN staff was without additional, but the original author's intent was additional.
As I've stated, the resources were -- had already been through a needs assessment basis -- a needs-based assessment in the case where each of the organizational participants in the Merger & Acquisition had had that done. So it is an additional needs assessment, just as a matter of fact.
Marc Lindsey: Well, no, my only observation is the way it's written here says will not be subject to any additional needs-based assessment during the process of 8.2.
John Springer: We wanted to have it during the process so as not to disqualify it from going through a needs assessment later in the case where perhaps it was going through an 8.3 transfer.
Marc Lindsey: I understand. Okay. But I think just as a drafting point, I would say you're limiting it to 8.2s and doesn't seem like it's bootstrapping 8.3s. I think the "additional" suggests that there was something initially in the 8.2 processing. Not a big point, but I think you should say.
John Springer: We'll consider your comments. How about that?
Marc Lindsey: And how about the second point about not the entire company, but a controlling -- in addition to the entire company controlling interest.
John Springer: The way the wording is added in the conditionals is that you would either acquire the assets that the resources were attached to -- routers, et cetera -- or a controlling interest. Or demonstrate that you've acquired the entire organization.
You're asking whether or not we think it would be a good idea to add a third "or" or maybe a dozen?
Marc Lindsey: So no, no, so all I'm saying is that in B you have the asset continuity test. A is two part. One is the asset continuity test, and the other is acquisition of the organization.
All I'm saying is the definition of acquisition as opposed to it being the entire company, just make the acquisition a controlling interest of the company. That's all.
John Springer: Well, I won't be able to make that determination myself. So I guess we'll have to have a chat with our legal as well.
Paul Andersen: Okay. We can take that feedback.
Marc Lindsey: And the -- and the third point I wanted to make is that I do think the policy ambiguity about returning resources has imposed some impediments on legacy holders coming forward to update the registry, but I also think the RSA is a substantial impediment to that process as well.
So you impose a set of conditions on a party who has no contractual relationship with ARIN. You want to condition their updating the registry to formalizing their relationship under a contract that has considerable terms and conditions. So I think this policy addresses a portion of that impediment. The second portion of that still exists and have to go through an RSA and forces them to have a contractual relationship with ARIN.
Earlier in a POC validation discussion, there was this notional idea about updating the registry for legacy holders, and they could choose not to have a contractual relationship because it's serving the purpose of improving the accuracy of the registry, and that on balance was a good thing to potentially abandon the obligation to enter into the contract.
I think if you added a second policy, another policy, to do that, I think you would dramatically reduce the occurrences of legacy holders who voluntarily choose not to update the registry.
Paul Andersen: I think John wanted to address that point and others. Go for it.
John Curran: Let's -- actually, now I'm up to three comments queued. We try to do them in order, and I'll take them in order.
The first one is with regard to your non-comment -- a non-AC member regarding the authority of ARIN to conduct a needs assessment and that that perhaps you dealt whether that was ever valid.
To be clear, we administer the registry according to the policies you make, and those policies apply to all the resources in the registry. If you make a policy that says there's a needs assessment, then it applies. If you make a policy that doesn't say there's a needs assessment, then there isn't one. But it's unequivocable that we have the ability to administer the registry according to the community's policies.
If someone doesn't like that, they don't need to use the registry, but we try to make it useful to everyone. So we have no doubts, at least as an organization, of our ability to apply whatever policy this community develops to all the entries in the registry.
I guess I'll go to the second point that Marc points out because it's somewhat related. So we do allow an organization to update its contacts without entering into any agreement. The Board has said we will continue to provide services to legacy people with the services that they were receiving when ARIN was formed. They can update their organization -- they can update their contacts.
The challenge with allowing the update of an organization without entering into a contractual agreement is that it is quite possible in that process, where someone asserts that, that it isn't actually legally the case.
And so it's one thing to update the contacts when someone says it's the same organization or even if it's been through a rename, if it's a legal change of entity, then at this time, we do not provide the ability for them to carry those rights over. We don't recognize that necessarily there's any obligation to do so.
If they have rights in the registry, that's fine, but all of the policies of the registry apply. The Board has instructed us to allow people to update their contact information, but we have not received further instruction.
I would take that up with a Board member if you want parties to be able to go through 8.2 processing and Mergers & Acquisitions and still not enter into an agreement. That's a pretty substantial lift.
Paul Andersen: And we do dangerously start getting a bit out of scope of the discussion on hand. On this policy. Happy to have that discussion on this policy at an open mic or otherwise.
Marc Lindsey: I'm with you. But the policy says you must have an RSA, right? That's part of the policy.
Paul Andersen: It does say the new entity must sign an RSA covered by all resources.
John Curran: Correct.
Marc Lindsey: I think John's point is that it's part of the policy, and not a staff question. It's in the policy today. I think it's a policy point. I believe that if your goal is to get more legacy holders to update the registry as a reflection of normal corporate activity, that you ought to eliminate the RSA as a requirement for 8.2s or substantially change it in a way that you can just get the minimum protections ARIN needs in that context.
John Curran: That's currently contrary to the position taken by the ARIN organization. And so, that needs to be addressed at the Board level before policy can be changed. Even if the policy is changed, we still would seek an RSA right now.
And then the last point was -- oh, the last point was in regard to the statements regarding a needs assessment having already been conducted on the resources.
We don't -- we look at the NRPM, and we generally talk about the requirements to process the request that's being asked. And so I understand the AC in that there was a little dialogue back and forth about not an additional needs assessment should be applied, but only for the purposes of processing this request. It's a fairly Byzantine structure to get the point across.
It's not clear whether trying to associate the ability to do a needs assessment or not, in policy with the block, like this block has been through one but can't be through another one unless it goes through one of these, then this block can, we actually don't associate the needs assessment property with a block or not. What we associate it with is with the request.
The simple language would be in processing an 8.2 request, no needs assessment will be performed, period. This was discussed with the AC. The AC went with a more -- a phrase that it thought was more exact given the history of the block. It's not the practice in the rest of the NRPM, but it's the language that was chosen.
Paul Andersen: Okay. I think thank you very much for your comments.
I believe you were next, sir, in front.
Brent McIntosh: Brent McIntosh, Cable and Wireless. I just want to say I'm in agreement with the policy. It makes it more streamlined for M&A transfers. From a Caribbean perspective, any such efficiencies are pretty much welcome as we're in a landscape where M&As are pretty much common these days. Thank you.
Paul Andersen: I'd ask, if you wish to speak on this topic, that you approach a mic because we are rapidly running out of microphone slot people. Rear microphone.
Robert Seastrom: Rob Seastrom, Neustar and ARIN AC. I was the one that wrote the original draft of this proposal. My intent was to eliminate two points of friction in having accurate Whois data, and that, I believe, is a compelling community interest to have Whois data as correct as possible.
The first one was the scary language about ARIN taking back space, which served as a disincentive. The other was the language that spoke to a redo on the needs assessment. Particularly end users, as opposed to ISPs, tend not to have the kind of exact data that would satisfy an ARIN audit readily at hand.
So both of those points tended to scare organizations off from updating the data, and I wanted to get rid of those points of friction so that there was no longer a reason for them to not update the data.
To the gentleman speaking on the mic at the right a moment ago about the RSA, John's already explained why that's something that the Board would frown upon, but I think that this moves us substantially in the correct direction even without those changes. Thank you.
Paul Andersen: I know you authored it, but are you still in favor?
Robert Seastrom: Absolutely.
Paul Andersen: Thank you. All right. Please approach. This is the last call for microphones. Please approach the microphones. We will be closing after this comment. Front microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written, and we're going to go into the next phase as a Recommended Draft, which is to see what the sway of the room is.
The policy's not perfect. I'm sure there's some things that could be tweaked here and there, but the policy gets us a major step forward, and I don't want to see us wait another entire cycle of ARIN meetings to make more changes to this policy. I just want to see it move forward as it is. We can always write another policy to do the next thing, but this really helps a big issue that we've had now, I think.
This has been brought up in six or seven meetings in a row relating to 8.2s. Let's just clean it up as best we can and move forward. Thank you.
Paul Andersen: Thank you. The microphones are now closed. Our last comment will go to remote participation.
Alison Wood: Thank you. Christoph Blecker, Walt Disney Company, is in support of the policy as written.
Paul Andersen: Thank you. All right. That ends the comments. So thank you to John for the presentation.
Paul Andersen: I will ask my poll counters to get in position. First just a quick test. Everybody raise one hand right now in the room. I mean everybody. Let's just test. Good, so we know -- there's a few here that aren't putting -- come on, we know that hand works.
John Curran: Can I raise my hand?
Paul Andersen: You can now lower your hand. Very good, Jason, showing proper procedure, waiting to be told.
So this is a Recommended Draft Policy. We're going to ask the question whether or not the community believes the Advisory Council should continue to proceed, move this policy along and proceed with it.
I will ask all those in the room that are in favor to raise that hand you just raised nice and high and keep it up until I ask you to lower it.
Online, please indicate your preference now.
This is our last Recommended Draft Policy this session. So this could be your last chance to raise your hand and make your mark. Again, if you are in the room, you are entitled to indicate one way or another. Just another few seconds. Thank you. You can lower them.
And if you are opposed, please raise your hand nice and high. Okay. All those that -- I believe there were none, unless they're in the corner. One moment, please, while we tabulate the results, including online. And then I believe we're going to potentially be a minute or two early for break. Snacks are always good. Never go hungry at an ARIN meeting. That's always a promise.
Just a reminder, though, too, just before the end of the day, we do have an open microphone. So some of the issues we were kind of saying may have been a little out of scope, but we're happy to discuss, that's an excellent opportunity to bring them up, and we are happy to speak.
But on the matter of 2016-9: Streamline Merger & Acquisition Transfers, a show of hands combined online and in person -- 61 in favor, goose egg against, 129 in the room and online. Thank you very much for this feedback, which will be presented to the AC immediately. Thank you.
John Curran: Oh, I loathe to give you extra minutes for break, but we are three minutes early, and it's now time for the break. Folks, please stream out there. There's refreshments. Please come back in at 10:00 -- sorry, at 11:00 promptly. In your seats at 11:00 a.m. Thank you.
John Curran: If people will come in and be seated, we'll get started.
Welcome back. We have a number of presentations coming up. Including updates from our fellow RIRs, a discussion of transfers, and I have a presentation on Internet and the U.S. Government.
So I want to move right ahead. I think Alan's here. Alan, are you here? Come on up.
We're going to do the AFRINIC update. This is Alan Barrett.
Alan Barrett: Right. Good morning. I'm Alan Barrett, CEO of AFRINIC, and I'm going to tell you a little bit about what AFRINIC has been doing recently.
So far this year, we've signed up 31 new members in the first three months, which is more or less on target, maybe a little bit above the target that we set ourselves for new members.
And at the bottom there, you can see a graph of how our membership has been growing over the past 11 years or so.
At the moment, we have a little less than 1,500 members. Out of our 1,467 resource members, between them, they hold about 6.1 /8s of v4 space. That's 102 million /32s if you want to count them in that way.
We also have legacy space holders who received IPv4 resources from elsewhere before AFRINIC was set up, and between them they hold about 8.5 million IPv4 addresses. That's about half of a /8. We do not have any contracts with our legacy space holders. We just offer them Whois service and reverse DNS.
So far this year in 2017, we've allocated about 3.2 million v4 addresses and 20 /32s of v6 and 35 AS numbers -- no, 36 AS numbers.
So our v6 allocation is a bit behind some of the other regions. Right now about 40.7 percent of the AFRINIC members have a v6 allocation, and in some cases they might have that space and even be announcing it but not really be using it properly. So v6 education is a big part of what we do.
Yesterday we reached our final /8 milestone. So we approved a request which would drop us below the final /8. So that triggers our IPv4 Soft Landing policy, and the Soft Landing policy is divided into two phases.
Phase 1 has just been triggered yesterday, and there's a list at the bottom of what changes. The maximum space that you can receive in a single application is a /13. Previously, there was no real limit. If you could justify a huge amount of space and we had it available, then you could receive it. But under Soft Landing Phase 1, you can't get more than a /13.
When you justify your need for IPv4 space, it can be based on an eight months' projection of your future needs, whereas previously it was 12 months.
We're reserving a /12 out of the final /8 for unforeseen future needs, and that's really for the Board to decide what to do with it if they ever make a decision. And, of course, it's possible that policy might change. Even though we've already reached this milestone, nothing stops our community from changing the policies.
And then another change in the rules as we reach exhaustion Phase 1 is that use of AFRINIC space outside the AFRINIC region must be to support connectivity back to the region. So the way we're interpreting this is it applies only to space that you received during the exhaustion phase.
So if you're already an AFRINIC member and you already have some space and you're already using it outside the region under previous rules, that's still okay. But if you want to receive more space during the exhaustion phase, then you'll -- any use of that additional space will have to satisfy this new rule that out-of-region use is only to support connectivity back to the region.
So more or less, what that implies is, if you want to put some equipment on at an exchange point outside of Africa, then that's okay. But if you want to serve customers outside of Africa, then that's not okay under this policy.
V6 deployment is very important, and as I said, AFRINIC is behind. We offer free training on IPv6 deployment. We are busy setting up some online training. We do lots of in-person training. I've got another slide with some statistics there. But we're planning to offer more than 20 v6 training courses throughout Africa this year.
Last year we've launched an IPv6 certification program called Certi::6. The training -- the certification platform is accredited by the IPv6 Forum, and the basic idea is you do an online test, and if you do well enough in the test, you get a certificate, which is from AFRINIC, which is accredited by the IPv6 Forum.
We offer these tests -- even though it's an online test, we plan to offer them in virtual environments. So we'll have somebody overseeing the test to make sure there's no cheating. We've got an IPv6 testbed, which is a whole bunch of routers in a virtual environment, where you can connect and run experiments. It doesn't see much use by the general public, but we are using it as part of our training courses.
We have several policies up for discussion. I'm just going to skip to the next one. I want to discuss page 2 before page 1. Yesterday we reached our Soft Landing Phase 1. There are policies up for discussion, policy proposals to change how the Soft Landing will work, and one of them is called IPv4 Soft Landing BIS. This will change several of the rules.
The maximum allocation size, instead of a /13, as it is now -- looks like a mistake on the slide. It's not a 10. Instead of a /13, as it is now, they're proposing that the maximum size will be a /15. When we get down to only one /10 remaining, that will be the start of Phase 2 of the Soft Landing, and as that point, the maximum allocation size will be a /22.
In terms of this proposal, the allocation period, your future projections for how you're going to grow as part of justification for your need will be eight months. That's the same as it is today under the current Soft Landing policy, but it's different from what it used to be before we hit Soft Landing.
Then this proposal will reserve a /16 for critical infrastructure, and that more or less means exchange points and important DNS operators. You'll have to read the details of the policy to see exactly how that's defined. There's been some controversy about that. For example, one of the points which was not very clear in the past version of the proposal was whether all TLD operators or only ccTLDs would qualify.
Okay. So that's a proposal which has been on the table for almost a year, I think.
And then the other policy proposal to change Soft Landing was put on the mailing list only a few days ago -- was it yesterday or the day before? And this will change the Soft Landing policy in different ways. Similar ideas to what you saw under the other proposal, but different numbers, different details. So it proposes to change the maximum allocation to a /17 in Phase 1 and a /20 in Phase 2.
And then this confusing wording that no limit on the number of requests unless a member has received allocation or assignment equivalent to the maximum prefix. What that means is the maximum is a /17. If you get several /19s in several separate applications, then that's okay as long as the total doesn't exceed the equivalent of a /17.
So, in effect, a member will be able to come back as many times as they like during Phase 1 to get lots of small pieces that add up to a 17, and then they'll be able to come back in Phase 2 to get either a single /20 or a few smaller pieces that add up to a /20. So this proposal is also formally under discussion. It was just posted to the mailing list a few days ago.
Then we have a policy proposal on transfers. Let me first talk about the other one. Yeah, this one. There's a policy proposal on transfers within the AFRINIC region. So both parties, the sender and the receiver both have to be AFRINIC members in the AFRINIC region. This policy has passed community consensus. It's passed last call in the community. It's waiting for Board ratification.
There is a small twist to it, and that's our current RSA, the Registration Services Agreement, the contract that members sign with AFRINIC, prohibits transfers. So we have to change the RSA before we can implement this policy.
Okay. Then there's a proposal. The one I just talked about has passed the community, not yet passed the Board.
Now I move on to a separate proposal, which is still in discussion in the community, about inbound transfers -- that's from another region, a different RIR region -- into AFRINIC. There's no consensus on this proposal. It's still in discussion. And it does not provide for outbound transfers where the sender is in the AFRINIC region and the recipient is outside the region.
We understand that might be a problem for some other RIRs to implement the reciprocal side of that. I'm pretty sure that ARIN will find it outside their policy that they won't allow transfers from ARIN to AFRINIC unless AFRINIC also allows transfers in the other direction.
Anyway, the proposal is under discussion. We'll see what happens. Right.
Then there's a proposal which has been called the audit proposal, which wants AFRINIC staff to conduct routine audits to review how our members are utilizing the space and to recover space when they're not in compliance with the policy. This is under discussion. Discussion has been quite heated at times, and there's no consensus on this.
All right, so, that's it for policies under discussion. I mentioned earlier that AFRINIC does a lot of training and encouragement of v6 deployment. This is some more detail about that.
This year, in 2017, we will be in 22 countries all around Africa offering training in IPv6. Since we started this in 2010, we've been to 40 countries, and we've trained more than 3,000 people in how to set up IPv6 networks. We get very good feedback from the participants in the trainings. So we think we're doing a good job there.
We run a grants and awards program called FIRE, the Fund for Internet Research and Education. We receive some money from donors: IDRC, Google, and the Internet Society provide funds which AFRINIC manages under this grants and awards program.
We support projects throughout Africa that harness the power of the Internet to do good things, to improve lives. And just last week, at RightsCon in Brussels, the winners of the Mozilla Equal Rating Challenge were announced, and I'm very pleased to tell you that two of the projects that AFRINIC's FIRE program supported were finalists in the Mozilla Equal Rating Challenge, and one of them actually finished in second place.
These are both community network projects. One is offering free public Wi-Fi. They're doing more than that, also skills development. They produce content. They have a way of -- people can contribute photojournalism, and then they distribute it over their community Wi-Fi.
And the other one is called LibreRouter, which is about writing open source code to run on commodity hardware to help provision community networks.
We distributed in 2016 just over $250,000 of funding to 13 projects.
We have two meetings a year, just like every other RIR. Our next one is in Nairobi, Kenya, last week of May, going into the first couple of days of June, and that will be the AFRINIC 26 meeting held in conjunction with the Africa Internet Summit.
You're all invited, of course. And even if you can't make it, you can contribute to the AFRINIC policy discussions. You can follow the meeting online. We will have an audio feed. We publish the videos on YouTube. I think we'll do live streaming on YouTube as well.
We run this meeting in conjunction with several other African organizations. There's AFNOG, African Network Operators Group. We work with ISOC. They also run some side events there. We have some agreements with AFRALO, the ICANN Regional At-Large Organization for Africa. AfricaCERT, a few others whose names I've forgotten.
And AFRINIC also has a Fellowship Program. This year we're bringing 11 Fellows to our meeting. For the first time, there'll be more women than men in the Fellows program and from a good distribution of countries around Africa.
Okay. Thank you. Any questions?
David Farmer: David Farmer, University of Minnesota, ARIN AC. You mentioned several community network projects that essentially you were sponsoring. Does AFRINIC have any policy relating to community networks?
Alan Barrett: Very good question. No, we do not have a policy relating to community networks. We also do not have a special fee structure for community networks.
In the past, the Board made an exception for one particular community network that asks to have their fees waived, and the Board said okay. But that was done as an exception.
David Farmer: Okay. Thank you.
Alan Barrett: The Board is currently in the process of reviewing the fees, and it is quite possible that there might be something in the new fee structure dealing with non-profits, community networks, and so on.
David Farmer: Thank you.
John Curran: Any other questions for Alan? Thank you, Alan.
Alan Barrett: Thanks.
John Curran: Wonderful report. Our next report will be from LACNIC, and I believe Oscar is here to give it.
Oscar Robles: Thank you. Good morning. My name is Oscar Robles. I'm Executive Director of LACNIC. I have a few topics to present to you. Those are related with activities that we do.
No. 1 and No. 2 are what we do; No. 2 and No. 4 is how we do it. So the first one is related with the registry activities, and the second one with our interest to support a stable, resilient, and robust Internet.
No. 3 and 4 is how we believe in the bottom-up participative process of development policies. And No. 4, how much effort we put in the process and repeatable process to fulfill our mission.
So regarding resource management, most of the information related to the registry already was presented by Leslie in the joint report. I'm just going to focus on the membership evolution.
As you can see, membership is still growing, almost 20 percent annually, and last year almost 1,000 new members, mainly driven by the micro and the small allocations, which is 60 percent of the allocations of the membership are the small and -- the small/micro, the smallest membership that we have, which is a /22 requirement.
As you know, LACNIC entered in February the third phase, which is the fourth phase. It's the No. 3, but we started in 0. So that's the number fourth, which is kind of complex.
Anyway, the Phase 2 finished in February, and we started in the 15th of February the Phase 3, which prevents allocations to current members. So there's no more space available for our 6,000 members at this moment.
So all the allocations could be /22, and that's only for new entrants. The pool size is /10, and we expect to have this phase for the next years, depending on the consumption rates, from five to ten years, if there's no other special allocation for specific activities.
Regarding the LACNIC Board of Directors, we every year have elections. Last -- latest elections, there were two positions to be renewed. That was Wardner Maia from Brazil and Javier Salazar from Mexico. Both were eligible for re-election, and they were re-elected. Maia was reappointed as LACNIC Chairman of the Board for the second year. He's from Brazil.
As part of our activities to support and to improve the security, stability, and resiliency in the Internet, not only to the region, but everywhere, we are working together in our own coordination group, engineering coordination group, to align the trust anchors. We're still doing some RPKI outreach. It's a co-level of deployment in the LACNIC region.
We do a good number of activities promoting IXPs. Last week it was with the Argentinian Network Operators Group, which is a very well-organized NOG in our region.
We are doing DNS security and stability. We just enabled a global node -- it is not a note, but a node -- @Montevideo from the RIPE root server, and it's IPv6 enabled.
We just issued a call to install and employ I-Root instances in the region. We have an agreement with that node to promote the installation of global nodes in the region.
Regarding the IPv6 deployment, as you can see in the information that was presented, more than 80 percent of our members already receive an IPv6 block, and half of them already are announcing the IPv6 blocks in its ASNs. So more than 2,000 networks are already announcing an IPv6 prefix in our region, which is a very good number.
So the subpart of this is that it is only the -- the technical side is done already, but the financial side is not completely done. It doesn't make business case yet for many of them, as you can see in the Google or APNIC statistics. Only Brazil, Ecuador, and Peru has relevant rates of deployment to the IPv6 to the end user. Trinidad and Tobago recently started to do some interesting things to the end user, and a few other countries with more than 1 percent, but it is a very limited deployment to the end user, the IPv6 in the region.
Anyway, the good part is most of the networks are already doing interesting things and are ready for IPv6.
Regarding the development of capacities in our region, we put a lot of effort in the IPv6, of course, security things, IXPs, RPKI, which are the topics related to LACNIC activities.
Last year we trained more than 4,000 persons, or people. We have an initiative for online courses by MOOCs and just the first edition of the IPv6 course this year received more than 400 students. That's a very interesting tool for us because that allow us to massively train in technologies related to our activities -- IPv6, PGP mainly are the topics that we do in this Campus LACNIC.
We have some initiatives. We have one program to support initiatives in the region that try to develop the Internet and make a better society in the region, and we call this initiative, this program we call FRIDA, which is a contribution from some of -- from Internet Society, IDRC, and LACNIC to support these initiatives. We have three different kinds of awards, which are the awards, the grants, and the scale-ups.
Then how we do -- but I just mentioned, through a participative model of development -- policy development process, you can see we've been successful in promoting the community involvement in our activities. This is the part related to the policy proposals, and the green bar is from 2014, the orange one is from 2015, and the blue one is 2016.
The one at the bottom, that's the total number of policy proposals that we received in 2014. There were three, then five in 2015, and eight in 2016. So that shows you that we've been putting many efforts to try to foster discussions in topics that are relevant for the community.
In San Jose, LACNIC 26 -- San Jose, Costa Rica, not San Jose, California. Be careful when you book your trip for the next ARIN meeting.
The proposals -- let me see. Yeah, the first three proposals were discussed in San Jose, Costa Rica. One got consensus. The other two were sent back to the mailing list for discussion. And we have a few proposals now for the LACNIC 27 in Brazil. Among other proposals, there's one for inbound inter-RIR transfers.
We just received another one that is proposing to allocate on the /23 and /24 for ISPs. I mean, micro, micro allocations, which kind of makes sense because of the phase of the stage where we are. And that's going to be discussed in Foz de Iguaçu next month.
Regarding the inter-RIR transfers, we discussed that policy last year, and it was implemented -- I mean, it was discussed in 2015 and implemented in 2016. So this is the number of transfers that we have had in the region. As you can see, it's a very small amount of transfers, and only the /16 in all these seven transfers.
Elections in our community. We are running an election for the co-chair of the Policy Development Process, the Policy Forum co-chair. We had seven candidates. This is the first time we had that high, that number. It's the first time we have a woman running for a co-chair in this position. The results are going to be announced next week.
Also, we have a number of elections on the bodies that represent LACNIC in the NRO or the ASO, and we have these Review Committee members. The members are Nicolas Antoniello from Uruguay, Edmundo Cazares from Mexico, and Ernesto Majo from Uruguay as the staff representative. But Edmundo Cazares and Nicolas Antoniello were appointed as part of the interim initial Review Committee members.
This may -- we will held elections for the proper election of these community representatives, and this is the link where you can see more information.
We rely a lot on community building to conduct our activities. So we try to collaborate with other organizations in the region to make some smaller events to some places where there is very limited chances to have a bigger event.
For example, last year we had the LACNIC on the Move in Belize, Suriname, Honduras, and Bolivia. This year we had one in Guatemala and jointly with Internet Society local chapter; the Superintendencia de
Telecomunicaciones, which is kind of the ministry of telecommunications; the regional Internet Society for Latin America; and the ICANN Roadshow. We had 150 participants mainly from the local community.
Another way to do what we do is to with quality and continuous improvement. We got the recertification with the ISO 9001:2015, and we certified three core processes -- the registry and management of number resource process, the Policy Development Process itself, and the events organization process.
We received for the fifth consecutive year, the award for a great place to work in Uruguay. It's one way to see that we are doing good things in the -- in our organization internally. We have nationals from ten different countries, and two of them are Russia and Spain, and, of course, the rest of them from LACNIC region.
Women comprise 50 percent of LACNIC full-time employees.
We redesigned last year the main page of LACNIC with a more usable interface and able to be loaded in mobiles. We launched milacnic.lacnic.net, which is a management tool for our members. Mainly number resources, RPKI resource certification, online payments, account, invoices, and all these management things.
And, of course, part of -- most of our efforts are defined in a strategic plan. The strategic planning cycles in LACNIC varies from three to four years. The latest cycle was 2012-2016. So we just started a new strategic planning cycle.
We work in that definition last year. We redefine the methodology. We work on the process of strategic planning. And that Strategic Plan was ratified by the LACNIC Board in September of 2016. So we are now working in those goals, in this mission, vision, and all those strategic definitions that are relevant to maintain us, align as a group, and to remind us what it is we have to do if some ideas come up in the middle of this cycle.
Finally, our next meeting is going to be in Brazil, Foz de Iguacu, not in the waterfalls, but very near these massive waterfalls. That's going to be LACNIC 27 on the 22nd to 26th of May. You can go to Brazil and then go to AFRINIC meeting in Nairobi, which is close to the region as well.
And the next event is going to be LACNIC 28 in Montevideo, Uruguay, from the 18th to 22nd of September. And we're going to celebrate the 15th anniversary of LACNIC. And that's it. Any questions?
John Curran: Thank you, Oscar. Oh, we have one. One question.
Tom Fantacone: One question. Tom Fantacone, IPtrading.com. I was curious why there have been so few transfers within regions, since the policy has been in effect a while. Do you think it's the procedure's difficult, or people aren't aware of it? Or just not a lot of sources?
Oscar Robles: Yes, the short answer is we don't know. We try in the beginning to explain this process to -- through webinars, through short guides to explain these transfers. There were a few, but we exactly don't know why we have this limited number of transfers. Could be because of their requisites, the criteria, I don't know. But certainly we don't want to lower those barriers.
We're still trying to find out, to have this conversation with the community why they think that there are so limited number of transfers.
Tom Fantacone: Are there a lot of attempts at transfers that don't succeed, or just very few attempts?
Oscar Robles: Very few attempts.
Tom Fantacone: Thank you.
John Curran: Thank you, Oscar.
Specified Transfers at ARIN
John Curran: Okay. Very good. So then we have a discussion on specified transfers at ARIN. I'll invite John Sweeting up to give the report.
John Sweeting: Good morning, everyone. I'm John Sweeting, Senior Director of Registration Services at ARIN. I'm going to talk about specified transfers. So this is the 8.3s and 8.4s that have nothing to do with the Merger & Acquisition 8.2 transfers during this talk.
A lot of this is repeat from what I presented on Sunday at the tutorial. An overview to talk about what is a specified recipient transfer, statistics, who can participate, transfer requirements, the process and fees, and we'll throw in a little bit about pre-approval and the specified transfer listing service and then some tips and tricks. I don't know if they're tricks, but they're tips.
Okay, so. What is a specified recipient transfer? It involves transfer of addresses that are typically unused by the person that is holding them to an organization that has demonstrated the need for them. It includes transfers within the ARIN region and also the inter-RIR transfers to -- currently with APNIC and RIPE. The details are, of course, in the NRPM under 8.3 and 8.4 for the inter-RIRs.
Here's a little chart on the numbers that are completed per month. As you can see, the inter-RIRs, they've gone up a little bit, but they stay somewhere between 10 and 20 a month. The process has gotten a lot better; although, today it's currently all manual and involves a lot of emails back and forth. There's a transfer log that's being developed and will help with that manual process. But I'm not quite sure exactly when that will be put into effect.
8.3s, you see during the holiday season, November, December, they kind of went down a little bit, but then they shot right back up in January and February. We expect to see at least above 120 a month going forward.
So who can participate in these processes, these two different transfer processes? Current ARIN IPv4 holders can participate as the source of addresses, either within the region or with the 8.4s to RIPE or APNIC recipients, and also then the organizations in need of the IPv4 addresses as recipients, they can source from within the region or from APNIC or RIPE region.
So the requirements for a source, the addresses must be registered with ARIN. They can't be involved in any dispute. So we work very quickly. If there's a dispute that comes up, we have to work very quickly to resolve that dispute.
That sometimes can happen. That sometimes can't happen. It takes a long time. But we just can't take the chance at transferring something that there's more than one organization out there claiming the rights to. So we have to go through all the documentation to make sure we get that right. It's very important.
They must not have received IPv4 transfers from ARIN or via a specified recipient transfer in the past 12 months, and they cannot come out of the special reserve pools for critical infrastructure, which is covered under 4.4 of the NRPM, or for the IPv6 deployment, which is 4.10 in the NRPM.
And for a recipient, you have to show the justified need based on your 24-month projected usage.
Okay, documentation required for a source. Verification that the current registration is in good standing, all fees paid, and that they are the authorized organization for the IPv4 block. If there's previous merger acquisition that hasn't been recorded, hasn't been updated in the registry, then an M&A transfer will be required before the organization can act -- can transfer under 8.3 or 8.4.
There's a notarized officer acknowledgement required, and additional items could be needed, and those are usually with making sure that that is the authorized organization with the authority to transfer that block.
For the recipient, the recipient's got to provide documentation for their previous issued IPv4 address space and then data to support their 24-month projected need and a signed officer attestation certifying that the information in the request is accurate.
There's a new transfer fee, went into effect -- I believe it was January 1st. Transfer fees are now lower. They used to be 500 and paid at the end. They're now 300 and paid up front.
The transfer fee is waived for the source when the resources are under a Registration Services Plan, an RSP, which is normally your ISPs, but there are some end users that have decided they wanted to be under an RSP, and they pay those fees to be under that plan. And they're also waived for recipients of inter-RIR transfers.
Ongoing fee -- and then there's ongoing fees associated with that based on the published fee schedule, your annual fees, what you have to pay based on how many resources you hold.
Okay. How long does it take? It's a good question. We get asked this quite a bit. Some can be very quick, and some can drag on and on and on.
What helps is when the registration is current and up to date, the customer does a quick turnaround on the officer acknowledgement, and when the recipient has already requested and been preapproved for the size of the block that's within that transfer.
Transfers that take longer to complete, it's the outdated records. It's when there has to be an 8.2 transfer done first before the 8.3 or the 8.4 can be done. The inability to provide necessary documentation to support their claim to be the authorized organization for that block. And not all transfers get approved.
Other useful transfer information, ARIN cannot provide detailed information to the two parties that are involved in the transfer. If the recipient comes and says, "What's going on? Why hasn't this been completed? I need those resources," all we're able to tell them is we're waiting on an action from your source. We can't go into any particulars. If you really need to know the details, you're going to have to work with your source to find out.
Same thing with -- if there's brokers, we can't share that information. Only if we've been given specific permission to discuss it with them, and then it's only for that side of the transfer that they're representing. We can't give them all the information about the whole transfer, only about the actual party that they're representing.
And, also, if you are on the IPv4 waiting list, you will be removed if you receive IPv4 addresses through the specified transfer, regardless of block size.
Preapproval for recipients. This is an optional service that will help everything go much faster if you come in and get preapproved and provide us the documentation up front that is required during the actual transfer process.
And it eliminates the need to rejustify at the time of the transfer. It's valid for 24 months. However, if your needs have changed and you need a larger block, then you can certainly provide the documentation to rejustify for the larger block.
Specified transfer listing service, it's an optional fee-based service. The preapproval, I believe, is not a fee-based. It's there and free. But the Specified Transfer Listing Service is a fee-based service that facilitates specified recipients and the inter-RIR transfer.
The sources list what they have available. Recipients say what they're looking for. Facilitators can arrange transfers between parties. The people that are on that list can see the details of the list, and there's also a public summary that's available for anybody else, but it won't have all those details on there. It will just show the block sizes, the number of source organizations with their approved block sizes, and the list of facilitators with contact information.
So some tips for faster transfer processing. Just -- it's all common sense, making sure that your registration information is current, up to date. We will go out of our way to help you to make sure that is done because it's only going to make everything easier for everybody in the long run.
On the recipient side, obtain the pre-approval. This way you'll know what your approved block size is when you're out there looking for a source that can provide that for you. Again, it also allows for everybody to have a much more enjoyable and quicker experience when the ticket -- when you get ready to submit that ticket.
Like I said, there weren't any tricks, it was just tips. Even though -- anyway, never mind.
So for customer support on transfers, you can call the Help Desk any time between 7:00 a.m. and 7:00 p.m. Eastern time, or you can send in a ticket through ARIN Online, or you can use firstname.lastname@example.org - that's the least preferred because....
John Curran: Who uses email?
John Sweeting: There's people that still -- hostmaster gets several hundred emails a month they have to do. They get several thousand, but most of those are spam. But there is a couple hundred a month that are actual questions we have to respond to.
So that's it for that. Any questions? All right.
John Curran: Thank you, John.
John Curran: Wow, presentation on transfers that doesn't get followed by questions. Amazing.
Reflections on the Internet and the US Government
John Curran: Okay. I'm going to give a quick presentation. It's one I actually gave at NANOG in February. This was right after the new administration came in, and someone asked me to sort of say where we were. It's not a very amazing presentation, it's just saying -- sort of status update of where we are.
Because ARIN is based in Chantilly, Virginia, we pay a little bit of attention to the U.S. government and subject to their laws. Because the U.S. government is the U.S. government, everyone pays a lot of attention to them. So I just figured I would share this because there can be implications.
So first one is, of course, congratulations to everyone. We are on the other side of the IANA Functions Contract.
John Curran: The longstanding contract between NTIA and ICANN for ICANN to operate the IANA name, number, and protocol registries, that actually has been replaced. It came to an end. NTIA and ICANN agreed to end it because the proposal that the community made to be the contracting parties for these things, the -- what was called the IANA Stewardship Transition Proposal was accepted by NTIA, and then we fulfilled the conditions in that proposal.
It called for establishment of contracts between the respective communities affected by each of these registry types and ICANN.
The name community has an ICANN contract on its behalf with PTI. So ICANN, through its supporting organizations and constituency, represents the affected community. It actually contracts with PTI, which is its affiliate, the Public Technical Identifiers Organization. The numbers community, we contract with ICANN, and ICANN, again, subcontracts that to PTI. The protocol community of IETF has a longstanding MoU with ICANN to perform the protocol parameters functions.
So now what's changed? Nothing. It's the same old IANA. Same great team, same people. Only now they're doing it because we're asking them to do it, not because the U.S. government's asking them to do it on behalf of everyone. So it's a big event, and it's a non-event at the same time.
It almost didn't happen. There was some remarkable things that happened in the last couple weeks of September, and to the extent that you happen to see anyone from, for example, ICANN, the legal team, Elise, Göran, all of them deserve thanks because ICANN really pulled through in fighting for this. We got involved. There were court battles at the last minute as things were tried to overturn.
But in the end, it transitioned exactly as we all planned. So it's a good thing.
There was a chance that this could have been unravelled by the new administration. It would have been very difficult. Someone asked that -- a couple of people have asked that. We are the ones that this -- these registries are operated for, ultimately, and we're having the party that operates them, do it on our behest.
There's no particular reason that any of us have any obligation, short of a new law, to do anything different. So it does appear to be quite durable.
The folks in the U.S. government who were helping this transition NTIA went through quite a bit to make sure it happened. And if you see Larry Strickland, for example, you should give him a word of thanks. The RIRs did actually send him a letter of thanks. The five CEOs signed that and gave it to him.
But it's all in all a good thing, and it does appear to be durable. So we're very pleased by that.
Someone else already noted now there's the routine aspect of running according to this, and we're setting up the review committee, and we're working on reporting and all those other good things.
FCC Open Internet Reclassification Order. So as folks know, we ended up with a -- recently, we ended up with the U.S. government taking a stand on net neutrality. This was the prior administration, and they did this by reclassifying Internet services under -- as a telecommunications service under Title II of the Communications Act.
This is actually a huge change. The good news is we got net neutrality out of it. So providers who do discriminatory functions like blocking and prioritization and so on and so forth have a clear party. You can go to the FCC and complain, and the FCC says that's now their jurisdiction because that's now a telecom service.
But in the process of doing it, you end up with everything that we've ever had for the phone network suddenly being applied to the Internet. Now, the FCC has said it's not going to do any of those things. All the other sections, like filing tariffs for your rates, they have forborne. They have said we're not going to do this.
So we got -- for those people who wanted net neutrality, we got it. For those people who didn't, sorry, we got it. We got it via the FCC. In the process, the FCC did become the regulatory authority for Internet services in the United States.
That had a bunch of implications. One of the other implications it had is that the FCC took it upon itself to issue some privacy regulations. In the past, that would have been done by the Federal Trade Commission. The Federal Trade Commission has handled dozens of suits and hundreds of matters regarding service provider issues. Well, the FCC now handles it because it's the regulator for the Internet.
It also had some strange effects with respect to IP addresses. We actually had to get involved to make sure that we didn't accidentally reclassify at least how the U.S. government thought IP addresses were managed.
So if you actually look at the order, you'll find the FCC Open Internet Order, the reclassification, you'll find, buried in a footnote, a statement that says this order does not affect in any manner how IP addresses are administered. Those are administered by the Internet Number Registry System. Footnote to the five RIRs and the RFC that describes us.
So they did reclassify what the definition of Internet is, what the definition of the PSCN is. They put it all under the FCC, but they put a little caveat saying we're not trying to change how Internet numbers are managed.
This is what's coming up ahead of us. Some recent ones, just other things going on. There is a Digital Millennium Copyright Act, the online Designated Agent registration, which is that, if you happen to be using the Safe Harbor provisions of the Digital Communications Millennium Act, you now need to register with -- all people, interesting -- the Copyright Office that's operated by the Library of Congress.
So it is very important that you register your designated agent if you're a DMCA party and use the Safe Haven provisions.
One of the things that's up for grabs right now is the Communications Decency Act. Right now there's multiple cases underway regarding the exemption for intermediate providers, and this is an interesting thing.
So we know what a publisher is, and we know what an ISP is, but an online service can be one or the other. It could look like both at times. And we don't know how this is going to work out. There are parties that aggregate content or provide a platform so you can put in your own content that may now be held by that content.
So does a room rental site that lets you rent out your spare bedroom, is it responsible for the accuracy of what someone puts in that website? If someone's advertising services -- I'm out there and I'm busy advertising a lawn mowing service, and you have a website that lets us all advertise, are you responsible for the accuracy of my ad or the legality of my ad? This is in flux and could easily have impacts on layers above the Internet layer.
This is also in flux right now, and it's a very interesting case for all of us.
Okay. The outlook, as I said. IANA Functions Transition, it does look durable. It even looks like the people involved are all going to be fine. So that's a very good thing.
The Open Internet Reclassification Order, we're now seeing one of the side effects. The FCC, which did some issues on privacy, that's now -- there's an act underway -- actually, there's now a bill underway in congress to effectively remove that authority from the FCC and put the handling of privacy matters for ISPs back in the Federal Trade Commission. Might be good, might be bad, but certainly something you want to be aware of.
And then there's, obviously, increased instances about network and user attribution. For example, ICANN's GAC has a Public Safety Working Group working on trying to figure out how to do better attribution of networks, which we've had discussions of.
That's my whirlwind tour of what's happening in the U.S. government and the Internet. I will take questions, but I also want to note we're one minute into lunch right now.
Any quick questions? No? I mean, it's an interesting topic. There's a bunch of interesting topics. I just want you to know, ARIN does pay attention to all these things.
We don't take a position in the vast majority of these. If we take a position on a matter like this, it's because I've come to you and said, we're going to take a position. We're going to split the IANA transition. The Board has asked me to do it. We tell you. We open it up.
But, in general, we don't take a position on these because you guys have different views on them sometimes. You've got 5,000 members, 20,000 customers, and some of you might come down one way or the other on these matters.
But we do track them so that, if they affect the registry system, we'll be prepared to respond.
Okay. We're now going to have lunch. Wonderful topic. Let's see. Lunch table topics. Joining the AC. If you want to join the Advisory Council, that's a great table. Increasing participation in ARIN. You can increase your participation in ARIN by sitting at the increasing participation table and talking about how to increase participation in ARIN with infinite recursion.
Who is an RDAP? The ASO review. The review of the ASO, i.e., the number community as functioning in ICANN. There's also a community networks table. I don't know what the sign looks like, but I do know that -- yes, he'll be there.
Okay. We're going to go for lunch. Take your valuables with you because we're -- the room's not locked. We will resume this afternoon here promptly at 1:30. I look forward to seeing everyone. Thank you.
Address by ICANN CEO
John Curran: If people will come in and be seated, we'll get started.
Welcome back. We have a busy afternoon. For the afternoon, we're going to have an address by Göran Marby, ICANN CEO. We will have an IANA Update by Elise. We'll have the IANA Numbering Services Review Committee Update. Jason Schiller will give that. We've got two more RIRs giving updates -- Axel will give the RIPE NCC Update and Geoff Huston will give the APNIC Update.
We then have the privilege of hearing Geoff opine upon addressing the past year. Should be wonderful.
And then we'll have a refreshment break. And we come back from the break with a Draft Policy, 2017-1: Slow Start for Transfers. And we'll finish up with a Software Development Update and Open Microphone.
So I want to get started right now. And I will invite ICANN CEO Göran Marby. Come on up.
Göran Marby: First of all, thank you very much. It's not often that I get an applaud when I go on stage. I hope I get an applaud when I go off as well.
Göran Marby: Thank you. First of all, thank you for having me here. It's a pleasure to be here. I understand, I learned today, I'm the first ICANN CEO ever attending a meeting like this.
Göran Marby: I also heard -- he said there's some other speaker coming up later than me, it was a pleasure listening to them. It was not a pleasure listening to me.
John Curran: Well, Geoff is legendary.
Göran Marby: I know Geoff. We have debated before on things like IP version 6. And I'm really proud to say -- I've said this every time -- I won over him in an argument, and he actually acknowledged that. That's not going to happen again.
First off, I just have to compliment you, everybody else, and especially John, in the work of the transition. It was -- well, I actually started a year ago as the ICANN CEO, and it was a year ago, it was 1st of April last year.
So I came in very late, and it was an amazingly interesting period to join because I didn't get it at all, it was a lot of people doing a lot of stuff all the time and shouting and running around.
But in the end, when I got more and more involved after the summer and I had opportunity to go to U.S. Congress and testify in front of Ted Cruz, we started up having meetings together in the -- kind of friends and families, where we really got down. And then I got how important this community was for the transition.
I want to point something out. What the U.S. actually did was a remarkable thing, because I actually wonder how many countries around the world would have done the same thing. I could probably say that my own country would never have done it, because we would always say, yeah, you know what, we Swedes can do it better anyways. So why should we leave it to anyone else?
You did it. The government did it. The Congress didn't do anything. And the court system actually in the end ruled according to law and not politics. That is something that I feel is very refreshing. We all should be very grateful to Americans for that process. So thank you very much. Thank you.
Göran Marby: I also know -- I'm cautious of time in this one. Because I know that the major event is not me, that's Elise, who's going to talk about IANA after this one. But we had a lunch. So I'm going to change my speech.
Because when I came into this, my first official meeting as an ICANN CEO was RIPE in Copenhagen, and I got into a discussion with someone who explained to me the differences between our different parts of the community -- hi, Axel -- and how important that was.
And I was thinking to myself, why do I have a turf discussion? After that, I actually changed my official presentation of what I do. Every time I go to someone outside our small world, I speak about the three different pillars that actually makes this part of Internet working. And I say that we are free, equal partners in this one. You have the protocol community, you have the numbers community, and you have the names community. And we have to work together.
And there's nothing else -- then I also said during the Congress, this is a voluntary system that is based on trust, that we're actually working together, and that's the only way we can do it.
So I engaged with John, and I engaged with the other heads of the RIRs really on that precedence. I'm here as an equal partner to work together with you. On the outside, we are measured as one. We are a trinity that has to work together.
And I'm very positive, and I'm very happy that I get invited to come to places like this to have, to foster that discussion going forward.
As well are the examples of recent things we do -- I always get these wrong -- is also to thank you for the cooperation with us, the research we do with you about the health index.
What we're trying to do is to really work together with you to find out ways to look into how things work and evolve. And it's been very helpful, and we're very grateful for your cooperation in doing that. So thank you very much.
So now, when a decision was done -- and to some people, the Internet didn't stop working the day after. I know there were people expecting that; that were looking on the data screen to see if it stopped working, and it didn't. So what do I concentrate on now?
We are after the transition, we've done new deal programs, we've done the transition. So it's kind of back to basics. So a lot of things I'm concentrating on now is what I call transparency and accountability, because now we replace the U.S. government's supervision of ICANN, actually, you are in charge. Everybody who comes to an ICANN meeting and engage are now in charge of what we do. And that means that we have to be much better when it comes to delivering on the promise of transparency.
For me, transparency is much more than disclosure. So I am actually spending an endless amount of time and resources to try to figure out how it actually works. Has anyone here been involved in any ICANN policy making process? Do you sometimes think they are complicated?
Göran Marby: Then you know what I'm trying to do. Because I actually think that, as a part of our stakeholder model, transparency and accountability are hard in the major stakeholder model. You have to engage to understand how to actually work with it because there are changes coming around the corner.
We talked over lunch today, and I often use this expression, the next billion users. We have 3.7 billion users, and as I always say all the time, I wonder how they calculate it. But apparently we have 3.7 billion users.
And I claim they were the easy ones because they were often the elite. They were often people with money and with people living in urban areas or in developed countries. The next billion users, if we really believe that Internet is important, it's going to come from other places.
They're primarily going to use mobile phones because that's the access form that these people can afford, and they also can't build fixed networks out in rural areas of the world. That's going to change the interface, how they interact with Internet. They're going to change how -- the demands and the wishes they have for interaction with a body like ours or yours.
And I think what we need, and I need, to be better at understanding those needs going forward is not only about the way we do things culturally, but also things like IDNs, local scripts, and all of those things.
Also, with a new mobile like 5G, how is this going to affect us going forward? Because that's going to be different from now on, and we have to be understanding of that going forward.
We do some other things as well. How many people of you know what we're going to do October 11 this year? Oh, shit. Yeah. Only? Yeah, my team knows about it. Thank you very much.
Göran Marby: I probably have to go back to my communication department.
We are doing a small experiment, thanks to someone from Australia. I won't name his name. We're doing a small experiment where we're actually going to -- in simple terms, we're going to change the password for the DNSSEC system. And that is something that affects everybody who uses DNSSEC system. I suppose that someone else could talk more technology-wise about it.
It's never been done before. It should have been done ages ago, and now we're doing it. We're in the test phase now. We built a testbed for it. So your operators and everybody's involved can actually check it.
But I actually urge you to talk about it because the more people that actually know about what we're going to do, then it's going to be easier. Because there's going to be a problem for certain users if their operator has not updated himself according to this new thing. So remember that.
Also, David Conrad doesn't want to be seen as the man who broke the Internet. That's how potentially big it could or couldn't be.
So one of the things I'm very proud of is the fact we now have an agreement between ourselves when it comes to the IANA functions. That's the right thing to do. I think it was very proper of you to have that agreement. Not only because I'm Swedish, I kind of like order of things, but I'm also now engaged with John to see how we can, from the ICANN perspective -- and I know Elise will talk a little bit about the legal structure of how it actually works going forward. And I'm looking -- because it's not only a piece of paper. It could be a piece of paper if we treat it as a piece of paper, but I think we shouldn't.
It's actually something where we formalized the relationship that we have, and as a sort of delivering person in that one, I take that responsibility very, very seriously, and that's something I would like to work with you going forward as well.
I'm very proud. I signed it, and I got tequila signing it. So I remember that event as very nice. Thank you very much for the tequila. I actually did get tequila for that. Thank you very much. Very good tequila.
With that, I'll leave you to it and Elise.
Thank you very much for being here. I learned a lot about how you can do policies in this room today. Thank you.
John Curran: Do you have time for questions?
Göran Marby: Yeah.
John Curran: Any questions for our esteemed speaker? I knew someone would.
Andrew Dul: Andrew Dul, CrowdStrike, ARIN AC. Not necessarily a question, but I just want to reiterate we're very thankful you came today. I've been coming to these meetings for a long time, and the fact that you came and wanted to talk to us and wanted to see how we do our process is -- I think that's great. So thank you.
Göran Marby: Thank you. Could I make -- I heard this now, since I came here yesterday, and I'm blushing because I'm not worth it, but the fact of the matter just told me something that I need to be better, and we probably have to figure out a way to do it.
Because we are -- in the great scheme of things, we are a small bubble, and we're together in the same bubble. I was actually surprised that my predecessor hasn't been here, no criticism to him at all, because you shouldn't be surprised at having me here.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I'll kind of echo what Andrew said in that this is the first time I think we've had any real attention from ICANN. Prior to the transition process, it was sort of a we'll leave them alone as long as they leave us alone and keep the numbers flowing like they're supposed to, and, you know, we've got this ASO AC that sort of goes off and deals with the ICANN stuff so we don't have to.
So it is good to see this getting to be more of an interactive process and to see you coming to our meeting. I'm also a member of the Registrar Stakeholder Group. So I had my first experience on the name side of things, which was pretty surreal, a couple of weeks ago.
Göran Marby: I -- one of the things, I come from the outside world and came in a year ago. You've all been to company presentations where people come up and they, first ten minutes -- you want to listen to what they actually do, and they spend the first ten minutes about their internal organization, which you don't care about.
And I have a feeling that outside this small bubble that we are together, with the protocol community as well, people view us as one. We all know that we have different responsibilities and we do things differently, but the trust of Internet, as it is, is on all three of us.
And If that trust is broken between us or of the outside world, we're not going to be measured individually, we're going to be measured as a collective.
I don't think the Internet is going to stay the same for the next 15, 20, thousand years, as some people think. I think it's going to change. The technology is going to change, the structure is going to change, and how we do things are going to change.
If we can't find ways of working together and evolving, we're not going to be measured individually. We're going to be measured collectively. That's why we have to have this interaction going forward.
By the way, I love to speak on CDNs. I heard you're from Akamai. One of my favorite topics. Yeah, I'm a little bit of a nerd. I know that. Sorry.
John Curran: Any other questions? Thank you for joining us.
Göran Marby: You're very nice. Thank you.
John Curran: It's not as if we haven't had anyone from ICANN show up to our meeting. In fact, we have had someone showing up as a regular. And she's going to join us again. Elise, come on up, and give the IANA functions update.
Elise Gerich: Thanks, John. I'm Elise Gerich from ICANN. I'm glad that you do know that I show up and that team members of mine show up, but we're also glad that Göran has joined the ARIN meeting for the first time. But he also mentioned that people get up and all they do is talk about their organization. Oops, I'm going to talk about the organization.
So, sorry, warning, warning, organization talk coming up. So I have a couple things. One is, what is PTI? Who do you contact? We're in the post-transition IANA stewardship time, so has anything changed? A lot of people ask me that every day this week -- breakfast, lunch, in between, over the bar, whatever.
Also just a quick highlight on the IPv4 recovered pool and the allocations from that, and then finally the performance, some of the performance things we've been doing.
So what is PTI? Well, during the transition discussions, the two years that that went on, it was called post-transition IANA. Well, we tried to figure out how we could get a different name for that, so we picked Public Technical Identifiers, PTI. And basically PTI is an affiliate of ICANN, and that is what the ICG, the Internet -- or the IANA Stewardship Transition Coordination Group called it. And they requested that there would be a new entity created to do the operations part while ICANN did the policy part for the names functions. So PTI was created.
And this little diagram shows that there's ICANN -- the mother ship -- and within ICANN there's the IANA department, and that IANA department does the IANA functions in the affiliate PTI.
So this one's a little more complicated. So it shows all of our relationships, the relationships with the RIR community, the relationships with the IETF and the IEB, as well as the relationships with the naming community. But I'll just focus on the RIRs. And you can see yourself highlighted there.
So basically ICANN and the RIRs entered into a Service Level Agreement, and Göran mentioned that briefly when he was speaking about how now we have a formal agreement between us, and that's for the performance of the service that the IANA department does for you all.
So then ICANN entered into a sub agreement with PTI, because now PTI's a legal entity, an affiliate, and they're performing the IANA functions. So ICANN has the relationship with the RIRs and then ICANN has a contract with PTI.
And then the final part, the final bubble on this slide, basically it says that the oversight happens between ICANN and the RIR community. So PTI has a responsibility to ICANN, but it's ICANN that has a responsibility to the RIR community.
I hope that's as clear as mud, because everyone asks me about this all the time. So hopefully it's a little bit clearer.
So there's PTI. There's the IANA department. There's ICANN. Who do you contact if you're doing something with the numbers community? Well, if you want to find out about contracts or the governance, who the directors are, all that kind of official documentation, stuff like that, you go to PTI.ICANN.org.
If you want to find about the operations and all the things that we've done -- all the registries, the IPv4 registries, IPv6 registries, the autonomous system number registries -- you go to iana.org, as you always have in the past.
If you have operational questions, you can send them to IANA at iana.org. If you're reaching me or someone else on the IANA department staff, you would just send it to Elise.Gerich@icann.org or Elise.Gerich@iana.org or fill in the appropriate name.
A lot of folks have asked, why didn't you get PTI.ORG or PTI.NET or PTI.COM or PTI.EARTH? So we actually looked into that, and they were all taken. And we came up with a long list, about 30 different names, we thought we could call PTI, instead of PTI. And most people vetoed them. It's, like, if you've tried to name a baby, you know how it's hard to get to a single name that everybody likes.
So we stuck with PTI, and we went with this nomenclature, PTI.ICANN.ORG for all the administrative contractual relationships, and we kept IANA.ORG, because basically it's hard coded in so many things. And this way we didn't disrupt the community too much. There was a lot of continuity and you can still reach us at all the same old places.
So one thing I did want to point out, because it's come up at a couple of meetings, that sometimes people haven't been able to find out how -- people being the official requesters from the RIRs -- how they request things from the IANA.
So we do have documentation on our website. And if you have feedback for that documentation or you think it's unclear or something of that nature, please feel free to send email to IANA@IANA.ORG, and we'll take your comments into consideration as we continually look at updating and revising our documentation.
So what about the IPv4 recovered pool? And as I heard today, AFRINIC's in their last /8, so looks like the recovered pool may be all there is some day.
As you know, there's a global policy on how we allocate from the IPv4 recovered pool. There are two allocations a year -- one on March 1st and one on September 1st. And we just did the March 1st allocation in March.
Each RIR, as per the global policy, received a /19. There is a tool that automatically does this. I say this, I think, at every meeting. So if you want to run the tool against what's left in the allocation pool, you can, and you can see what your region will get for the next allocation.
This is what ARIN received on March 1st. As you can see, a /19 is not a whole lot of IPv4 addresses, a drop in the bucket in the grand scheme of things. But that's the way the global policy is written.
And here's the timeline for the IPv4 allocations from the recovered pool. If we receive no more IPv4 addresses, and it doesn't seem likely that we will, given what I hear about the transfers and the market for IPv4, March 2019 will be the last allocation from the IPv4 recovered pool, and that will be the last of the IPv4 addresses that the IANA department has to allocate to the RIRs.
So, finally, the performance. Every year we do two audits. We do what's called a SOC3. It's a Systems Organization Control audit for our processes for our root zone processes, that's the SOC3. We completed that one. And we had a successful audit. And we got a certification from the auditors, PricewaterhouseCoopers; please no jokes about the Academy Awards.
But anyway, we successfully completed the SOC3. The second audit is a SOC2 audit, and this is a much more in-depth audit. You get more than a certification. We, the IANA department, get a big report that tells us about our processes, if we've had any exceptions. We had no exceptions this year.
And this is one of the reports that we'll be sharing with the RIR CEOs next year because this is a requirement from the Service Level Agreement that we signed with you all that says that we will do an audit of our systems and our processes. So we will have included the RIR processes for allocation numbers in next year's audit.
And then finally one of the things that our SLA says is that we will start delivering a monthly performance report on the 15th of April. That's coming up very soon.
This is a sample that's been shared with the RIR CEOs to get their feedback of what a sample performance report would look like. As you see, the date on this sample is July 2016. So this isn't the one you'll get on April 15th -- you'll get one that covers the month of March.
But this is the kind of report we've proposed, which says that we've met the SLA for acknowledgment on time, that we got the request, that we responded on time, that we implemented on time, and that we implemented it as requested. And it shows here we had an autonomous system number request in July.
We have not had any requests in October, November, December, nor January. So the report in April will only be reporting on what we did in March, and March was the allocation of the IPv4 recovered pool. That's just a heads-up. That's what the report will have in it.
So we are talking still with the CEOs of the RIRs to see if there's more feedback or other things or changes in this template. And they promised that they will give us more feedback and we can make incremental changes if necessary.
So if you all think you need changes, you know who to talk to. Okay. All righty.
So that's all I have to say. And if you all have any questions, I'm certainly happy to take them.
John Curran: Any questions for Elise?
Kevin Blumberg: Hi, Elise. Kevin Blumberg, The Wire. If you could you go back to the slide about the return over the next couple of years, I remember last year it was mentioned that if there was a small amount that was returned back to the pool, it would then make all the numbers work perfectly and then the next time everything would go out and just be done.
Elise Gerich: That's correct. We did do that calculation. I've dropped it off the slide because it seemed like there was no interest. But I can find that number and tell you.
Kevin Blumberg: Out of curiosity, do you remember? It was a very small block, it was like, a 22 was needed, something like that. Correct?
Elise Gerich: Yeah, it was very small, like a /22. If anyone who has one that they want to give away.
Kevin Blumberg: Yeah, if anybody in this room has a very small block, and I'm sure that PTI could tell us what that was, that would just all go away and the reserved pool, or the pool that is there, would be done and we'd never -- we wouldn't have to look at the slide again until something magically came back into the pool.
Elise Gerich: You don't like this slide?
Kevin Blumberg: I don't like the fact it's going to take three years to deplete out a very little amount of --
Elise Gerich: Yes, it gets incrementally smaller and smaller. I think it was a /22, but I will confirm -- it was on last year's slide. So I will check that and let you know.
If we had that amount returned to our recovered pool, then in September we would deplete the pool completely.
John Curran: In that circumstance, there's an assumption you'd never have to do any more of this, presuming no other space comes back by any means. If something else somehow were to come back, you'd have to restart the pump only with one address in it, which would be a little weird. But it's so noted.
Elise Gerich: Anyone else? Yes, thank you.
Javier Rúa-Jovet: Javier Rúa, ICANN at-large, NARALO. Could you go back to your slide on the organizational structure of the PTI? Just a question on --
Elise Gerich: The big one or the little one?
Javier Rúa-Jovet: The flowchart of decision, that one. Just to -- in terms of the acronyms, what's the acronym on the bottom right, RZERC?
Elise Gerich: RZERC, root zone evolution something committee.
Javier Rúa-Jovet: Okay. I just want to know what everything is there.
Elise Gerich: So, the RZERC was created to be an advisory group to ICANN if there are architectural, major architectural changes to be made to the infrastructure, the Internet infrastructure.
Javier Rúa-Jovet: Since we're here, the other ones. The one on top, CSC?
Elise Gerich: CSC is the Customer Standing Committee, and that's also in the ICANN bylaws. And that was the body that was created to oversee the performance of PTI for the naming function.
And so monthly we have phone calls with the CSC, the Customer Standing Committee, and we give them a performance report, much like I'll be sending monthly performance reports to the RIR CEOs.
Javier Rúa-Jovet: And EC?
Elise Gerich: That's the Empowered Community, and you'll have to ask someone else more about that. I think that's part of Workstream 2 right now.
Javier Rúa-Jovet: I think John knows what that is.
Elise Gerich: Oh, John, go for it.
John Curran: When the names community indicated that ICANN was going to be the party that represented it and contracted with someone for IANA number services, IANA name services, that someone being the affiliate PTI, they wanted to make sure that ICANN was accountable to the community and they weren't 100 percent confident that the current Board structure always fulfilled that.
So they created a set of powers above the Board called the Empowered Community. The Empowered Community is the -- by California law -- are the parties that appoint ICANN's directors and have other specified powers. The Empowered Community has a very specific list of powers.
The ASO is one of the five Empowered Community members. So if ICANN does a fundamental bylaw change, each of these five organizations -- the ASO, the GNSO, the ALAC, the GAC; I left someone else out.
Elise Gerich: SSAC?
John Curran: No. I'm sorry, the ccNSO -- all have to participate in ratifying that change. So bylaws changes or rejection of a budget, rejection of a contract change with IANA, all of these are things that are powers of the Empowered Community.
These are all powers that generally should be pretty routine and not used. There is a fundamental bylaws change coming up right now that the Board has approved and somewhere between now and Johannesburg, the Empowered Community will set up the process to ratify that.
And in the case of the numbers community, because the NRO is the party that holds that responsibility, all five RIR CEO executives have to say yes to anything the empowered -- anything the ASO does with the Empowered Community.
We are in the process of setting up procedures, because some of the Empowered Community functions involve things like ICANN directors. And that's something that we formally delegated to the ASO AC. They're the ones who select those directors.
So we have to set corresponding procedures up, and we're in the middle of working out the 14 detailed procedures for the ASO to exercise its Empowered Community rights.
That's probably a lot more than you wanted to know. But yeah, we're one of the five.
Elise Gerich: And Göran is nodding his head in the back, so I think you must have gotten it right, John.
Does anyone else have any other questions? Well, thank you very much, and I appreciate your time.
IANA Numbering Services Review Committee Update
John Curran: Okay. What have we got next? Okay. So next up, we have the IANA Number Services Review Committee update. And that will be presented by Jason Schiller.
Jason Schiller: Good afternoon. The short of this presentation is there's really nothing to see here, so if you need to catch up on email, go ahead. But please do tune in and pay attention at the end where we have a discussion, because that's very important.
So who, what is the review committee? I'll talk about where we are in the bootstrapping process, what the role of the AC is, and then open it up for the important part, which is the discussion.
It was chartered by the NRO EC, and it's based on the CRISP team recommendations. It's 15 members -- two community representatives from each region; and one RIR staff from each region, which is a non-voting member.
And the list should look fairly familiar. It's the same names from the community-appointed ASO AC members, and some RIR staff members that should be familiar to you.
So there's some functions specified in our charter that's very clear. The output of the committee is advice to the NRO EC.
We are to assist in the periodic review of the service level of the IANA numbering services that's provided to the numbers community. And we need to complete a yearly report on the SLA.
It also clearly states that we need to seek feedback and comments on the report from the community. And that's fairly straightforward.
We decided that we're going to leverage the RIR staff to generate a chart of each SLA performance standard metric and the value that's been measured.
We're going to review those results to make sure they're in compliance. And we're going to look at how those results are measured to ensure that they're reasonably accurate.
We then envision taking these data points and wrapping a report around it, putting out some summary text saying they met, they have been meeting, they nearly missed meeting.
There's some interesting slippage that's starting to occur. And then we're also going to include community feedback as well. It's our expectation that we would put this out on a Mailing List for 30 days, collect any comments, summarize those as well, and also include the raw comments.
But there was some discussion of a broader role. If you look at the NTIA transition assessment and you look at the CRISP text, there's some text in there that says some vague things about how the review committee will ensure community involvement and how it ensures that the IANA meets the needs and expectations of its customers -- namely, the numbers community -- and supporting and enhancing the multi-stakeholder model.
So there was a bunch of us that thought, you know, is it really sufficient to just write a report and throw it over the wall and give them 30 days to comment? And some of us felt, no, that there needs to be a broader community engagement.
And so we decided that we are going to have an open communications channel with our respective five communities. We will have some mechanism for collecting input. It might be an email list. It might be some sort of a web forum.
We're still working on that. And we're still working on our procedures to sort out exactly how that's going to work. But we know that we're going to seek feedback from the community. And if there's something urgent, we will pass that on directly to the NRO EC in a timely fashion.
Just for transparency I wanted to include some links -- the link to our review committee page. It's got links to the minutes of our previous two meetings. There's a link to our Mailing List, which is open, as well as the final charter that the EC provided for us.
I've also included a whole bunch more links, which is basically every reference I could find to the review committee.
And this is the important part: So we truly are seeking your feedback on the service that IANA is providing you. So long as IANA continues to provide a good service, I expect this to be a dull and boring presentation. But in the event that there are concerns, we want you to voice them and we want to hear them.
So I hope that we will regularly open up the microphones and ask you: How is IANA doing? Do you have any concerns? Is there any advice that you think we need to pass to the EC about the services the IANA is providing or the SLA?
In the previous topic, where you said if there's issues, or things that you'd like to see reported on, this is the time to bring them forward.
You can also come to the mics and say you're completely happy with the IANA service and they've been doing a great job up until now and you expect that to be the future as well.
Elise Gerich: Wait, Jason, I'm not going to say that, but I do have to respond to a previous question.
John Curran: You have a complaint about the IANA?
Elise Gerich: Elise Gerich. But not to comment on the IANA service. But someone did ask me the question just a minute ago. It would be seven /24s, or a total of 1,792 addresses that would top off the recovered pool. And that would allow us to drain it on September 2017. That's the answer to the question. But thanks, Jason.
John Curran: Thank you, Jason.
RIPE NCC Update
John Curran: Wonderful. We're going to move right along to the reports, and first one up is Axel Pawlik giving the RIPE NCC Update.
Axel Pawlik: And another talk about the organization and what it's doing. Good afternoon, hello. I'm Axel Pawlik. I'm the Managing Director of the RIPE NCC, as you've probably figured out by now.
Basically a bit of a set of highlights of what we're doing this year, what we're thinking of and why we're doing those things. I'll just go through them one by one.
So it shouldn't be a big surprise to anybody that our main focus, as it's the core part of the business life, of the RIPE NCC is to maintain a strong, secure, accurate registry.
That's what we are most visibly doing. Also, generally, I think it's a good idea to enhance RIR stability through good governance and accountability. I'll talk about that a little bit later on.
Pursuing efficiency through streamlined internal process as an automation, making, doing more things and make it more efficient and cheaper; and to engage with our members, obviously. We need to know what we're supposed to do, so we need to talk to our members and the wider RIPE community as well as those other guys similar to you who are making the policies.
Also to governments, because they govern us in some different way, and also to regulate us for similar reasons.
Oh, my God, we started this year with 15,003, 15,005 members. And, yeah, more than 200 every month come.
If you look at the graph, it's a left curve. It's a bit concerning. But we'll see how long that goes on like that. It's good. More people. More people paying money, makes it cheaper for everyone.
Yes, we have moved. Those of you who have been to the old offices on Singel Canal in Amsterdam remember this very cute building that looks like nothing from the outside and then you get lost in internal hallways in there that led to the fact that we barely saw each other anymore. And occasionally we would find a parched skeleton somewhere in a corner, a guest who couldn't find out anymore.
That starts to smell also. So we had to move. Now we are in a building that is adjacent to the Central Station in Amsterdam. So very, very central.
Good communications links, good transport links as well. It's old on the outside, and on the inside you'll see it's fairly new. Also nice old beams, those steel beams, it's all quite fancy.
The idea is we can see each other and communicate with each other; that we find the skeletons quickly and throw them out into the canals.
We have two and a half floors. You'll see the top-most floors, there's a hole in the top floor so it lets light in and, you know, it's good for communication.
We have a barista. People said, oh, we'll have a barista, and the receptionist and then the people will be standing there in the queue and talk to each other and I thought, yeah, yeah, they all want a coffee. No, no, it works. It works amazingly well. Also, he does tea.
So things that we should be doing. Like I said, we hear that from our members and from the wider community, to ensure that we know what it is really instead of guessing, we do regular surveys. We do them every three years by now.
So roughly in -- so in sync with APNIC as well, do similar things. This time last year we had 4,300 and a couple of people responding to that from over 100 countries.
Our service region is, I think, 76. So that's not too bad. The good thing is that we were not shocked to see the results. Generally people say, yeah, you're doing sort of roughly what we want you to do. And you do it rather well. So that's nice, of course.
But other things that we see, so hidden in there a little bit, that we are doing many more things that people never heard about and don't understand. So that's something that we need to focus on beyond the allocation of numbers that people should know and maybe use.
The results of the survey were done by -- the surveys were looked at by a neutral third party, again, the Oxford Internet Institute. We used their report to identify ourselves, the top 40 major findings, and said what we wanted to do about that. And we have a nice form there on the website. It's publicly available and it changes over time, even when we get to do things, which is good.
Right. Another thing that we have seen over the last couple of years, as we progress, for instance, with IPv6 allocations and arguments with the German government and other governments as well, about allocations, is that it would be really, really good if we would talk to them before they have all the IPv6 plans finished.
So this is IPv6 program for governments, a one day sort of -- events, training calls in a way -- to tell them how this is done from our side, how to interact with us, what the policies are, what maybe other governments are doing, who the other governments are that they could also talk to when they come to RIPE meetings around those as well.
That's been quite successful and popular. Talking about external relationships to people without -- not really outside of our community, but sort of on the fringes a little bit, we are talking about all sorts of people. With all sorts of people we're coordinating, we're doing things together. And occasionally we are being asked: Why are you talking to the ITU still, or why are you talking to Europol, and what are you doing there?
So we have said that we would also in the vein of sort of increasing our transparency and accountability, to document that a little bit more clearly than what we've done before, so basically in the form of MoUs where that's appropriate. And is basically to document and as well just to show others that we are open to communication, to cooperation, coordination with other organizations, to benefit our members in our community.
So talking -- I mentioned Europol, we have a long-standing relationship with them, and earlier this year we went actually there and signed this relatively benign, high-level MoU saying, yep, we want to work together not -- for the benefit of our various communities.
Also, we do all sorts of training courses for law enforcement, and now Ukraine below us is on the slide. We've done others before. Also those things are popular, especially in that they show law enforcement folks how to use the publicly available tools, how to get their information needs satisfied without having to go to RIPE NCC and asking for things. That works relatively well.
We also have, and that's not a positive thing, an incoming policy proposal -- we'll see when it comes and when it's there -- again, similar to what you've seen the other day here, yesterday, focusing on accuracy of the RIPE database and how to increase that and how to sort of make sure that we're doing all the right things. So looking forward to that.
Regional presence: We obviously have an office in Amsterdam. We have all the big RIPE meetings that happen twice a year, but also we do other things.
We go into the regions. We have regional meetings, community events, member lunches, making sure that wherever possible we talk to our members in the regions that are not as well visited as sort of, let's say, Western Europe.
The Network Operators Group in various countries, smaller countries, tucked-away countries, we go to and generally well received. People like us coming there.
Of course, we have the larger operators group: ENOG, MENOG, in Southeastern Europe, communities there. That is something that we continue to support. Those things have grown quite successfully and have a life of their own and it's really nice to see.
As we go around, we also want to, if possible, find the government, wherever and whoever they are, and talk to them, again, about what we are doing, what they see us doing and how the world really runs and how what we are doing and now what our members in their region is doing is good for their economies and the like. So talk about all that type of thing.
So to be able to do that, our Board has asked us last year to focus on this work, some more, get some more people in to enhance our teams within the regions -- most of the people are in Amsterdam. We have two people sitting in Moscow. We have a small office in Dubai. And now we will add to the region there as well.
Was that me? Okay. Fellowship Program. Yes. It's great to have well-running, growing RIPE community. But, again, we see, similar to here, the same faces rather frequently. Then we go to other, sort of other local areas and we see a couple of the locals coming, or quite a lot of them. But still there are people who would find it difficult to attend the RIPE meeting at all for various, mostly maybe financial, reasons.
So we have formalized our Fellowship Program where we get people who have work or study in sort of related areas, living in the service region of the RIPE NCC who have a need for financial assistance, and agree to not only come and sit there and look at things, but also go back and tell their colleagues and their local community about what they've done. So we've done that. It's out there and it's starting to work from now on.
I won't talk much about policy. We've heard the presentations about that before. Basically there's a lot of housekeeping still going on, which is lovely, and some sort of adjusting so that the things work, again, smoother and more easily are understood.
Lots of discussions around the last little scraps of IPv4, but, yeah, that's what we all get.
Transfers: Lots of transfers, thank you, incoming from ARIN. That's lovely. Thank you very much. We also send some back, but not as many.
So, well, it's statistics. Lots and lots of transfers within our own service region. And 17 is already on the rise there quite nicely.
Statistics: Have a look on the online slides.
Resource certification, RPKI, you do that as well in this region. From over there, where I work, we have 4,400 and a couple LIRs that have a certificate requested. We have all sorts of ASNs before the 6 prefixes being covered by us, that's lovely.
We try to explain quite well what this is and why it might be important that it's being used. It's good to see that all address space, including PI and legacy address space, can be covered. Again, the curve up and to the right and slightly curving to the left, I hope.
So 28 percent of the LIRs have a certificate, are using RPKI in one way or the other. And we do see that quite a number of the larger ISPs and also IXPs are interested in this and asked us to make it better understood, make it smoother, make it nicer.
So we have been asked to work in our IP validater to make it more stable and better to use and with a better design. So we are doing this this year as well.
That's basically the update from the RIPE NCC for today. As it's April, I think it's April, yes. Next month is May, and that's typically the RIPE meeting month. So if you haven't booked your tickets to Budapest, why not? You should come. It should be great fun.
If it's too late for you and if you have known that, then there's another RIPE meeting happening later in the year adjacent to the ICANN meeting in Abu Dhabi, the RIPE meeting will be just around the corner in Dubai. So you're welcome to go there as well.
And with that, if you have any questions, I'm here.
David Farmer: David Farmer, University of Minnesota, ARIN AC. Could you back up a few slides to the transfers?
Axel Pawlik: Yes.
David Farmer: Keep going. That one. There's a number of v6 transfers. Are those M&A-ish type transfers? Or are they just freehold transfers of chunks?
Axel Pawlik: Andrew?
Andrew de la Haije: Hi, David. Andrew de la Haije, RIPE NCC. Yeah, they're related to transfers of M&As, I mean, 64, which they transfer, and then alongside they take the IPv6 transfers with them.
David Farmer: Okay. So I don't know your guys' policy terms. But for v6, you don't have, sort of, what we call a designated transfer, and that's not representing that. Cool. Just checking. Good.
Axel Pawlik: Thank you. Anybody else? No? All right. See you in Budapest.
John Curran: Very nice. Office barista. Yes, burned into my brain.
Paul Andersen: Dream on.
John Curran: Next up is the APNIC update. Geoff Huston. Executive office barista.
Geoff Huston: I'm Geoff Huston. I'm the wanna-be executive office barista for APNIC. This is the APNIC update. I don't normally give these. And I've been told if I really muck it up, I'll never have to do it again.
John Curran: They thought that was a threat.
Geoff Huston: They thought that was a threat. They gave me 50 slides. Let's start.
I really pruned the pack. If you're desperate to see what we're doing, go and look somewhere and you'll find the entire pack. I've got this down to about eight.
Annual v6 delegations in the region. This is the number, not the quantity, of addresses. And what it's really saying is there's been a strong uptake, particularly in what we call East Asia.
I'm not very good at that. I think that's bits of Malaysia, Indonesia, Australia. But more to the east than the west has done a lot more delegations in recent years than in the past.
Oceania -- which is really just the Pacific, Australia and New Zealand, relatively constant -- and South Asia. Indian sub-continent. Massive deployment recently, but in terms of delegations not an awful lot. But some of them are enormously big, and that slide really doesn't show it.
In v4, the last /8 policy has been interesting. In our case, it's certainly heightened dramatically and changed the organization completely.
We now have more new members who have basically enrolled to get one of those allocations from the last /8 than we had members prior to exhaustion.
The way it works in this policy, a little different to AFRINIC, to remind you, is that you can get one and only one allocation from that last /8 of up to but no more than a /22.
And, so, a lot of folk do come along and say /22, I can work with that. A lot more than we had before. And so the number of delegations is large, extremely large, and our membership has grown dramatically, certainly by those large pool of folk taking advantage of that policy.
I'll speak about how long it's going to go in the next presentation, which I'll have more time for if I whiz through this. Oh, look, next slide.
Transfers: I want to talk about transfers again in the next set of slides. As you see the amount of cross traffic between regions not so significant. The actual number of transfers within APNIC more significant. There's an awful lot of movement.
Interestingly, Japan has a lot of it, I've noticed. But, yes, it's more intra -- that's right, rather than inter -- regional traffic in terms of transfers for us.
We're very proud of Whowas. We did it in about a year, thanks to the tech guys. It's a brilliant piece of work. What are we as a registry? What should we be doing?
For a long time we all specialized in giving you a snapshot of you today. But as we do things like transfers and as we try and sort of understand how to get a bigger picture of how we got to today, actually making sure that we're actually able to tell you what happened before now.
What was the picture a couple of years ago? Who had what address? So we've actually done a lot of work in giving you a really fancy GUI with colors. Colors. No applause, okay, I'll tell them. They didn't applaud the colors.
Geoff Huston: Two, two people, that's it. Colors are gone. About who had what and also, of course, like many others, we're working on RDAP. It's amazing how long it takes to kill port 43. My suspicion is, it will never die, but we're certainly trying to make it die.
RDAP gives us a lot better service, gives you better service and gives us more control over it, rather than uncontrolled denial of service attacks.
The COMS group have gone absolutely nuts. We told them they'd get a lot more money in their salaries if they got people posting on the blog. So if you're not crash tackled by one of our COMS people, there's something wrong with them or you, because you will be.
They're scouring the world for articles. They're trying to do at least one a day as far as I can tell. We are competing with the Washington Post -- watch out, Jeff Bezos, we're coming for you.
Huge number of guest posts these days and an eclectic series of stuff. If you're just curious and have got an idle ten minutes, have a look around. You'll probably find something that interests you in there in amongst all those postings.
And if you really feel you need to publish and ARIN won't let you, come to us and we'll certainly put it up on our web site, no questions asked.
We've done a lot of work with training over the years, as you're probably well aware. And we've teamed up with a number of folk to do that. We've tried to sort of put this on a better foundation these days and to actually encourage others to help us.
And so we're now setting up the APNIC Foundation. This is its first year of operation. Incorporated in Hong Kong.
Taking a number of our traditional partners, such as the Canadians, now the Japanese and the ITU, and pooling that money together to actually try and get a critical mass to work with a whole bunch of developmental programs, be it both training, on-the-ground programs, awards for various bits of community work and so on. If you're interested, the APNIC Foundation, well worth having a look at.
And if you are interested in that space, please get in touch with us. We're certainly willing and interested in folk to work with this.
So it's a big initiative for us this year. Anyone been to Taiwan? It's amazing. It's a really cool place, right?
And if you've been to Taipei, never boring, this is Taichung, which is a small regional city halfway between the earthquake center, Kaohsiung, down at the bottom, and Taipei, which never has an earthquake, never, well, maybe a little bit.
It's actually a really nice city, evidently -- quite busy; very, very Asian; and a lot of fun.
And if that's not to your taste, Kathmandu in Nepal, we'll be doing a waiting list. So line up first. And if you like tropical islands, in September next year we're going to do our own, a very French one, off Australia, in Noumea in New Caledonia.
Questions? I told you I'd be quick.
Owen DeLong: Not so fast, Geoff.
Geoff Huston: Damn.
Owen DeLong: Can you go back to the slide of your windfall of new members under the last /8 policy?
Geoff Huston: Way back?
Owen DeLong: Yep.
Geoff Huston: Sort of like that one which sort of explains the delegations?
Owen DeLong: Yeah. Any sense of what percentage of those new members are sheeps in wolves clothing? I.e., existing members spinning off entities to satisfy their need for space they can't get anymore?
Geoff Huston: You know, there's this kind of a implicit social contract, I think all the registries have with their members, that you guys make rules. We run with those rules, but you play by the same rules.
And our trust is that you're playing by the same rules. We're not actually empowered by our members to run the APNIC investigative police force. We don't know.
Owen DeLong: Okay.
Geoff Huston: What we're aware of, and it's relatively common practice these days, is web-hosting companies used to get a large amount of addresses and lease them to their tenants. They are sending their tenants towards APNIC because they simply don't have the inventory to support that. And the tenants themselves, the Web asset holders, are now coming along saying, I need an allocation. As long as they meet the policy criteria, that's just fine by us as well.
So that's a more typical practice. Playing the sharp edge on this stuff, the problem is if you get caught, you tend to lose everything or shamed by your neighbors. It's not a good deal. Implicitly, I think, like all RIRs, there's a certain amount of mutual trust that we all play by the same rules.
Owen DeLong: Okay. Thanks.
John Curran: Question, can you go to Whowas?
Geoff Huston: Whowas -- with the color version. Yeah.
John Curran: That link at the bottom, apnic.net/whowas works for anyone. But it has APNIC data obviously.
I would be highly interested in people in this room going to not all at once, over the next couple of hours, going to apnic.net/whowas and looking at the interface.
We have an interface for our WhoWas service. And this one is slightly different. In fact it couldn't be more different.
I'm interested in knowing whether or not we need an interface of similar usefulness and functionality compared to our present interface, and so to the extent that you can try this out and provide us feedback, noting that if you want it, it's developmental, working with these guys to see how much is in common, because -- who has used our ARIN WhoWas interface? Okay. How would you describe the difference between that and this?
Paul Anderson: Way less color.
John Curran: Way less color.
Geoff Huston: What I want is what neither of you have done, actually. And my favorite wish list is actually a delta log of the changes, because to do long-series analysis of some of our published data, to understand each day what changed, is enormously useful as you will see in my next presentation.
Cathy Aronson: I don't want to delay your next presentation because you know how much I love them. But, one, do you have a barista yet? Because you do have a lot of new members generating revenue. Just curious.
But, did you say, did I miss the part when you said how much of your last /8 is left?
Geoff Huston: Okay, that's coming in the next presentation. And every APNIC meeting has its own barista.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. Specifically, to answer John's question, the last time I used the ARIN WhoWas interface it may be a little out of date because it consisted of sending an email into Registration Services saying, I'd like WhoWas data for the following time period for the following resource identifiers, and waiting for ARIN to email me an answer.
John Curran: When you got the answer, was it in English or was it a bunch of interesting, encoded files?
Owen DeLong: It was mostly in what I would generally refer to as RPSL.
John Curran: Okay, because we've, I guess, fixed it or broken it depending on your perspective.
Okay. Thank you, Geoff. No other questions. And stand right here.
Next up, Geoff Huston, APNIC, presenting his view on addressing, 2016.
Geoff Huston: Which I now have 25 minutes for. Thank you.
Geoff Huston: This is something I normally do once a year, and normally it comes up at APNIC meetings. But John saw it, and Leslie, and said, why not? And hopefully you'll find it interesting. I'm trying to look at what happened last year, just what happened in addressing.
And this is a slide you've always seen -- it's the IPv6 allocations by RIR. Up and to the right, bit of 2017, nothing kind of -- not obvious. V6 is growing, you'd think. But you'd be wrong. Because if you look at the amount of allocated addresses, as a world system, we tend to spin out about a /20 per year.
But each RIR varies dramatically in the amount of addresses it actually hands out in v6 every year. So the vertical scale doesn't matter -- it's actually /32s or the equivalent. But you'll notice that approximately a /20 leaves the factory and has done since about 2011.
But that big yellow thing is RIPE. Some years RIPE is enormous. The light blue stuff is ARIN. Let's just look at ARIN.
Massive allocation in 2008. Another whopper in 2013. Some years are big, some years are small. Now, part of this is v6 itself. What we've done is amplified the differences between large and small.
So it's relatively easy as far as I can tell to get a minimum allocation, which is probably a /32. But it's possible to get a /20, which is 10 bits bigger. 2 to the 10th? A thousand, so it's a thousand times larger. So now big is really, really big, and at the times when you do big allocations, it just pops right the way through.
So oddly enough, it's not even in that respect to everyone. It's just some of the big ones really dominate.
And then I started to get really interested, because we do country codes. We actually sort of say, if I give this allocation, I gave it to X, and X kind of claims that they live in country whatever.
And so since 2012, these are the largest 10 allocations every single year. And it makes fascinating reading.
Number one, 2012, Argentina. You'd never have thought. But of course the telco there was probably doing some kind of planned rollout. So all of a sudden, 4,000 /32s are allocated in Argentina.
The next year is more like v4 -- number one, U.S.; number two, China. Because the last four years of v4, it was either China or the U.S. got the largest allocations every single year.
There's a lot of Chinese. And the U.S. infrastructure is incredibly well developed, so there's a lot of demand. So between large number of folks and sophisticated infrastructure and large demand, you tend to see most of the allocations going there. But not in v6.
For two years, '13 and '14, the United States and China, but where is the U.S. in 2016? It's down at rank four. Where is China? Down at rank 10.
Because once you've got it, it's hard to get another. They're so big, it's not likely you're going to come back.
Look at that one in 2015. In terms of the top 10 countries for allocations, this is the first time AFRINIC has ever been at the top of the scale in terms of countries.
One provider. The local mobile provider. One allocation, it was a /22 or something and all of a sudden South Africa is the largest.
Let's just focus a little bit though on 2016. Now, there's a fair deal of v6 in the United Kingdom, thanks to Sky, so 9,000 /32s is kind of okay.
Deutsche Telekom is rolling out v6 in Germany, and, you know, it's painting the map green. This is terrific.
Netherlands, amount of deployment, less than 10 percent. So we gave them an enormous allocation but can't see any.
United States -- Comcast, Verizon, AT&T, 1,000 /32s, yeah, yeah, growing infrastructure, I dig it.
Russia -- 1,000 /32s, can't see a single v6 user. Well, I exaggerate; there are a few. But that's a lot of allocation and there's almost no usage.
France, well, until France Telecom gets moving, it will always stay at where it is. Brazil is kind of moving. But Spain, Italy and China, there's almost nothing there. The actual managed allocations in those countries is really quite small for usage.
So you kind of wonder if the hoarding word is appearing inside all of this. So let's have a look at this and try and understand a bit better.
So instead of sort of going down there, let me back off and go to the routing system. Because when we hand out a block, you will advertise some of it and not advertise the rest.
So the purple line is what the RIRs allocated. You'll notice the discontinuity, and I'm sure LACNIC will explain it to you if you ask Oscar nicely.
The one-line summary was that there was a /18, which was a single line block to Brazil. And back in 2013, they broke it back up and started recording the individual allocations out of that block, so the block itself notionally got returned and the individual allocations took back, hence the discontinuity.
The green line down at the bottom is what we see in the routing system. Steady growth. But the line in the middle is the bits that are unadvertised. Can't see them.
Now, what's utilization in ARIN? You've debated it long and hard, so you should know the answer. It's sort of -- I've used about three-quarters, 80 percent of my addresses. And so the whole idea with v4 was to keep that unadvertised amount low so that you kind of got some, used some, got some, used some.
But in v6 it's going in a different dimension. Right now the advertised amount of addresses is about 45 percent. So 55 percent of what we've given out so far in all of v6 we can't see in the routing system. It's just not there.
45 percent is visible, 55 percent is not. What's going on? Back to the country list. In the U.S., we've given out -- I'll go to /48s, because it kind of makes it easy -- the equivalent of 10 /48s for every single one of your 283 million users in this country. 10 /48s per user. You advertise about a thousand /48s. That's the equivalent of 11 /48s per user. Yeah, so-so.
China, in actual fact, there's a lot of users in China -- 694 million of them. So they have about half the allocation size. The amount of allocated 48s is only two per user. But advertised, because they don't advertise much, it's actually much higher, 23 per user.
You'll see some of these countries are bizarre. Sweden, Sweden -- where are you, yes, there you are -- due to a complete lack of attention by the regulator years past --
-- I haven't finished yet -- the v6 infrastructure was trailing badly and no particular provider in Sweden felt motivated to actually deploy.
So they actually have quite a large allocation. But because there's almost no deployment, what's advertised is spanning very, very few users, less than a million. We really can't see it there.
So in Sweden there's this huge amount of allocated space lying idle. And that's one of the bigger ones. Egypt, Taiwan and Ukraine have a similar kind of situation.
So why is there disparity? Because all of you, in theory, go through the same process of justifying need. Yet, the outcomes are radically different; that they vary dramatically from country to country.
My suspicion is we're reliving a history when we shouldn't. The whole reason for the RIR system coming up was one of the principles was conservation.
We knew there was a timeline. We knew it wasn't going to last forever. We knew we couldn't be profligate. We went through this whole thing about, "Do we really need it? If you don't need it until tomorrow, I'll give it to you tomorrow; just wait, exercise caution."
And so a lot of countries now go: Right. V6 rules, different rules; I want the lot now. And that's what we're seeing: "I want the lot now" is dominating a lot of these allocations.
Now I'm not saying that's right or wrong. V6 is prodigious. There is a lot of space. You can't see the twilight of v6 anytime soon. So in some ways, it's not particularly bad that this is happening. But it is interesting to observe that this is an entirely different behavior by us as an industry; that we're now taking the opposite of conservation and going, in some cases, wildly mad, like Sweden, getting stuff when we don't need it yet because the regulator really hasn't pushed the industry into doing something.
I'm going to win that debate sooner or later, if I keep returning to it. But that's v6.
I want to now turn in the time available to quickly go through v4 and come back to some of the discussions and things you've been seeing about transfers.
So the first thing: When do they all run out? The last /8 policies in APNIC and RIPE have actually dramatically changed their picture.
APNIC was the first to run out in 2011. Interestingly, that last /8 will run for almost 10 years. We never thought it would last that long.
Currently, it's sort of looking at early 2020. The RIPE NCC, they didn't actually stick to a /8. They had whatever they had and put it into a pool they called the last /8. So they had a larger pool to start with. That will run through to about 2021.
AFRINIC, I don't know how the soft landing policy is going to work. If they did nothing, the middle of next year. If they do something, that will change.
LACNIC and ARIN, well, you know where you are. Nothing down there, right? You know.
And that's the kind of decade of allocations that happened over that period. We were doing fine until the global financial crisis.
And that's the peak demand of that industry, 2010, quarter of a billion addresses per year. And we had tight policies. So the incipient growth rate, 10 years ago, was quarter of a billion new addresses per year.
My suspicion is, right now, with the Internet of Stupid Things, you're going to be up to around half a billion per year or higher. Already the Internet has around 12 billion devices all hiding behind NATs. So that incipient growth rate is still going there.
And at the moment, NATs are being truly prodigious and just absorbing all that stuff and keeping the stupid things behind barriers. Just think about that when you talk about v6 and no NATs when you expose the stupid things to the cold light of public networking, what's going to happen to your world. Whoops.
And the exhaustion profile, as you see, we are truly running on empty. Where did the addresses go?
Again, by country, it's pretty easy to see where they went. Last year it was almost all Africa. That small amount around the U.S. There's a certain amount of date wrangling that ARIN do when they do transfers and so. And it's difficult with ARIN to track dates. So I suspect there's a bit of an echo there.
What's left? The available /32s: APNIC about a third of a /8; RIPE, about two-thirds of a /8. ARIN has 0. Except it has 6 million addresses reserved. What are you reserving them for? Is there a typhoon coming?
What's going on there? The RIR system together has got a little over one /8 reserved. And in some ways I think you need to be honest, RIRs, including me, with the folk who need addresses to actually understand what you're doing here, because that's a lot of space.
And it's not a public conversation very often about exactly how that's being treated in every single RIR.
So, yes, there's a lot of reserved space still sitting there, marked reserved, that at some point would alter the picture. Why does it need altering? No one's willing to go all IPv6/no IPv4 yet. Not even in Sweden. No one's willing to make the jump.
We are still addicted to 4. And if you're just hanging on to stuff, you're not helping. So think about that number. Think about what you might want to do with it.
I want to look where these addresses are coming from, though, advertised versus unadvertised per pool.
Different picture. The unadvertised pool is way down at about 45 /8s, as advertisers kept up because there's not any more addresses, right down there, the unadvertised pool.
Let's amplify that up the last 14 months. No, longer than that. That's right, start of 2016. Notice how the pool's shrunk in size.
Let's put that together with the other two lines starting at 0. Over the last 13 months, the RIR system allocated 1.4 /8s.
The routing system grew by two /8s. We recovered two-thirds of a /8 from the old legacy pools and put them back into action.
Thank you. This is what we meant to do with transfers and trading, to take otherwise locked-up addresses and actually release them and actually make them useful again.
So that is working. And there's still another 45 /8s. I'm not sure what the effort is. I think it gets exponentially hard. And the easy ones has already been flushed. But that pool is being drained to some extent and it is helping others. And that's a really good thing.
So let's have a look at about this, because the aftermarket and the address transfer market is still quite vibrant. Some are sales. Some are leases. Some are clear. Some aren't clear.
Let's look at the ones that are clear. Number of transfers per year, as you can see, 2016, big year, 3,700 transfers, first few months of 2017, already at 500. Another big year coming up.
Volume, that's a lot of addresses. In 2015, 47 million addresses got moved around. 2016, 33 million. Already this year, 5 million.
So there's a fair few addresses actually moving. So let's look at country codes.
The U.S. is talking to the U.S. a lot. A lot of addresses are moving. 58 million of them. This is in total across all of the transfer logs.
Canada to the U.S. Canada is a net donor. I hope they've got a lot of money for them. Interestingly, the biggest one going out was the U.S., not to China, but to India. Not to China but to India. Russia within Russia, you can read it as well as I can. But there are some surprises. Romania to Saudi Arabia, 1.3 million, didn't expect that. Romania to Iran, similar amount of space.
So let's concentrate on ARIN. Where did ARIN folk export to? Now the Caribbean is confusing, and there aren't very many. So I just simplified it and I said you're just Canada and the U.S., sorry everyone else.
Predominant export market, India, then China, and then Canada to India. So around 5.6 million addresses net left to India.
As you can see there, even Australia, we got half a million addresses from the U.S.. Thank you very much.
Where did you import them from? I think it's mean that you sucked 6,000 badly needed addresses out of Saint Kitts and Nevis. That was just unfair. Just give them the money and leave them with the addresses. They need your help.
But, yeah, certainly that's where you imported from. They are a little bit surprising, some of them.
How old? Complicated graph. But I'm trying year by year to understand the age profile of addresses that are transferred.
Did someone get it and flip it? Or is this old stuff that you got years and years ago?
The purple line is the first year of transfers, 2012. 40 percent were handed out recently within that year, less than a year old. So there's a certain amount of get and flip going on.
As the years progress, and the last year is the big red, 65 percent of all the transferred addresses are more than 20 years old.
Again, we're transferring our history, which is actually what we wanted. All this talk I hear about speculation, and, you know, I've got the addresses just to trade, there's almost no evidence. The oldest address that was allocated that got traded was more than five years old.
So the last /8 material coming out of RIPE and APNIC isn't actually hitting the transfer logs at this point in time. So in some ways the industry is sort of doing what we expected them to do.
How complete are these logs? I don't know. You don't know. Some address brokers might sort of take nuance with what we're saying. They might say you haven't got the complete story. They could well be right.
How can we find out? Difficult. They won't tell me. So that's okay. I don't need to know.
Let's look at BGP. Because routing tells you everything. The address system grew by around 59,000 advertisements. But that's not true. We lost 67,000 and we gained 126,000. The growth is the net, not the actual.
So in terms of addresses, five /8s disappeared, eight /8s appeared, across the year. There's a lot of movement there.
So I look at that movement and say: Is that movement in the transfer logs? So 8,663 of those things are in the transfer logs. Cool. 117,982 aren't. Confused.
I am. So there's a lot of movement that we're not actually recording in the registry, for whatever reason. And you can certainly categorize them and go: Well, what's listed and what's unlisted?
We capture about 10 percent of the movement. The rest we don't capture. So we're sort of seeing 1/10 of the movement of addresses.
Now, we don't know what's transfers and what's other bits of movement. Totally not. But I do know of the things that moved and changed, around 10 percent of them are transfer logs.
Look at the age of these things: Interestingly the age profile is similar to the transfer age profile. 20 percent of all these moved addresses are more than 20 years old. 50 percent of this is more than 10 years old. So basically this is old stuff moving, same as we see in the transfer log.
So what can I say about this? We're doing a decent job with a bit of it, but we're not doing a good job with all of it.
And that kind of disturbs me a bit, because when we start moving addresses from people, person to person, either you use a registry for the way in which the new owner can say to everyone else: It's my address now, it's no one else's but mine. Registries are a common public asset.
If you do this stuff under the table, you're relying on lawyers. You're relying on bilaterals and letters of association. And that leads to chaos within seconds, because not everyone knows. Not everyone can tell. Not everyone understands what's going on versus what's in the registry.
And once reality and the registry start to diverge, this industry has a problem.
And so that number worries me, because 90 percent we don't understand is a really, really big number.
So what this means: We need to look harder and do more work. And there's a lot more analysis that needs to happen here. And I'm willing to put my hand up and do some of it, but you're going to have to do some, too.
We've really got to understand why a lot of that movement isn't being recorded. What's going on and to what extent arrangements like leasing and other forms that aren't naturally expressed in the registry, maybe we need a way to express that to at least understand that these days there's a subtle difference between the owner -- the titleholder of a title -- and the person who is knocking at your door saying, "Please route this address, I've got the use of it today."
And understanding that distinction might well give us some more insight into making our registries more reflective of reality.
I did it. I made it. I've got four minutes to go for questions. Thank you very much.
Alain Durand: Alain Durand speaking on my own behalf, not any of my employers past, present, or future.
You're talking about addresses that are moving but that are not transfers by definition. You say that there are 90 percent that are not recorded.
I would actually make the case that it's much worse than that, because there are things that are moving around but that are not shown into the BGP table, simply because they're private contracts that we have heard about where people are logging addresses for the next five years and they're simply not used yet.
So, first, private contract by definitions are private. And we have no idea how many there are. Maybe some of the brokers know how many there are. But from an outside perspective we have absolutely no idea.
So I would say take a risk, things that are transferred, things recorded properly. There are things that are under lease contract, LOAs, that are advertising to the routing tables, that we see somehow but not recorded.
And there are things that are simply not seen at all, because they're locked into private contract. And the question is: Why are people doing that?
And I will posit that there's an underlying theme in that, in your previous data you're showing, why people are having all those IPv6 allocations and not apparently using them.
It would appear as if all those things are essentially insurance policies. Bet hedges against what could happen.
Maybe it would be more difficult in the future to get v6 addresses, I'm going to get them now so I don't have to worry about it; or I'm going to buy addresses, not transfer them, buy them, because the price is cheap now and I think that it may go higher.
Almost like hedging things. And as a community member -- again, not speaking on behalf of any of my employers -- I'm wondering how we should really approach those betting and hedging things; should we have some kind of a mechanism to really deal with it?
Geoff Huston: What was that comment yesterday about long speeches disguised as questions?
However, I do agree with your observation, and certainly from the RIR's perspective, as an allocator, who kept a record of what they allocated to a full-blown registry operator, seeing a movement of resources beyond simple allocation, there are many questions like the ones you've raised.
And I suspect we need to look closely in these kinds of policy meetings about how we continue to make our common registry our common asset; the thing we consult to understand where and why an address.
And if we can achieve that, I think we'll have fulfilled our basic mission. But you're right, there are a lot of challenges. So thank you for a few more.
Peter Thimmesch: Peter Thimmesch, Addrex. Geoff, as always, entertaining and filled with so much data; we parse it all back in our office.
But, I'm going to repeat this every time I get a chance to say it. And Axel is here. RIPE purposely, through its policy process, has decided not to list transfers of legacy space.
So you keep always bringing up -- I want to make sure everyone knows -- there are transfers legitimately getting updated in the registry in RIPE with the correct information updated; it's just not in the list of transfers, because it's not covered under current rules.
Geoff Huston: I would desperately like to see all of us adopt a common transfer log format. I'd like all of us to understand dates.
I'd like all of us to publish these logs, not only of transfers, but of things that happen.
End of Geoff getting down on his knees pleading with the RIR system to do what Geoff wants.
But why do I think it's useful? Because I really think there's a feedback loop between the policies you make and the industry you're working in.
And what you really want to do is make good policies that make this industry work better. And certainly registries and understanding the transactions helps us all do better policy.
So, yes, I don't really like the idea that data gets discarded or hidden. And it's a pity. And it would be nice if we could get a more complete picture.
But, you know, I've said that to the RIPE NCC folk as well. We all understand the problem, and I suspect folk are working on it, and I would dearly like to think so.
John Curran: As it turns out, you'll hear some of this tomorrow. There are efforts among the RIRs to get one step closer. I would never say aligned. But one step closer to alignment in the areas we can on common log file format.
And so we're getting there. There are some places where we may not ever agree, country codes, dates, a few little other things.
But we are -- there's an effort going on right now between the five RIRs to try to get at least the first round of alignment done, and Mark will say a little bit about that. But we are making progress.
Geoff Huston: I think the front microphone.
Chris Woodfield: Hi, Chris Woodfield, Salesforce, ARIN AC.
One quick thing to point out is that unused space does not equal unadvertised space. Where I'm going with this is I'm wondering when you might go back to the difference between allocated v6 space versus routed v6 space.
In an IPv4 world, it's common practice for people to use RFC 1918 for internal networks. In v6, there's no reason to do that. There is a ULA, but my anecdotal information says that most people just take a block out of their public space for any internal application.
Actually, I'll put Dan on the spot and ask him: Does Comcast use ULA space or public space for your private v6 routing?
Dan Alexander: It's all public.
Chris Woodfield: Yeah. Exactly. So I'm wondering how much of the unadvertised v6 space could be explained by that practice, if any.
Geoff Huston: The problem is, because it's private, it's really hard for researchers like me to come in from the outside and poke and twiddle.
There is a lot of work going on right now and some interesting papers done with Akamai data over the true usage of v4, because everyone goes to Akamai, don't they?
And this is kind of interesting stuff. And it's sort of stuff we hadn't really thought about before about how to think of the distinction between used in a public context, used as in advertised, versus allocated. And understanding a bit more of that.
Why? Because, again, it helps us make policies that reflect reality. So, yeah, it's an interesting question. Thank you.
I think the front. Elvis and then -- yeah.
Elvis Velea: Elvis Velea, V4Escrow. We had a pretty good chat last night about lots of these things.
First of all, legacy space, parts of it, does get published by the RIPE NCC. And that's the inter-RIRs, inter-RIR transfers that happen. Only what happens within RIPE does not get published. But let's hope we'll get to fix that as well.
Then the second thing I wanted to mention is: Have you noticed that in the RIPE region there were -- well, about 200 transfers in 2014 -- no. Yeah. 200 transfers in -- no. Actually, sorry. I got my numbers wrong. About 920 transfers in 2014, while in 2015 they jumped to 2700.
I have a feeling that the reason for that was the cleanup of the IPv4 policy in the RIPE region at the end of 2014, which actually ended up in removing the needs policy.
Geoff Huston: So you're supposing there was a correlation? You might well be right. I don't know.
Elvis Velea: So I have a feeling that by removing the needs-based policy in maybe the ARIN region as well -- APNIC, I know they have a proposal, but let's see if it actually happens. I have a feeling that if this will happen, then most of the transfers will surface. Most of what is hidden under lawyerish futures, whatever, contracts, will surface, because there will be no reason for people to get addresses and not put them in their name anymore.
Geoff Huston: At some point you're crossing into a boundary of advocating policy. That's a fine thing to do, but probably when that policy comes up for discussion, ARIN might well be the right place.
Elvis Velea: And the last thing that I wanted to mention, you're saying about 90 percent of what's happening is not visible. Well, it's visible, but we don't know what is actually --
Geoff Huston: The routing system said it changed. I couldn't see it in the transfer log. I am confused.
Elvis Velea: So that means considering the two /8s that were a bit more than two /8s that were transferred in 2016, that means that about 18 /8s have been changing stuff but not --
Geoff Huston: Bedebedah. Somewhere down here I have it listed, I've forgotten where, details, details, details. I didn't memorize my numbers. 16,000 were removed, prefixes 20,000. Haven't done the address space there.
A fair amount. A fair amount is all I can say.
Elvis Velea: If we think of it like number of addresses. If two /8s were transferred in total in 2016, and that's only 10 percent, then that means that about 18 /8s are --
Geoff Huston: I don't know. That's the whole thing. They moved in routing. I couldn't see them in transfer. That's where it stops at this point. We don't know. We'll make it quick because of meeting...time.
Kevin Blumberg: Yeah, I'll make it quick. Kevin Blumberg, The Wire. I think that's the key. The routing table has changed. I haven't seen them in the transfer log.
I shouldn't necessarily correlate the two because that's a really bad idea. The fact that the routing table has grown made perfect sense; when we've run out of space in the free pool, we're going to disaggregate, we're going to use smaller blocks.
That makes sense. Stuff moving around, Geoff, is also explained because there's a lot of legacy space. People use /24s and whatever it may be, /21s, /20s, from their upstream years ago that are now being reclaimed and reused.
People are being more careful about the space that they gave out originally; are starting to reclaim it back and reuse it on their own networks.
So it might have been advertised on Network X and pulled into Y. I want to be very careful not to correlate the routing table with the transfer.
Because 90 percent is a very aggressive way to explain that there's a problem when that might not be a problem.
Geoff Huston: So what I'm saying here, it's sort of down there, there's a large body of movement. It's not in the transfer log is what I can say. But I can't say why. And you're exactly saying the same thing.
It needs more work. Right? It needs more investigation. Yes. Thank you.
Owen DeLong: Owen DeLong, Akamai Technologies. The document Geoff alluded to is The State of the Internet report, which we publish periodically. And it's readily available from the Akamai website for anyone who is interested.
All kinds of wonderful statistics about how people are using addresses. And we've got a reasonably good vantage point on that.
Geoff Huston: And a blindingly good research paper by a young kid called Philipp Richter from the University of Berlin with Dave Plonka from your organization.
And if you want a really nice piece of research to read when you can't sleep tonight, go and read it; it's amazing. It even uncovers the behavior of DHCP address pools, in the market - it's so cool. Nice piece of work. Kudos to him.
Owen DeLong: Coming back to the 90 percent that's not accounted for in the transfer market, I think probably half of that is likely explained in ISP churn and people moving their PI prefixes among ISPs. I know we do quite a bit of that on a fairly regular basis ourselves.
Geoff Huston: I'll leave it to budding young 20-year-olds who want their master's degrees to investigate fully.
John Sweeting: John Sweeting with ARIN. Just on your reserve blocks, you had 6 million.
Geoff Huston: Yes, I did.
John Sweeting: So the majority, two-thirds of those are our special 4.10 and 4.4 for IPv6 deployment. I'm not really sure why they get designated differently than other special purposes for new entrants and the other RIRs.
Geoff Huston: In the crude terminology of reserved, allocated and available, they're available, just not under the old policy.
John Sweeting: Correct.
Geoff Huston: And it would have been, I suppose, easier if it was 4 million to have marked them as available, because your policy on handing them out is different, but they're still available.
John Sweeting: And the other 2 million are the reserved -- are revoked and returned -- that we covered earlier. So they're available, but they won't be available until the future.
Geoff Huston: You're saying with a simple change of nomenclature, you've reduced the pool by 4 million. Well done. Good work.
Joe Provo: Geoff, one remote question. Kevin Otte from Flying Penguin. Geoff says we have an IPv4 addiction. Do we need a 12-step program or just go cold turkey?
Geoff Huston: I couldn't possibly comment.
John Curran: Thank you, Geoff.
John Curran: This has been the first 11 minutes of our break. The remaining 19 minutes will take place now.
Out the doors, you have a break. Be back here promptly at 3:30. We have a policy block. Be here at 3:30. We'll take the last policy. Thank you.
John Curran: If folks will come in and be seated, we'll get started. I am competing against double chocolate coated brownie pops and losing the battle.
Paul Andersen: We now will talk about the large fee increase.
John Curran: No, we'll talk about my large waistline increase. Okay. Come on in. Very good.
Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers
John Curran: We're going to get started on our final policy, Draft Policy 2017-1: Clarify Slow Start Transfers. And this is a Draft Policy. So at this time -- actually, at this time it's going to be presented by the AC. Do we have Alison here? Oh, very good.
Alison Wood: Hello, everybody. My name is Alison Wood, and I am presenting Draft Policy 2017-1. I encourage you to reference your Discussion Guide because the text is in there. One clarification, it refers to 2015-5, and the correction is it should be 2016-5, if you take a look in there.
All right. With the adoption of 2016-5, the transfer policy is severed from the ARIN allocation/assignment policy. And so an algorithm has been developed to make the transfer more predictable and the correct size, and it will align it more with organizational growth and give it some predictability and stability.
So the solution is that organizations who demonstrate efficient utilization to the utilization of their most recent transfer, to extrapolate a two-year projection up to double the size of their previous request.
That's a tiny bit confusing, so we do have some real-world examples in the next couple slides. So stay with me. All right. So all of this is in your Discussion Guide. These are the proposed changes. The algorithm is described here in this paragraph, but we're going to look at a real-world scenario of that.
So if you're an ISP and you asked for a /26 about 90 days ago and you used over 50 percent of it and can demonstrate that you have used those IP addresses, then you can come back in and, using this algorithm, ask for 64 addresses divided by 90 days times 730, which would give you 520 IP addresses, or a /23 approximately. And then you would have to demonstrate that over the next two years you're going to use about 50 percent of those addresses.
So here's -- and, again, this, I believe, is in your Discussion Guide. If not, it's here. And this is just a breakdown of the real-world scenario that I just explained with the actual algorithm. So if you want to follow that.
So a couple discussion points on this policy is that, as a community, do you believe that we truly need this change now that we have the new transfer policy? Especially some of the policies that were addressed over the last day and a half. And if this change isn't necessary, is there a need to provide a different path for qualification of slow start transfers?
Paul Andersen: Find my trusty cell phone/clock. Sorry.
Alison Wood: I'll try to keep John from taking your phone again.
Paul Andersen: Yes, thank you. I would appreciate that.
The microphones are open. We are for sure competing with chocolate as I look out onto the vast tan seats, both in terms of just people getting to the microphones and -- are there comments on this policy proposal?
Please approach a microphone. Start typing. This is your last chance to contribute to policy at this meeting, other than the ever exciting open microphone.
Owen is approaching a microphone.
Owen DeLong: Owen is approaching a chair.
Paul Andersen: I tried. We have all the microphones open if you'd like to discuss the policy proposal, Owen.
Paul Andersen: 2017-1.
Alison Wood: I can cover the algorithm one more time.
John Curran: Maybe if you go through that last example.
Paul Andersen: We're going to go through one last example just because we saw a few people sneak in.
Alison Wood: Andrew's up.
Paul Andersen: No, go for it.
Alison Wood: So to go over that real-world example one last time -- let me back up to the slide. One more.
All right. So if you're an ISP, you're a small ISP, and you asked for a /26 three months ago and you have documented that you have used 50 percent of those addresses, you can use this algorithm, the slow start algorithm, to come forward and ask for more addresses that you're going to use over the next two years.
So the algorithm is that you can ask for 64 addresses divided by 90 days. That was how long it's been since your last transfer, times 730, meaning that you could technically ask for 520 addresses, or a /23, and then document 50 percent of the use of those over the next two years.
Paul Andersen: So, you know, we try to make remote participation as equal as possible so you understand what's happening. The ARIN staff have outdone themselves with the plethora of chocolate treats at the break, and we may have induced a small coma here in the room. We'll be mailing all of you who are remotely participating one of them so you can participate, assuming that doesn't violate some state law of any kind.
John Curran: Nope, they're all mine, thank you.
Paul Andersen: From the microphone, please.
Andrew Dul: Andrew Dul, CrowdStrike, one of the other shepherds on this policy.
I think the question that would probably be most helpful to the AC as we discuss this is, you know, is this policy, ideas in this, still necessary given the likely adoption of the /16 transfer change that we overwhelmingly supported yesterday? This would apply to large organizations beyond a /16, so perhaps this would be useful to those organizations as well.
But we'd like to hear if this is necessary or not, or this has perhaps been obsoleted by events.
Paul Andersen: If you like, we would totally invite input on that question. Please approach a mic or start typing. Rear microphone, please.
Joe Olivieri: Joe Olivieri, Root Level Technology. My question about this policy, this is maybe just a point of clarification. You're asking smaller ISPs for /20s, /26, /24, to request more. Why shouldn't this come from the pool that's been reserved for /24s to implement v6 as well? Has that been considered?
Rather than trying to wait on new IPs coming in, ARIN already has a pool that has 99.3 percent still available of a /8, I believe; is that correct? /10, I'm sorry. Of a /10, and that's directly for the purpose of awarding a /24 up to every six months to help implement v6. So why wouldn't we use that for this policy, I guess, is my question.
Dan Alexander: The shepherds may be able to clarify this better, but the /26 may have just been a confusing example. The section we're talking about modifying is actually the Section 8 transfers. So it's not actually related to any of the special allocations.
Joe Olivieri: Okay, but again, if a small ISP is requesting a /24 -- let's just use that as an example. Why we wouldn't forward them to the free /24s that are currently available from the reserve pool rather than have this address it? I don't know if I'm asking the right question.
Dan Alexander: They actually wouldn't be because the minimum request is --
Paul Andersen: Back you two. Dan first.
John Curran: Go ahead, Dan.
Dan Alexander: No worries. They actually wouldn't be because the minimum allocation is a 24.
John Curran: It's also possible that the party needs IPv4 addresses, and they need IPv4 addresses for the purposes that aren't compatible with the reserve policy, which is for purposes of deployment of IPv6.
We do actually assess that. It's possible for someone to come in and say, "I'm going to use this, and it's for this purpose." And we go, "How does it enable IPv6 deployment?" And they go, "It doesn't." And we go, "We got nothing."
Joe Olivieri: Thank you.
Paul Andersen: Owen, did you have a direct response to that first before your comment?
Owen DeLong: Yeah, I do. 4.10 was very specifically oriented towards transitional technologies, as the author of 4.10.
Paul Andersen: How convenient you're right there.
Owen DeLong: It was specifically intended for if you're going to do something like 6rd or certain other types of transitional v6 deployments that involved certain technologies of tunneling most of your v6 through your existing v4 infrastructure, you need a certain amount of v4 address space for that infrastructure in order to be able to do that, and this was to provide that specific v4 address space for that specific purpose.
It was not intended to be, well, I'm also deploying v6, but I need v4 just because I need v4, and so I'm going to go use this chunk of address space for that. It's not designed for that.
If you're not using it specifically in a way that specifically enables your v6 deployment because you're using something like 6rd or some other v4-dependent v6 deployment technology, of which there are, unfortunately, many, then it really wouldn't apply to you and you really wouldn't be eligible to receive space from that pool under the, at least, intent of the policy. You may be able to find some letter-of-the-law way to get around that.
Paul Andersen: Thank you for your clarification. Did you also have a comment?
Owen DeLong: I also had a comment. I that think this proposal has at this point been largely overtaken by events. I think the /16 oriented policy we discussed yesterday obviates the need for it by and large.
I think the fact that this would allow much larger chunks on a more liberal basis would actually work as an end run around the more constrained intent of that policy, and I therefore oppose this policy as written.
Paul Andersen: You mean putting aside the policy yesterday? If that policy just didn't exist, would you still be in support?
Owen DeLong: I would still oppose this because it doesn't have sufficient constraints.
Paul Andersen: Thank you. Side microphone, please. Your name --
John Springer: John Springer. I'm unaffiliated except for a position on the ARIN Advisory Council. If the choice of the subnets is accidentally unfortunate here, I'm less in support of the slow start aspect of it. But if it is meant to enable individuals to use the transfer market for larger blocks, I am in support of continuing to work on it.
Paul Andersen: Thank you.
If you would like to -- sorry. If you would like to comment on 2017-1, Clarify Slow Start for Transfers, please approach a microphone quickly, because I do not see anybody other than Jason right now. So we will close the microphones after he speaks.
Please go ahead, front microphone.
Jason Schiller: Jason Schiller, Google, ASO AC. The policy we discussed yesterday, one of the slides talked about how one of the co-authors of the policy did not like the /16 cap.
My intention was for the policy that we discussed yesterday to be paired with also the policy that allows anyone to get a /24 if they don't have any direct resources as a way to implement slow start in the transfer world and in a sort of simplified sort of way.
My intention with the policy we discussed yesterday was, if you needed more than a /16 every six months, you could only take a 16. You could use it, show that you're using it, and then take another 16 -- rinse, wash, repeat. But that was taken out. And the reason why it was taken out was because it said, if you're big enough that you need more than a 16 every six months, then you're big enough to use the standard process.
I really hate the standard process. This two-year future looking, hand-waving justification, it's very difficult to come up with. It's very hard to chase down marketing guys and to put some teeth into getting a real number, and it's very hard for ARIN to question the reality of those numbers. They're not really in a position to say your business plan looks like crap.
All they can really do, if they think it's not a decent request, is to push back and ask more clarifying questions. And what this creates is an unpredictable result. It's unclear how many back and forths it's going to take before your request gets approved, and it's unclear how likely ARIN is to approve it because there's just -- there's no useful metrics here.
What I did like, when ARIN had space, was slow start, because that made sense. I used up the space. It lasted less than two years. Give me a bigger one, and when I use that up and it lasts less than two years, give me a bigger one again.
And that was my attempt to do here. It's simply to implement slow start, but modified slightly in two ways. One, to have an adjustable look-back window because things may have been placed on hold because you could not execute a transfer in a timely manner. So you need to be able to start the clock when a particular transfer occurred. The idea was to look back one or more transfers, figure out what the average daily utilization of IP addresses are, and simply project that out to two years.
I would have much preferred taking off the /16 cap and getting a 16 at a time and showing that you're using it and coming back, but I was deferred away from that and said use the standard process, and it's not clear to me if the standard process actually supports the slow start any more because of the way it's been severed from Section 4.
So this was just an attempt to make it very clear that this doubling is still supported.
Paul Andersen: All right. So you are in support then?
Jason Schiller: I do support it, yes.
Paul Andersen: Thank you so much.
Microphones are now closed. Any remote participation? Nope. Rear microphone for our last comment.
Elvis Velea: Hi, Elvis Velea, V4Escrow. While I already mentioned a few minutes ago I would be in favor of removing any space policy in the ARIN region and comparing to what happened in the RIPE region, where more than three years ago the needs based was completely removed and, well, it works, I am in favor of any policy proposals that would relax the requirements and allow people to actually transfer address space.
Therefore, I'm in favor of this policy proposal, and I would like to see even further steps towards even further relaxing the transfer policy.
Paul Andersen: Thank you for that. And that ends our discussion. Thank you to Alison for the presentation and thank you very much for your time. Hand it back to John.
Software Development Update
John Curran: Very good. We have one more presentation and then open microphone. The presentation will be Nate Davis presenting our Software Development Update. I should say ARIN's most excellent Chief Operating Officer Nate Davis.
Nate Davis: Thank you very much, John. Boy, the room has thinned out from up here. Those desserts must have been good.
Welcome, everybody, again. My name is Nate Davis. I'm Chief Operating Officer here at ARIN. I give this report at every ARIN meeting.
The reason why is I'm actually product owner for a couple of the Agile teams that provide input into the software development process. So I'm here to report on what we're working on within ARIN, and I do this at every one of the meetings.
So some of the things I'll talk about are strategic guidance. Really what governs what we work on within ARIN, how work is prioritized, projects that we've completed since the last meeting, some of the forthcoming initiatives or work that we're planning on working on between now and the next ARIN meeting, and then just briefly give an update on the ARIN consultation and suggestion process because that feeds a lot of what we work on within the software development arena within ARIN.
So starting first with strategic guidance, if you go out on ARIN's website and you look under About Us, Corporate Documents, you'll actually find ARIN's strategic plan that the Board reviews and revises every year.
And in that strategic plan at a high level, we're responsible for maintaining, developing, and enhancing functionality of ARIN services as sought by the users and supported by the membership.
And then within that strategic plan, we actually have two sets of organizational goals, some for 2017, some for 2018.
For 2017, we're responsible for providing automation as supported and requested by the Advisory Council, so we have to provide tools and software to support them, and continue to review and enhance online services, including making significant user-interface improvements, per user feedback and customer survey.
And this is some of the input that we collect vis-à-vis the presentation that Richard gave so well this morning.
And then, lastly, we continue to focus on community-suggested, customer-facing, high-impact software development efforts in a timely manner. So, again, we get all this feedback from you, and we figure out what's the low-hanging fruit, what's the most effective way we can spread engineering dollars throughout the organization.
So we have a bunch of items that kind of influences the priorities that we work on, and this is a list of them. And at any given time, some may be more important than others, but it's all things that we look at and we have to evaluate when we're setting priorities for the Agile teams that are working on development items.
So projects completed since the last ARIN meeting. So we've had some enhancements that we've rolled into production, but I do want to mention that at the last ARIN meeting, when I reported on this, I'd indicated that we needed to kind of step back internally and work on some infrastructure improvements. And we have been doing that, and we will continue to do that for some time.
As far as John and I, John and I have been pressing Engineering hard to really put product out that's beneficial to the community, and at some point, you've got to take a step back and actually do such things as upgrades and infrastructure changes to support the future. So we're in the process of that right now.
So I did want to mention that in the context of, these are the things that we have completed, but there's some work that's going on that doesn't necessarily have visibility because it's infrastructure related or we're upgrading some of our platforms and so forth.
So the ability to modify and reassign networks and delete reassignments from search results page within ARIN Online. The option to view free blocks as you manage your own IP address space within ARIN Online, you have the ability to view your own free blocks that you have and assign those accordingly.
We completed a change in our voting contact management. As you probably noticed in the last election, all voting went through your web user account as opposed to a specific voting contact, and we had a successful transition with that.
We're also continuing to do a lot of work in web accessibility and responsive web design. With this last release that just occurred recently, you probably see some of the interface changes with that. Again, this is going to be something that we're working on for some period of time, the web accessibility and user interface, user experience improvements.
We've also added a fourth type of the ability to assign zones, child zones, and that's been recently implemented.
And then POCs can now perform verification. We talked about POC validation quite a bit over the last day or so. And POC validation can now be performed by replying to the validation request email. So ARIN sends out these annual emails, and you can now just simply reply and in the subject line add the word "CORRECT," and those will be processed, and your POC will be validated accordingly.
So forthcoming initiatives. We had a request -- Alain. Is Alain in the room? Durand? Yeah, there he is. We're finally getting to your request, and that is to actually make some of the transfer statistics available on the FTP site. So that's coming up.
Again, we have some technical debt that we're undertaking, upgrades and infrastructure improvements. Continued work on web accessibility, UX and UI work.
We have an implementation that we've had actually open since 2012 by Dani Roisman to limit Whois query results for child network queries, and we're working on that presently, along with RPKI to 0/0 solution.
And then, lastly, unlimited result sets from queries from authenticated users via RDAP.
So those are things that we have on the plate that we're working on, and hopefully we'll get most of those, if not all, done by ARIN's next meeting.
Last thing I wanted to mention is just kind of a state of the union, if you will, with regards to ACSPs. So we've completed 26 of them. 20 of those actually were Engineering efforts, and that's been within the last two calendar years.
And I really want to take a moment to applaud the entire staff because not all these are Engineering related. There's been a number of them that have been completed by non-engineering staff within ARIN, and then 20 of them by Engineering staff. I really want to recognize the efforts there. The folks are focused on the things that you suggest through the suggestion process.
Presently, we have 27 open, and of those, 26 require engineering work. A few of them have some heavy lift, and what I mean by that is they require quite a bit of effort to actually complete. One of those is actually the routing registry project, which right now the Services Working Group is in the process of providing us guidance on that. But we have three ACSPs tied to the Internet Routing Registry.
And then, lastly, access restrictions for APIs. Again, that's another heavy lift item that we're looking forward to get underway and get completed, but it does take a fair amount of work. It's not something we can turn around right away.
And with that, that concludes my presentation. I'll take any questions, if there are any. None?
John Curran: I do believe the fact that we're off Bourbon Street and there's sunshine might be having an impact. Any questions for Nate?
Nate Davis: Thank you, everyone.
John Curran: We have come to the last event of the day. The last event of the day is generally an open microphone session. I'm going to turn this over to Paul, and he will manage the open mic session.
Open Microphone - Tuesday
Paul Andersen: Well, we'll see what excitement we can get to close off. So the open microphone, we encourage anybody to approach a microphone on any topic they wish. We'll be having one today and one tomorrow after our Members Meeting. So we generally like just topics that you might bring up to be a bit more policy oriented, but we're very lax on the rules.
Occasionally, people will come up, and if you have, for instance, a policy you're thinking of proposing, but it's just in the early stages and you want to get some early feedback, it's a great way to just approach a mic. Please approach a mic, and we'll see what happens in the time we've got.
Rear microphone, please.
Joe Olivieri: Joe Olivieri, Root Level Technology, Houston, Texas. I just want to thank ARIN for the ARIN on the Road program. That was a huge deal for me. We have been members of ARIN for years and have done absolutely nothing with it, but looked at it as a hassle to jump through hoops.
When Susan came to Houston, it was just convenience that I had the time to actually go to it. I want to thank you all for awarding me the Fellowship. I've learned so much just in the past two or three days and plan to become more active in it. So just -- ARIN on the Road works. Thank you.
Paul Andersen: Thank you so much for that. Thank you for the feedback. Me first. And thank you to Susan and her team, because I have attended many of those events myself, and they are great successes. I think we're in year four, five now? Five years?
John Curran: Eight. It goes fast.
Paul Andersen: A good thing just goes so quickly. We've been doing them for years, and they've been an extremely successful outreach attempt.
If you have an idea for a city where one might be hosted anywhere in the region, Susan is always looking for -- especially if there's events you might want potentially, you might want to co-host them at. We try to do five or six or sometimes eight a year.
John Curran: And I'd like to ask for a round of applause for Susan.
Paul Andersen: A round of applause for Susan.
Paul Andersen: Far microphone.
Dani Roisman: Good afternoon. Dani Roisman from SoftLayer, IBM. We had a great talk the other day and great update from Leslie where she gave some stats, number of transfers, number of transfers completed, percentage completed, et cetera.
And speaking during one of the lunches, we had a question around the table as to how many transfers has ARIN had to reverse in the past number of years, so transfers that have gone through, but for some reason had to be turned back.
Paul Andersen: After they'd been approved?
Dani Roisman: Yeah.
John Curran: So we work hard to try to vet these things up front because it's so much easier. When you ask -- you know, if any of you have said, why are you asking for that in a ticket? Well, okay, this is why. We're trying to make sure we don't remove and change a registry from someone who has the rights and assign them to someone else incorrectly. So we do extensive vetting.
But, over the years, I could say we have had a handful of 8.2 M&A transfers that we've had to revert. They fit on one hand. So it has happened. It's a very small number. They're all related to fraud, and I can't get into particular customer requests.
Dani Roisman: Any 8.3s that have had to be reversed?
John Curran: No.
Dani Roisman: Kudos.
Paul Andersen: Thank you. Rear microphone.
Susannah Gray: Hello, Susannah Gray, San Francisco Bay area ISOC Chapter and ARIN Fellow. As we saw earlier today, three of the five RIRs have implemented grants and awards programs that provide funding to community initiatives, and I was just wondering if there's ever been any discussion in ARIN about such an initiative.
And I think RIPE NCC is also discussing --
Paul Andersen: RIPE NCC is also.
Susannah Gray: Yeah, they'll be discussing with the community about programs. So I was wondering if there's ever been any discussion in the ARIN community.
Paul Andersen: We have ad hoc-ly funded efforts in our region and outside on areas we believe are related to our mission. We are in the process of finalizing a more formal one, which would be, I think, along the lines of grants so that there would be a more formal process by which, if parties wanted to request funding, so that we have more formal, that you'd understand the process and the timing so that it can be properly budgeted.
There has been some very casual discussion regarding, I guess, farther in terms of -- I know that APNIC is now down the way of the foundation, but certainly nothing that has progressed on that.
John Curran: I want to add on the formal aspect. So over the years, if I go back eight, ten years, we get a request for funding, and everyone would look at it like: Now what? Because we didn't budget it, and you get them from all sorts in there. Some are technical projects, and some are outreach.
So over the last few years, we've gotten a little better. We actually have a formal line item where we budget for Internet support activities that's separate from our reach. It's literally for that sort of thing.
The problem is, it still has a wide range of people seeking support, everything from technology projects to publications to -- you all use software on the Internet. Some of those software people would like to have their free and open software funded. So we probably have 20 organizations that ARIN would -- would like to have ARIN as a member.
If you have a need for funding, you can send it to me, email@example.com. In case you haven't figured it out, it's all over the place. But you can send it to me. We batch them up. Towards the summer, we prioritize them, staff writes up whether or not it makes any sense, and it's part of the board prioritization project every year.
So we now have a process. If you have a need for funding, we're happy to consider it. I will say, last year we turned down every one of them. That's probably not a great track record, but we're in a situation right now where we've been trying to catch up with the engineering work. Nate just gave a great presentation about everything we've been doing.
That means we're literally operating slightly over revenue with our costs. In that situation, we tend to do less. At the times where we're a little more normal, we have more flexibility.
Please, if you have something, send it to us. We have not yet discussed setting up a separate foundation for that purpose. It's not clear. There's so many people doing it, it's not clear we have to.
Paul Andersen: And at a high level on that -- and this might sound obvious -- ARIN gets its funding from registrant money, money from people in this room, and some investments that we make, which started with your funds. So we're very conservative how we allocate those funds.
But if there is community support for us to look into these initiatives, we're quite happy. But we've always taken a more conservative approach because we're spending your money. That is generally why we've not gone down that path in a more wider sense.
Susannah Gray: Okay. Thanks for that. I look forward to more information as you get it.
Paul Andersen: I'll go with front microphone. You may have been first, I apologize.
Owen DeLong: Actually, I'll defer to my Fellow.
Austin Murklund: I'd also like to express my gratitude for the fellowship. This has been an eye-opening experience for someone's whose first experience to ARIN was the NRPM. My expectations were radically different than what I experienced here.
My second question is, I know there's a lot of discussion about the narrative of community networks, and there was a roundtable discussion. I was just wondering if there was any results from that discussion.
Paul Andersen: So, actually second question first. If anybody was at that lunch topic and would like to volunteer to give a summary report, we'd appreciate it.
On your first question, I'm very glad that you enjoyed the Fellowship Program. We're very proud of that. One thing I would just say, while we're on the topic of fellowship, is I would encourage you, anybody in this room, to look at the Fellowship Program.
It's changed quite a bit in terms of who qualifies and how it's grants and all that. In fact, it's much, much wider, simpler, less words in terms of qualifications. People, for instance, can return multiple times.
So I encourage you to all encourage others to put their names in for that. San Jose is open as we speak, if I'm correct.
I believe David Farmer has jumped up to give us the report on your second question.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I'll just give a quick little summary. Apologies if I -- you know, if anybody has any -- and they can add if they wish.
Paul Andersen: It's never a shy community.
David Farmer: Exactly. There was a fairly strong opinion that we should change the 100 percent volunteer requirement. There was a number of discussions, wide ranging, on what else can be done, and I wouldn't say there's a strong conclusion.
There was a number of community network participants there that they basically -- the real answer is, they didn't know it existed. They probably didn't even know ARIN existed most of the time. Or if they knew ARIN existed, hadn't actually looked at any of the policies because assumed that it was just about servicing ISPs and that they couldn't get address space.
So there's some -- but it was some definite ideas on and discussion about how to maybe do some better outreach. One of the things that was brought up was the ARIN on the Road events and seeing if we can get the community -- some of the community network activists for an area -- into those events and trying to get the invites out to the right people, because, again, it's the right people knowing about it at the right time. So we're sort of thinking about some of those things.
And then I'll step away.
Paul Andersen: Okay. On the topic of community networks, if there is others that would like to give input, I think one of the challenges -- please approach a microphone.
Could those at microphones, if someone approaches, yield to those wanting to talk about community networks for a couple minutes.
I guess one of the challenges I'd say is we are just trying to understand what are the current problems. There was a great amount of text work, as Cathy noted earlier, to try and -- years went past trying to bring the text to where it was, and clearly it was not in the end useful, either through knowledge of its existence or just the application of it.
So now would be a great time to approach a microphone if you'd like to speak to community networks. My apologies. I'll also recognize you in a minute. Community networks at the rear microphone.
William Michael Cunningham: Yes, my name is William Michael Cunningham. I'm here with ICANN NARALO. I was at the community network table.
One of the things I wanted to point out was the issue with respect to the signing up for community network discount services. There apparently is no button on the signup page that you can click to say that you're applying for community network status or services.
Now, again, I don't know this, but this was one of the interesting things that came up as part of the discussion.
The second, I think, key point out of the discussion, as I got it, was recognition of the value of the intent with respect to community networks and intent -- and a value that's growing with respect to the social return that we expect to see from community networks.
Paul Andersen: So a little commentary if you haven't been around the community for many years. The threshold you had to do to get a block of address space was much higher than it is now, and we would see a lot of community networks coming and saying that the threshold was too high for the small -- what typically were very small organizations.
My understanding was that the community networks proposal at that time was much more oriented towards trying to make it the size of networks these people were operating could qualify for space.
Really, there was also some discussion regarding discounting and whether they would qualify for a lower rate. In the end, that doesn't really apply right now for it. Really all the current one does, as far as I read it, is just making it easier to qualify, and it's not even sure, given that all the other thresholds have lowered around it, that it is much easier.
As for the button, there's really no button on when you apply for address space. There's no real button. You just simply make your request, and then staff will apply the policies based on that. So if you say you're a community network, yes, they would apply it against that.
Perhaps, though, there is some education in letting them know that you need to specify that is available to you. Did you have a follow-up?
William Michael Cunningham: No, that was it. You covered it. Thank you.
Paul Andersen: Jason, you're here to speak.
Jason Schiller: Jason Schiller, Google. I wanted to be very specific about the language we discussed about how to define what a community network is.
Paul Andersen: Right.
Jason Schiller: What we came up with was be a not-for profit or non-profit and have a substantial portion of your staff be volunteer.
Paul Andersen: I think 100 percent, wasn't it?
Jason Schiller: No, the definition that we discussed at the table.
Paul Andersen: Oh, at the table. My apologies.
Unidentified: To modify.
Paul Andersen: To modify. Got it.
Jason Schiller: I'll repeat it again. So it's be a non-profit or not-for-profit and have a substantial portion of your staff be volunteer. That's where we stand at the moment.
Paul Andersen: For a definition. Are there others at a mic that are wishing to speak about a community network? I see one at the rear. Otherwise, move on to the next topic. Rear microphone, then we move on to the next topic.
Joe Olivieri: Joe Olivieri, Root Level Tech. Can we define a substantial amount as a percentage? 51 percent? 76 percent? I think it would probably be helpful in clarifying that.
Paul Andersen: Sure. We aren't going to come to a conclusion today. We're just taking ideas, and hopefully then somebody in this room will take it upon themselves to submit a policy proposal.
Jason Schiller: Yeah, we actually discussed a specific number. We felt it wasn't proper to actually define it, but people tossed around even below 50 percent would be enough. So probably on the lower side, but we didn't think that we should specify a number.
Paul Andersen: Okay. Closing this topic. If you're not -- I'm going to go to that next, but I don't believe she wanted to talk on community networks. I just want to close off community networks.
Far microphone. My apologies for not noticing you initially.
Roxanne John: No problem. Roxanne John, Government St. Vincent and the Grenadines. I must first commend ARIN for such an organized meeting. As a newcomer, I learned a lot. Of course, not everything in detail, but I think it was a structure that allowed knowledge.
As I saw the presentation with regards to the IPv6 update, and I can't recall seeing any Caribbean country on the list. So, of course, ARIN on the Road in the Caribbean will be welcome.
Paul Andersen: I will be sending Susan your way very shortly. We have been trying to do as much outreach in the Caribbean as well. We want to make sure we get to the entire region.
I'll go to that microphone next.
Marc Lindsey: Marc Lindsey, Avenue4. I wanted to follow up on a point I made earlier about the need for RSA and the connection of 8.2s and how that might correlate to registry accuracy. I think Leslie pointed out a lot of reasons why POCs might be inaccurate, ORG IDs might be inaccurate.
I don't mean to comment on all of that, but I do think a material portion of that are organizations that are active, using their networks for what they're supposed to be using them for, they've gone through years of corporate change and that they are intimidated by the process of joining ARIN through the current 8.2 process.
And a part of the language we talked about in the earlier proposal, eliminating the overhang of potentially revocation, that's gone. It's great. I think that's a good portion of it.
I do think the RSA itself, for an organization who merely just wants to update the records for the benefit of the community and not just its own benefits, is a heavy lift when an organization has to look at that contract and, say, have a lawyer in house or outside advise them and say, what does this look like? Is this a reasonable risk for us to take? And what are the benefits?
And many, many corporations who are simply looking to update their records to reflect the current ownership structure of their companies will reject that and say the benefits of updating the registry to show me as the current parent company, business unit that's no longer around, I'm still fundamentally using it, there's no one who's hijacking it, I'll opt out of signing the RSA.
Now, I want to back up. I think ARIN did a great job back in 2015 soliciting comments from a lot of the community to update the RSA. So it's a much better RSA than it used to be.
There's still some issues that John and I have been back and forth on about the RSA. I'm not going to do an issues list description on this microphone, but if anybody wants to talk about what those specific issues are from a company's perspective, who is potentially considering entering an RSA in the context of 8.2, let me know.
Now, I will also say that my interpretation of this is driven by the fact that I believe the way it works now, company has legacy address space. They go through an 8.2. It gets washed over and becomes a regular set of IP addresses. It no longer qualifies as legacy address space. So the RSA would operate on them like they are a regular number holder after they've gone through an 8.2 process for the benefit of updating the registry for the community.
So that implication, and along with what that means to changing their rights portfolio, is meaningful to many companies. You can agree or disagree as to whether that's correct, but it is definitively shaping the behavior of many companies who choose not to go through 8.2.
Paul Andersen: So I just think my one general comment on RSA would be, obviously, one of the Board's key roles on the executive team is to manage risk from our side of that, and that's where we've come.
Having said that, as you noted, we've been evolving the RSA based on feedback. We encourage you and anybody else who has feedback on how we can make the RSA better for both sides. I don't know, John, if you want to address any of the specifics of this concern on executing on a change for a legacy owner.
John Curran: As you noted, we did a major push in 2015 to harmonize the RSAs. So now the legacy RSA and the RSA are the same document. We've removed, to the vast extent, the revocation for lack of use.
And so there may be -- and we actually made very clear the rights that are provided, okay? And we've put in durable terms so that we can't arbitrarily change the agreement without going to the community.
So it is true that someone looking at the most recent RSA could say, given the rights you're giving me and given whatever residual risk there is, I don't consider it a fair tradeoff. That's possible. But I will say that a lot of the risks that people were dealing about, a lot of the concerns that people had don't exist in the present RSA.
And I recommend, if people are concerned one way or another, a legacy holder, that look at the current one, and if there's a problem, let us know. We're happy to hear.
Paul Andersen: Let us know.
Marc Lindsey: We talked about that. I'll definitely take you up on that. There's some lingering things that I will point out to you guys again.
But I also think it ought to be considered -- I know there's a certain position the Board has taken. It ought to be considered as to whether a full RSA is the right vehicle to protect ARIN to get the benefits of legacy holders coming up and getting the M&A updates to the record.
The RSA contract as it is today, and all the things that are there, is that the only choice that should be presented to companies who are coming forward and saying, I want to do an 8.2, just so that you now know who the right company is and I have right POC information for the benefit of me, but also, more importantly, for the benefit of everyone else and not just me.
Paul Andersen: So you're proposing that perhaps legacy holders sign a different document that's not the RSA but some other agreement?
Marc Lindsey: Yes.
John Curran: Now, we worked so hard to bring everyone to the same document and the same rights.
Paul Andersen: I wasn't saying we should do it.
John Curran: If you think the RSA needs to become a lighter RSA for everyone -- because the legacy holders also get significant benefit by doing so. Right now legacy holders get the old services. Legacy holders don't get, for example, RPKI. Legacy holders don't necessarily get the advantage of any new services we do. And, by the way, legacy holders don't know whether or not those services they presently enjoy will be continued ad infinitum. So there's consideration that they receive.
If you want to recommend that the RSA get lighter for all parties, okay, then I think that's particularly important to do. Separating them is a really interesting tradeoff. Right now the community is working towards one track, and, by the way, for everyone with v6, they're all on the same track. So this problem does go away with time between v6 and transfers of v4 because every transfer ends up under RSA.
I'm not sure how much work we want to do to create a special case, having just gotten rid of all of our special cases.
Paul Andersen: Okay. Quick response.
Marc Lindsey: So I'll try to be quick, but I can't help it. So I do think the point is is the priority in preserving a consistent contractual framework across all legacy holders? Is the priority minimizing the barrier for legacy holders to come forward and update the registry database to be accurate for the broader community?
Secondly, in the mode of incrementalism, I think it would also help a portion of those folks who are recalcitrant to say we're going to treat 8.2s -- if they're a legacy holder, we're not going to scrub them and make them non-legacy anymore. I'm going to at least get the benefits of the legacy RSA if my current address space, by the company that I acquired was legacy, why can't I continue to enjoy that status and at least get the slightly enhanced benefits of a legacy address space as opposed to non-legacy space?
Paul Andersen: Okay. Thank you for the feedback. I think, as John said, we've been trying -- trying to keep it as a single document, but if we can at least understand the provisions that are causing angst, we can try to see if there's ways to resolve it.
On the RSA issue?
David Farmer: Yeah. David Farmer, University of Minnesota, ARIN AC. Brought up was risks associated with an organization that might want to sign the RSA. I want to counter that organizations exist continuing to -- resources for organizations that are worth billions of dollars, not having a contract, you might want to talk to your corporate counsel about whether that's a really good idea or not.
And I will just say that I have found that many corporate counsels think it might be a good idea to have a modern contract for the resources for a multibillion dollar organization.
Paul Andersen: Thank you. Any other comments on this topic quickly?
If not, front microphone. Thank you for your patience.
Owen DeLong: Owen DeLong, speaking strictly for myself in this particular case. The fine folks in the EU have decided -- and this is kind of a heads up -- that they want to enhance the data security of their citizens, and they have passed a rather lengthy 200-plus page piece of law, regulation, whatever combination of the above it is, called the General Data Protection Regulation.
Paul Andersen: Regulation, yeah.
Owen DeLong: There is a U.S./E.U. compact that comes alongside that that says, if you are an American company and you are collecting European citizens' data, people in the E.U. can sue you for not following the GDPR and make it stick, and the U.S. will cooperate in this.
As a result, if you have European customers, you may want to compare the GDPR to the things you're required to do under ARIN policy for Whois and consider the fact that, in my opinion, there are some significant mismatches that need to be addressed somehow.
Paul Andersen: So it's not the first time we've run into issues like this. Canadian PIPEDA was obviously.
John Curran: Canadians.
Paul Andersen: Yeah, Canadians and our privacy. We're crazy folks. I don't know if you have much comment on this one.
John Curran: We have looked at it once. Recognize that our target service area doesn't directly overlap with the -- with having customers there, though we can end up with them incidentally.
When you look at all the transactions that can happen, sometimes companies do weird things. If we're faced with updating the records or not, we could end up with a party that is now a European entity even though it's using resources in the ARIN registry.
So we have paid some attention to this. It's not a direct threat. It is something that is more likely to have operational issues for ARIN, having to do with some data privacy handling and data -- data policies that aren't clearly communicated right now on the web site.
Regarding the policy implications, if you think there's policy implications that require changing ARIN's Number Resource Policy Manual, there are members of the ARIN AC here, and you should suggest that to them. But that's entirely within the realm of policy.
Paul Andersen: Front microphone.
Jose de La Cruz: Hi, Jose de La Cruz, Internet Society Puerto Rico, also an ARIN Fellow. I'd like to thank ARIN for bringing me here. When she said bring ARIN on the Road to the Caribbean, there's gonna be an OTR event in August in San Juan. So I think we are also part of the Caribbean. You can come over to San Juan and be with me for the ARIN on the Road event. Okay? So thank you very much.
Paul Andersen: Thank you very much for that. Thank you for your participation in the program.
It's almost closing time for the microphones as I try to find new words to say.
Chris Woodfield: I'll try to make it short.
Paul Andersen: Actually, we're only technically seven minutes into the allotted time for open microphone because the previous two items. But I have no problem leaving early. But having said that, I would just like to give fair warning that we will close the microphones if you don't start moving quickly. So.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I recently read of a situation of a recipient of a transfer block -- I think this made the NANOG list -- who discovered that the block wasn't usable. He did all the vetting you would expect an address -- a purchaser of IP address space to do. Didn't show up on any public blacklists.
Some conversation around that led to my thinking of a potential catch-22 that I wanted to ask about, if it's a real situation, or am I just thinking up theoretical situations, of someone who has acquired a block of address space that they cannot use due to the quality of the block, to use that term.
Now, I understand that ARIN has -- for very good reasons makes no warranties as to the usability of any space that is acquired or transferred. However, if you have address space that you can't use for whatever reason, if you want to get more space, don't you have to show usage of the space you've been allocated? And what happens if you can't do that?
Paul Andersen: I will feed that to John, and I think I see Geoff also trying to interject.
John Curran: I don't have a specific response.
Paul Andersen: John, go quick, then Geoff.
John Curran: So we have an absolute non-win situation here. So we don't control routing or abuse filters. Both of those are out there in the Internet somewhere.
Chris Woodfield: Right, and that's understood.
John Curran: So while we do look at these things very carefully and they are part of our processes, we do try to minimize -- if we know a block has impacts, we will try to not issue it, give it time to calm down, there's hold periods. But at the end of the day, when one party does a transfer to the other and they come to us and say we'd like to change these rights, we try to process that.
So the problem we face is this. It's not really our problem. It's the problem of the people who maintain the abuse lists. Geoff, a wonderful, nasty spammer, has rights to an address block.
Geoff Huston: It's a living.
John Curran: Having made his money, his list is blocked on many, many abuse lists. He sells it to his evil twin Geoffrey. Okay? And if we actually report that this block has changed hands, could be Geoffrey has a different name and a different organization. The problem is, if the abuse people actually do remove it from the filters, it can be the same principal hiding behind the scenes.
Now, in most worlds, they deal with this because the first time he did bad, he was pursued and arrested, okay? So the second time, he's not out there to do this and do this whitewashing because we have things like law enforcement, recourse of courts, and all those other things that the real world deals with.
Since the Internet doesn't do that and instead pretends it's its own space with its own enforcement, some of these problems are completely unsolvable. That's one of them.
Geoff Huston: Some additional data on this that we found, having been given Net One from IANA and allocating it out --
Paul Andersen: Did you discover it between your spam runs?
Geoff Huston: Between the spam bots, there are some addresses that are unusable because of the sheer volume of incoming. We did not allocate -- I think it's 12 /24s for that very reason, that they were unusable.
But all the rest that were allocated, it's buyer beware from then on after. We're not going to take any back consequently. Those 12 /24s are still incredibly noisy. They are unusable. They're not going anywhere. But as John has said, once it goes out, it goes out as far as we're concerned as well.
But it's a big lesson for buyers. If you really want to be sure about what you're getting, maybe you should advertise the intended block and see exactly what kind of attracter it is to incoming noise.
Paul Andersen: Take it for a test run. I don't know if this addressed his original question, which I thought was a policy question, then when he goes to get more space, he's going to have a qualification problem. I do listen to the questions.
John Curran: We don't have space to give out anymore. So it doesn't matter.
Geoff Huston: Does incoming traffic count as use?
David Farmer: Just to clarify, David Farmer, University of Minnesota, ARIN AC. I don't think the question was can ARIN give you more space; it's can you get another transfer? You bought from evil transferrer 1 and learned your lesson. Can you buy from -- will you qualify to buy from evil transferrer 2 or good transferrer 2?
Paul Andersen: Good transferrer 2, because the problem is you haven't used the address space because it's unusable.
John Curran: You have effectively put yourself down the end of a one-way street, which is a dead end. I'm very sorry. Currently, the policies, as ARIN has them, doesn't allow a way out of that.
Paul Andersen: So this does raise interesting questions for the AC and potentially staff on whether or not there's a gap here. I don't think it's something we've hit yet on a regular basis. And, as you say, it may have been a bit of a hypothetical.
Kevin Blumberg wishes to speak on this topic.
Kevin Blumberg: Kevin Blumberg, The Wire. On a humorous side, you could give back seven /24s to IANA and fix the other problem.
Kevin Blumberg: But, in all seriousness, years ago -- this is not a new problem. 69.x was a swamp space of unroutable for many years until a big provider started using it, and suddenly everybody wanted to make sure it worked.
So one of the options is to give that space or loan that space off to somebody who can get it cleaned out for you fairly quickly. Incredibly, when webcast or whatever might need to be available to the world, that space will suddenly get fixed up.
Paul Andersen: Andrew, I guess you've recanted on that. All right. Unless there's anything else on this topic, we'll move to the next microphone. Front microphone, then back.
Brent McIntosh: Brent McIntosh, Cable and Wireless, Grenada. I'm also a first time Fellow from the Caribbean. I just want to emphasize the importance of understanding policy and how ARIN impacts business organizations.
Also, having to review and look at my own local WhoWas, I've discovered there are two resources that we need to recover in our organization. ARIN is actually going to make back the money that it spent to get me here because of the back payments. So I am going to reapply for that.
Again, I just want to say thanks. This was an excellent experience for me.
John Curran: Thank you very much. We hope we'll see you again in the future.
If we don't see anyone moving to the mic, this will be the last comment at the rear microphone.
Scott Sullivan: So Scott, part of the NARALO GA. Just an appreciation for the small things. The technical staff out front, available to help, meant I recovered my ARIN account, fixed six-year-old stale records that were incorrect, and got my name off an ISP I haven't worked with in six years.
Scott Sullivan: So thank you.
Paul Andersen: Thank you very much to our staff as well who do a great job on that, and just the meetings and all that. John wanted to get in next.
John Curran: Just one thing.
Paul Andersen: He did get in before you got to the microphone.
John Curran: For those people who have projects they'd like ARIN to fund, if you go to About Us and you go to Corporate Documents, you'll see a process for funding ARIN external projects and entities. It says sort of what I said. It says please direct your funding request to the ARIN staff at info@ARIN, and we consider this in waves.
People who have projects who want to submit them, on the ARIN web site, there's a process. Feel free to follow that. Thank you.
Cathy Aronson: Hi, Cathy Aronson. He's not in the room, but I'm still going to do this. For those of you who don't know, a really active member of our community is changing from the FBI to the civil society, and he'll not be participating as actively or at all in the process of, basically, representing law enforcement here in this forum, and I just want to thank Bobby Flaim for all the hard work.
Paul Andersen: Yes, thank you, Bobby, for all that you've done for many, many years in this community. If you see him outside on the street, buy him a drink.
Cathy Aronson: Or if you want his email.
Paul Andersen: Rear microphone, then front microphone.
Elvis Velea: Hi, Elvis Velea, V4Escrow. While working on some slides for a future presentation, I've noticed some inaccuracies in how ARIN presented some of the transfers, and I've actually presented this to ARIN, and I would like to thank the staff that immediately fixed this overnight. So thank you very much.
Paul Andersen: Last comment before we break on what looks like a lovely day.
Alfredo Calderon: I'm Alfredo Calderon from ISOC Puerto Rico, a Fellow also. So I'm here on behalf -- thanks to Susan and her staff and the committee that selected me to come again to an ARIN meeting.
I just wanted to make a couple of announcements, if I can. Two of my colleagues already mentioned that we're going to have in Puerto Rico an ARIN on the Road on August 25th.
The other thing is that next year, from March the 7th to the 9th, before the ICANN 61 meeting, we're going to have the first North American School of Internet Governance. So you are all invited to apply when the time comes, and if you're selected, well, we'll receive you gratefully in Puerto Rico, and we'll share a lot of experiences there. Thank you.
Paul Andersen: Thank you very much.
Paul Andersen: So we will now close the open microphone. Just a reminder, we have another one at the end of tomorrow's Members Meeting. With that, I'll let John finish it off.
Closing Announcements & Adjournment
John Curran: Thank you, Paul. Okay. It's the end of the day, and we're almost done. Closing announcements.
I'd like to thank our network sponsors. Cox.
John Curran: Thanks for our webcast sponsor, Google.
John Curran: And our break sponsor, Avenue4.
John Curran: Okay. The policy discussion breakout room is migrating. It's moving from one room to the other. So tomorrow if you have a chance -- if you're busy talking to people about community network policies or fixing people who have dirty address blocks and have new need and you want to get together with other people, we do have a policy breakout room for you to meet in. It's going to be in the Orleans Room tomorrow. So that's right behind the meeting desk.
Don't forget the meeting survey. It's online there, surveymonkey/r/ARIN39survey. We'll also send you an email with the link. We will be giving out an Apple iPad to someone who completes it. Without an IP address. You have to get that from your provider.
John Curran: Tomorrow we have breakfast at 8:00 a.m. Members Meeting 9:00 to noon. This is when we give all the reports of all the departments, the Board of Trustees, the Advisory Council. Everyone is welcome. You don't have to be an ARIN member to attend. Feel free if you want to know how we run the organization. Meeting materials, of course, are online.
And then that's it. You're all done. We'll see you tomorrow. Thank you.
(Meeting adjourned at 4:40 p.m.)