Table of Contents
- Opening Announcements
- NRO Activities Report
- NRO NC Report
- Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers
- Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks
- RIPE NCC Update
- LACNIC Update
- APNIC Update
- AFRINIC Update
- Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
- IANA Update
- IANA Transition Panel
- Policy Simplification
- Software Development Update
- Open Microphone
- Closing Announcements and Adjournment
John Curran: Good morning. If people will come in and be seated, we will get started. Okay.
Welcome back. Glad to have everyone this morning here at our wonderful ARIN 37 meeting in Montego Bay. I'm John Curran, President and CEO of ARIN.
We're going to start on another day of policy discussions, also have a number of updates coming up.
Also, for the people who are out there, Jamaica is boring. There's no beautiful beaches, no wonderful barbecue. You're not missing anything, but we do welcome you back to our policy discussions.
It was actually incredible last night. Quite an event. So for those of you who are remote, we have a webcast, live transcript, downloadable meeting materials and the online chat room for your participation.
I'd like to thank our sponsors, network sponsor C&W Business and webcast sponsor Google.
John Curran: Very good. And rules and reminders: We're trying to get something done here. This is part of our Policy Development Process. It's fairly important. We want to make sure everyone has a chance to speak if you have a view.
And please be clear. State your name and affiliation when you're at the microphone. There's a list of courtesies in your program if you have any questions.
So today's agenda: The NRO Activities Report. The Number Resource Organization is the NRO, and will give their activities report. The NRO Number Council, which is the elected body that has three representatives from each region, they'll give their report.
We'll then resume the policy discussions with Draft Policy ARIN 2015-7: Simplified requirements for demonstrated need for IPv4 transfers, and with Draft Policy 2015-9, eliminating needs-based evaluation for Section 8.2, 8.3 transfers of IPv4 blocks.
Then we'll go into global reports. We'll hear reports from the other RIRs and also the IANA. Should be an interesting day.
We have another policy, the ARIN-2016-1 Reserved Pool Transfer Policy. We have a discussion about the IANA stewardship transition. We'll have a panel discussion where we'll talk about what's happening in that.
We'll have a panel -- I guess a panel discussion. Or single discussion? Kevin, what's the policy simplification, one person or a panel? Panel.
Kevin Blumberg: Panel of one.
John Curran: We'll have a discussion about policy simplification.
As people may have noticed, our Number Resource Policy Manual is interesting. Colorful, full, full of stuff, and potentially it could be less full of stuff and still be as effective.
Then we'll have an open microphone session. To the extent that you have an issue that hasn't come up that you'd like to raise, this would be a good time to do in front of the staff and the community and Board, and we'll take questions.
And then tonight we actually have a happy hour from 5 to 6 at the Royal Pavilion. Same place as Sunday night's happy hour. Join us before you head out for your own dinner. Wear your name badge, very useful. It should be a wonderful day, nice event, and then you're on your own for this evening.
So at the head table we have Vint Cerf, Chairman; Paul Andersen, Vice chair; we have Daniel Alexander, the Chair of the ARIN Advisory Council; Kevin Blumberg, who is the Vice chair; and we have Chris Tacit, who is our Jabber scribe. I always forget one. I just draw a blank.
Let's start in. We'll have the NRO Activities Report. The NRO has an Executive Council which is made up of the executives from each of the RIRs. I'm the representative from ARIN. And then usually the Chair of the NRO would give the update. But the Chair is Oscar. Oscar is in preparation for his upcoming LACNIC meeting, and so the task falls to me. So I'll give the NRO Update.
NRO Activities Report
John Curran: What is the NRO? Flagship and global leader for collaborative Internet number resource management as a central element of an open, stable and secure Internet. We basically coordinate collectively the activities of the RIR to give a nice, stable number system. That generally works.
So we have -- I'm going to go through that, our key focus areas, talk about our financials, talk about the activities, specific activities we've been doing, and then take any questions.
We're incorporated. Not incorporated, we're unincorporated, but we were formed by an MoU in 2003. And it's just an agreement that says how the RIRs work together. And, again, it's to provide a coordinated number system.
When someone has a question about the Internet number registry, they can go to the local RIR. But a lot of times you'll get a question from an international organization, they want to hear a voice that represents the full number registry system.
So it's a focal point for queries about the Internet number registry.
And we contribute to global discussions when someone's looking for an opinion on how something affects the number registry. We often will prepare a piece and file it.
So the executive committee, as I said, is made up of the five CEOs or executive directors. Oscar Robles is LACNIC and chair. I'm the secretary. Paul Wilson, treasurer. Alan Barrett and Axel Pawlik are also on the executive committee. The roles rotate every year. So you get to -- each RIR takes a different task. The secretariat function is hosted by LACNIC. We have an executive secretary, German, who handles all the things keeping us running smoothly. We have coordination groups, which people don't really know. We don't talk much externally about them.
But the respective communication teams, the public affairs teams, the engineering teams and the resource managers, the leaders of those teams from each of the RIRs get together to talk about joint activities.
So, for example, the engineering teams, as you might imagine, spends time talking about things like RPKI and the registration service managers spend time talking about things like joint stats and transfers. When they're done talking about transfers, the engineering team gets to talk about transfers some more. And so it's how we coordinate activities, because it is one registry, even though there's five RIRs.
So the NRO finances, we do have some expenses that we identify as NRO expenses. Travel for the chair of our Advisory Council, which we'll talk about, and the chair, the executive secretary is an NRO expense.
Communications specific to the NRO, our website. IGF, the NRO contributes jointly on behalf of the five RIRs for IGF, the Internet Governance Forum. We contribute to ICANN. We've contributed $823,000 per year every year since ICANN's inception. So that contribution is a joint contribution on behalf of the RIRs that comes from the NRO.
These expenses are budgeted and then proportioned out based on the size of the RIRs, measured in Registration Services revenue. So each RIR pays a prorated portion of that. The RIRs also have pledged funds to be available for registry stability. We've jointly -- each RIR has made a pledge of a certain amount. Jointly we have over $2.1 million. We all hold those funds. They're in our reserves. But they're pledged in case one of the RIRs were to come into some catastrophic circumstance that would represent a disruption and very quickly need support. We've pledged financial support. We've also pledged obviously staff and engineering support as necessary.
So, again, even though we're -- the advantage of five organizations is that we're resilient. We'll make sure that the system keeps running even if one of us were to run into a problem.
Couple things we do. We produce the global Internet Number Status Report, which Leslie gave yesterday. That's how we co-join all the statistics and make sure we have information on the entire number registry.
We do a comparative policy overview. This is an interesting one. If you're interested in -- and Einar touched on this, because this is one of the more interesting things that's developed. If you're interested in what the policies are for what we're talking about in ARIN in the other regions, you can look up by area -- v4, v6, assignments, allocations, transfers -- and see how the other four RIRs do their policy.
That's sometimes useful. We all have our own communities. We all develop our own policies. There's no requirement for regional policies to line up. But we should not hesitate to borrow good ideas if someone else has got theirs first. So we do a comparative policy review, comparative policy matrix so people can look at the differences.
We have a governance matrix. We've actually compared the governance frameworks of the RIRs -- information on the bylaws, use of Whois, disputes, budget practices, et cetera -- and put that up for people who want to see how the RIRs are administered.
And, again, the same thing. So you can see best practices. So we can inform each other. We're working right now on an RIR accountability process. We've actually had each RIR has hired an independent law firm to go out and look at its governing documents, its structure, try to figure out how to ensure that we're accountable to the members. We're not subject to being captured by a party of disproportionate interest. And so that's an ongoing activity right now. We hope to do a public report of those results sometime later this year.
So IANA Stewardship Transition. The CRISP team. I'll talk about it on the panel later, but I'll do briefly -- wow, time flies. In 2014, the US government indicated its willingness to transition the stewardship for the IANA registries, okay -- the DNS root zone, the protocol parameter registries and the number registries -- to the global Internet community.
As part of this, obviously, worried about -- we have to concern ourselves about how the responsibility for the global number registries are administered.
And people, a lot of people sort of misunderstood the stewardship transition. I saw probably 200 headlines that say US government's planning on giving it all to ICANN. That's not what they said. They said they're giving it to the global community and they want ICANN to facilitate the process.
So since 2014 we've been going through a process. In the numbers community, we actually formed something called the CRISP team, the Consolidated RIR IANA Stewardship Proposal team, to come up with our proposal on how numbers, the stewardship for the numbers should be handled. And the act of stewardship in this case predominantly means making sure someone is doing the IANA registry function.
So right now the US government asserts it's the steward. It has an NTIA contract with ICANN, and it's saying someone else needs to be the steward. So someone else needs to have a contract for IANA functions.
So the CRISP team put together a proposal, and that proposal indicated that the five RIRs jointly would contract for an IANA operator, and we'll talk about this in some detail. The proposal also talked about many other aspects, intellectual property and how reviews were handled. We submitted the CRISP team proposal by the deadline, January 15th, 2015. The IETF did the same thing, submitted its proposal.
And then the names community was a little late. And the names community is late because it is a names community that's helped coordinate, be coordinated via ICANN, but ICANN is also the body that's doing the IANA function, and ICANN is also at times an oversight body for various functions for global registries. And so when you have ICANN doing all those things, coming up with a plan is hard.
In any case, we did our plan. The IETF did their plan. The names community got their plan done and their plan required some ICANN improvements in the bylaws. All of that gave us an extended game.
And actually all of that is finishing up. We'll talk about that in a panel this afternoon. But the CRISP team did its job and was finished predominantly in January 2015. It's hung around just in case there's been any questions.
But this was a successful joint planning activity of the RIRs that the NRO helped coordinate. It's going to result in Service Level Agreement. And that's online. I'm going to talk about that for an hour later on today. So we're going to skip that.
The group in the names community realized they needed to change parts of ICANN's structure, and they came up with a cross-community working group on ICANN accountability. And we actually, because of the way ICANN structured that cross-community group, included people not just from the names community but from, for example, the numbers community and the IETF.
And so we appointed -- the RIRs jointly appointed RIR staff and ASO members to this role. And they've been helping with the accountability structure of ICANN because we don't want ICANN to become -- in the process of trying to become accountable to actually become unaccountable by accident or end up with a loophole in its changed bylaws.
This process we'll also talk about this afternoon, but suffice to say when someone says they need representation from the numbers community, they come to the NRO and we figure out how that will be staffed.
We participated in the 10th IGF in Brazil. We supported the IGF, the Internet Governance Forum. We have an informational booth. The IGF has a lot of people who need awareness about how the number registry works. A major function of the NRO to make sure we have information there.
That's the whirlwind tour of the Number Resource Organization. I guess I'll take questions now. We are going to have an NRO Number Council report that follows talking about things like global policy and ICANN Board appointments. But on the NRO, if there's any questions? Questions? Questions?
John Curran: Thank you. I will now ask John Sweeting to come up to give the NRO Number Council Report.
Within ICANN, the NRO is called the ASO. Within ICANN, the NRO Number Council is called the ASO AC. Just the terminology they use in ICANN.
This is John Sweeting, and he'll give the Number Council Report, which handles two particular functions within the ICANN community.
NRO NC Report
John Sweeting: Good morning, everyone. I'm glad John explained all that, because I think it's been like a year now, and I still don't really understand all that NRO versus ASO, Number Council versus Address Council and all that. But, with that, I'm going to be the one giving the report for the ASO Address Council.
Here's a quick slide on who we are, what we do, how we're organized. There is one mistake on this slide. The last --
Vint Cerf: A test to figure out whether we can see what it is.
John Sweeting: Where is it? Louie, where is the mistake on this slide? It's actually -- it's the term of office. I don't want to waste a whole lot of time. Term of office. That is actually the APNIC ASO AC members' term of office, because they were the last one to use the slide deck and I failed to catch that. So here in ARIN it's three years for the elected members and it's three years also for the appointed member.
What we do, we advise the ICANN Board, select ICANN Board members and select ICANN NomCom members. And we meet every month very early for Louie on the West Coast. I think he's either 4:00 or 5:00 each month.
Then there's some months where one of the regions failed to show up so we have to have an emergency meeting like the next week to get -- we don't have quorum unless we have one member from each one of the regions.
Moving right along. Here's the current members of the ASO Address Council. The ones important to you are ARIN, it's Jason Schiller -- by the way, happy birthday, Jason Schiller. You must be all of 28, 29 now.
John Sweeting: So some of the ASO AC activities. The meetings. Like I said, we have a scheduled meeting every first Wednesday of the month, and then the emergency meetings we have whenever there's a reason to have one.
And since the last ARIN meeting we've had six teleconferences and one emergency meeting. As I said, it was because one of the regions couldn't get in, it was difficulty with the communication system.
Okay. So some of the appointments that the ASO Address Council make. Hartmut is on the ICANN NomCom. We have two people that are on the ICANN CCWG Accountability. The CCWG Internet Governance, Dr. Ajay Kumar and Filiz. Dr. Kumar is also on the Drafting team for the generic top-level domain auctions proceeds. Fiona is on the Academy Working Group. And Filiz and Ricardo are co-chairs, along with Louie Lee, of the Address Council.
So one of the main things that the Address Council does is of course the global policy management. Global policy is when policy has gone through all five of the RIR policy procedures process and they're all in agreement and it's also followed the ICANN Policy Development Process, and it has to do with some -- an extern- -- either IANA or another external ICANN-related body to implement.
A couple of examples are global policies determine number allocation policy for requests that involve IANA and also specify regional number allocation policy.
And here's a little flow chart. Each reach has its own -- they have to go through each region -- process. It's open, transparent, and bottom-up. Submitted in all five regions and they all agree, and it gets forwarded by the -- the NRO does their review and forwards it on to ICANN. Currently there are no Global Policy Proposals going through the process.
Another very important task for the Address Council is assigning board members -- the ICANN Board members to Seat 9 and Seat 10. Last year Ron da Silva was -- I don't know, Ron, are you in? There you are. He was assigned last year, so he's on a three-year term that started in October, right after the October meeting, the ICANN meeting. This year we're currently going through the process to select Seat 10. We had five candidates originally.
One withdrew from consideration prior to the face-to-face interviews we conducted in Morocco at the ICANN meeting. So I'll go on to the next slide because that kind of shows where we are in this process.
So the comment slide -- the comment phase of it, where you can go in and put comments endorsing whichever candidate you feel you would like to endorse, that was from 8 January to last week, last Thursday. So that has now closed.
The interview phase has been completed, and we're now into the selection process, which we started talking about last week, and it runs Through 29 April. The due diligence review will be held from 30 April to 13 June, and then there should be an announcement somewhere around June.
Now, during that due diligence, that's when the Address Council will vote, make our vote known, forward it to I believe the ICANN Board for their acceptance, and then they do some more due diligence and make sure everything's kosher before it gets announced.
If you're interested in other activities of the ASO Address Council, you can go look at this URL here. And that would be it. Any questions?
Louie Lee: Hi, Louie Lee, chair of the Address Council. I just want to invite the community again to comment on our Board candidates, and if you don't want to do so publicly, we are here to also accept private comments. But obviously the public comments will get your input in firsthand to all the members rather than having it relayed secondhand.
John Curran: Thank you, Louie.
Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers
John Curran: We are right on time. We're now going to go into our policy block. We're going to handle a few policies. The first one is ARIN policy -- Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers.
Because this is a Draft Policy, there's no staff introduction to it at this time. So I'd like to ask Rob Seastrom of the AC to come up and give the presentation.
Rob Seastrom: No, I'm not trying to trip and go to the hospital at another meeting yet again.
So problem statement for 2015-7 is the ARIN transfer policy inherits the demonstrated need requirement for IPv4 transfers from Section 4. And because we wrote this back when there was a free pool, it's more complicated than it's really necessary to be right now. So this is a proposal to simplify the assessment process for 8.3.
The policy statement is to add a section, Section 8.1, and the actual text is: IPv4 transfer recipients must demonstrate (and an officer of the requesting organization must attest) that they will use at least 50 percent of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months. Organizations that do not meet the simplified criteria above may instead demonstrate the need for number resources using the criteria in Section 4 of the NRPM.
So we asked staff what they thought. Staff said they'd apply the policy language to 24-month needs assessments for 8.3 and 8.4 and preapproval. So in order for staff to verify the demonstrated need of 50 percent, the policy criteria in NRPM Section 4 would continue to be utilized.
Policy would allow organizations to qualify for a larger amount of v4 address space than they currently can. And this policy could be implemented as written.
There's an editorial comment from staff which was that the proposal is to stick this under 8.1. The staff, when implementing this revision to the NRPM, would actually duplicate it under 8.3 and 8.4, making them bullets 5 and bullet 8 respectively.
The lawyer says no material legal issue. The lawyer also says that it would be -- it would significantly lower the degree of utilization required and permit larger transfers.
So it's a bridge between a lighter needs-based structure and between where we currently are and the lighter needs-based structure.
The lawyer also had a comment. We don't have to resolve this now, but the -- whether we need to address whether ARIN is making clear whether an acquiring party taking appropriate advantage of such a policy change ought to have a corollary duty to disclose all addresses under their effective control.
Do you support this policy as written? And let's hear comments on the addition of a duty to disclose other number resources.
Paul Andersen: This is a Draft Policy, so we invite any feedback on the questions or just your view either on the problem statement or the policy. Too much dancing last night at the social? Not everyone is not quite there.
Vint Cerf: First of all, I just want to encourage you to say something because the AC is looking for feedback, and we need to know if you support this or not. So negative comments are usually the ones that drive people to the microphones, but let me encourage you to make a positive comment if you think this is the right thing to do so the AC will have some idea where to go with it. Thanks.
John Curran: I just want to pick up and clarify or elaborate on the counsel comment a little. It's quite simple. It's what the community wants. It's whether or not the community wants us to have organizations attest that they need these additional resources, X, or whether they want organizations to attest they have these resources, A, B, C, and they need additional resources X.
And it's not really -- it's not something that would necessarily be visible to the community, but it might improve the accuracy of the process, because someone who has to disclose the resources that they have control over will understand that we have a better understanding of their need even if we're not assessing it. It's completely up to the community.
So given this would be -- this change, if adopted, would represent a significant change, something that would strengthen it would be a duty to disclose all the number resources.
It's not required. The policy does not pose any legal challenge either way, but we offer that as something to consider. It falls far short of any need to justify usage. But that's the only reason I wanted to elaborate on it.
Paul Andersen: Thank you for elaborating on that. We'll go to the first microphone.
Alison Wood: Alison Wood from Oregon. I'm a Fellow. I'm wondering what your vessel of enforcement is and if that enforcement continues beyond the first 24 months, so is it reviewed in 48 months or five years, ten years, to see if they're still in use?
John Curran: So it's fairly straightforward. If we have a report that a party has fraudulently obtained number resources to invoke what's called NRPM Section 12, Resource Review, which does have us ask all the resources they have, all of the utilization of the same, in elaborate detail.
Providing fraudulent information to ARIN can result in resource revocation. However, if this was the policy that was adopted for transfers, we, in general, would not be following up on any of these unless we received a report that was credible that indicated there was a fraudulent transfer, that someone obtained number resources or transferred number resources based on incorrect information.
There would not be a default follow-up otherwise.
Paul Andersen: Does that address your comment?
Alison Wood: Yes. And I do support this.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. Opposed. We've been continuing to try and have different ways people have proposed chipping away at needs basis, and the community has repeatedly said, "No. Needs basis is good. We like it." There's no reason to get rid of it for transfers, and I think that's still the case.
There's no reason to be handing out resources to people that don't need them and reducing the barrier of deciding whether they need them or not from actual documentation to they claim they need them and they signed a piece of paper that said they claimed they need them or claimed they think they will need them within the next 24 months, maybe, is really not in the interests of the community, in my opinion.
Paul Andersen: Thank you. Did you want to respond? On the stage.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. In general, I do support this, but I just wanted to clarify. This is an "and" proposal; i.e., it will remove the other ways of doing it and everything will be based on this way of handling it. No?
Paul Andersen: Do you want to address that?
Kevin Blumberg: This proposal provides a proposal to the current, is what it says. That's a summary. Sorry. I was looking at the summary.
Scott Leibrand: Last paragraph on the slide there.
Kevin Blumberg: May use the criteria in Section 4, right. What I'm saying is the Section 8 criteria, which is 24 months, would that apply? You said now Section 4, does that mean three in 12 months or --
Scott Leibrand: Scott Leibrand, author of this proposal. The last paragraph on the slide deck here indicates if you do not qualify or wish to qualify for addresses under this simplified policy that you can instead use the same policy that is in force today.
That is, you can use the criteria in Section 4 and all the other stuff that's in Section 8 to qualify as you would do today.
Paul Andersen: John would like to comment.
John Curran: The challenge here is the simple categorization of is this an "and" proposal or an "or" proposal doesn't say enough to categorize it. What we're saying is that this adds an alternative way which may actually become the default way for qualifying. It doesn't add additional criteria, it adds an alternative criteria.
So either you attest that you will use 50 percent within 24 months. If you're unable to do that, then you fall back to the current practices.
Kevin Blumberg: Thank you, that's what I wanted --
Rob Seastrom: You said it doesn't sound like an "or" proposal. It sounds like an "or" proposal to me that you can either use the Section 4 criteria or you can use these new criteria. So what's the distinction?
John Curran: The phrase characterizing a piece of the NRPM as an "or" proposal or an "and" proposal is insufficiently precise to allow categorization. I don't object. I agree exactly with what you're saying. You're saying you shouldn't just say it's an "or" proposal or an "and" proposal, because some people think of an "or" proposal as I will do it this way or I'll do it this way and it's up to the staff as to how they qualify. I just think you should not simplify it that way; you should describe what it actually says.
What it actually says is you have an alternative. You can do A or B. Describe it in full.
Rob Seastrom: Thank you.
Paul Andersen: Let's go to the front microphone.
Alain Durand: Alain Durand, ICANN. Question to John. You say that the suggested additional wording from legal is to ask people to disclose all the other resources that they control. Could you explain what you mean by control? And, in particular, does this cover option contracts that they control?
John Curran: Because the policy text doesn't say anything regarding this, it would be what the community ends up putting in the text. You haven't given text.
We'll implement whatever the community says has to be disclosed.
Paul Andersen: Thank you. Quick check. Remote participation. Any? Doesn't look like it. Rear microphone.
Jason Schiller: Jason, Google, NRO AC. I have two topics I want to talk about. The first one is what we talked about one back, which is whether this is an "and" or "or" proposal. I'm very confused if the proposed text would replace the existing 8.1, or if the proposed text would replace 8.1, 8.2, 8.3, or if they would create a parallel structure, 9.1, 9.2, 9.3. Clarity on that might help us resolve understanding whether this is an "and" or an "or."
Rob Seastrom: If I can speak to that the third paragraph here, it's not actually replacing anything in 8.1. Staff said that they would add bullets in 8.3 and 8.4, listing this as a way that one could qualify for resources without preventing from using the existing language in Section 4.
Jason Schiller: Can we get the template wording updated to match the text on the slide? Because I don't see that in the proposal.
Rob Seastrom: Yes, we can certainly update the template wording. I think that that would be a matter of an editorial change. It wouldn't be a substantive change to the proposal.
Jason Schiller: And then my second topic, I wanted to follow up -- I'm sorry, Scott, did you want to respond to that?
Scott Leibrand: No.
Jason Schiller: Are you sure? My second topic was I wanted to follow up on Owen's comments about removal of need.
I don't think he really explained what he means by removal of need. I think what he means is a party who is doing a transfer can simply make a claim of what they think they might use in two years and get an officer to attest to it and it's done.
And there's really no verifiable proof or additional requirements that are really needed. So if an organization is willing to stretch the truth to the extent that they're willing to stretch the truth and have an officer sign off on it, they can circumvent need.
Paul Andersen: Owen, did you want to address that question?
Owen DeLong: Owen DeLong, Akamai, ARIN AC. What I meant was pretty close to what Jason said. But it doesn't even have to be an organization that's willing to stretch the truth.
It can be an organization with dreams of grandeur, and we think in the next 24 months we're going to sell 10 million cloud units and therefore we need a /8, and our officer will attest to the fact that in the next 24 months we expect to use half of a /8 in 12 of them or whatever the requirement is or 24 months.
Then they qualify for a /8. They can go out and waste their venture capital and buy a /8 and that goes off to a place that it doesn't get utilized. So that's what I mean.
Paul Andersen: One second. The AC chair would like to interject.
Dan Alexander: To play a little devil's advocate, I'm just curious. Should ARIN policy or our wording here try and really limit bad decisions? Agreed, that could happen, but at the same time they're paying a large amount of money for whatever the space is. How is us not doing this going to prevent something like that?
Owen DeLong: I'm not worried about preventing their bad decision. I'm worried about not handing over the addresses to someplace where they're actually not going to get utilized.
Paul Andersen: One second. R.S.
Rob Seastrom: I have a question for Owen which I'd like answered in four sentences or less because we can talk about this all afternoon.
What level of technical or business vetting do you believe is appropriate when someone comes to ARIN saying I want -- fill in the blank -- number resource?
Owen DeLong: I don't see a problem with the existing policies. I believe they're working just fine on that.
Rob Seastrom: Thank you.
Paul Andersen: Wait. Vint, did you still have a question?
Vint Cerf: Two things. First of all, no one is really perfect at predicting the future. So almost anyone could make a reasonable estimate and then turn out to be wrong. But I actually have a nit which I'd like some help with.
I'm looking at Section 4.3.3, Utilization Rate, and yesterday we talked about removing the 25 percent immediate utilization rate and left only the 50 percent utilization within one year.
If I've understood correctly, in this proposal you either say you could utilize 50 percent in 24 months or 50 percent in 12 months.
And so it's very funny to imagine that if you could -- if you couldn't satisfy 50 percent in 24 months, how could you satisfy 50 percent in 12?
John Curran: So recognize that this would be a criteria that's applied if someone wanted to and would have an officer attest to it, would be preemptive, if they qualified by this they'd be fine.
Otherwise they go back to Section 4. Now, Section 4 has end user and ISP and initial and additional allocations. You're looking at end user initial. You're looking at one of the four pieces.
So in that case, by the way, it is possible that someone may say I'm going to follow the normal process of NRPM 4 because I don't have an officer who I can reach who is willing to attest to this. He doesn't understand that. They would go through that process.
On the other hand, they may say I do have an officer who is willing to assess, I do want to get a block that's so large that I can only use 50 percent of it within 24 months and they could use the simplified process.
The simplified process would be what they'd use if they could. If not, they'd fall back to our current practices.
Vint Cerf: I'm just sitting here wondering whether we should hire an IRS attorney help us write these things.
Paul Andersen: Let's see if we can back this out. Owen, you got the response you need from that? Jason, did Owen address your comment?
Jason Schiller: Yes, and I'll save my other concerns.
Paul Andersen: Would you like to state your opinion on the policy at this time?
Jason Schiller: I'm all in favor of simplifying the policy. I get that small organizations are having a hard time getting through this policy, and it's daunting.
But I think this completely gives an end run around need, which is a bad thing when we're talking about a public good.
I suggested an alternate simplification back in January, which was show that what you're holding is currently 80 percent utilized, and then you can double within the next two years. And at any time you can again reshow 80 percent utilization and again double.
And I also suggested that we probably have to deal with the slow start case. And I threw out the idea of maybe your first 24 needs no justification. You can get a 24 holding nothing and then use it, show 80 percent, and then start doubling. And if your initial is more than a 24, you can do that under immediate need.
So I think that is a very easy policy that people can navigate and get through and is a better solution than this one. And, as such, I oppose the policy as written.
Paul Andersen: Thank you sir. Another five minutes for comments. I'd encourage you if you want to say something, because there's a bit of a lineup to get there. Again, I support or I'm against. You don't have to get into great reason. But important feedback. Chris, any remote participation? None at this time. Front microphone. Need a microphone there, Chris.
Chris Tacit: Christoph Blecker from the Walt Disney Company has a question: Would it be feasible for staff to do automatic follow-ups at the 24-month mark for people who take this option and if the resource holder isn't utilizing 50 percent, then work with them to remediate. Having this automatic follow-up may curb "delusions of grandeur" -- in quotes -- as renumbering would be a possible consequence.
This just came in literally while you asked me.
Paul Andersen: I sensed there were bits moving through the stream. John, comment.
John Curran: It's not presently in the policy proposal. But if were put in, staff would follow it.
Paul Andersen: Come back to the room, front microphone.
Chris Woodfield: Chris Woodfield, Twitter. I'm currently -- I'll admit to being more or less on the fence on the policy as written. The duty to -- addition of a duty to disclose clause, so that the calculation is done based on all space under an organization's control makes me slightly more comfortable with it, but, at the same time, the proposal that Jason mentioned does make a little bit more sense to me than this policy as written.
The question I came up here with was how does this -- does this policy, compared to the policies of other RIRs at this time -- I'll admit a lack of familiarity -- is this -- are other RIRs considering similar policies and will this put us more in sync with other RIRs or away from other RIR standards?
Paul Andersen: John.
John Curran: We actually have other RIR representatives, but I'll try to be brief. Transfers right now between parties in the RIPE region I don't believe have any constraints of need.
I would ask an APNIC -- is there someone from APNIC who would like to characterize your transfer policies? Interorganizational?
Paul Andersen: I know Adam is in the room. Adam at the rear, please.
Adam Gosling: Hi. Ours is probably similar to your Section 4, I was just going to try to check, but the demonstrated need is just the same demonstrated need that you would require getting from the free pool.
Paul Andersen: Thanks, Adam. Sorry to put on you the spot there.
John Curran: I'm unaware of interorganization -- Seun, do you want to talk about organizational transfer in the AFRINIC region?
Seun Ojedeji: Yeah, so this is Seun Ojedeji, chair, AFRINIC Policy Development Working Group. We do have a transfer policy currently under discussion. So we don't have any.
John Curran: And LACNIC, is there anyone? I guess RIPE, if you would like to get up. I paraphrased for you, but it would be good to hear.
Andrea Cima: Andrea Cima, RIPE NCC. You were correct, John. There's no needs justification needed in the RIPE region with regards to transfers.
Rob Seastrom: Thank you everyone who stepped up. That information is helpful.
Paul Andersen: Front microphone.
Sergio Rojas: Sergio Rojas from LACNIC. We don't have inter-RIR transfer in our region. We have two proposals, but they returned and remain to be discussed.
Paul Andersen: Thank you. Thank you to all the RIR staff for a little on-the-spot feedback.
If there's no further, we're going to go to rear microphone, please.
Charles Gucker: Charles Gucker, VMware. I support this policy as written.
Paul Andersen: Thank you. If you wish to comment on this proposal, we are now starting to get a bit closer to the end of our time, so I would urge you to approach a microphone with due haste. Front microphone.
John Springer: John Springer, ARIN AC. I'd like to point out this is a transfer policy, so by definition any addresses that are going to be handled by this policy are already not in use. So that the outcome of this policy, whatever it is, if it results in IP addresses being in use, it's a net gain of addresses in use.
And anybody that wants to oppose it needs to come up with other reasons why that's a bad idea. And so far I haven't seen any of those.
So at the moment I support the policy as written.
Paul Andersen: Thank you, John. Rear microphone.
Alan Barrett: Hello. This is Alan Barrett, CEO of AFRINIC. I'd like to expand on what Seun said minutes ago. The AFRINIC transfer policy is under discussion. We don't have one yet. And the proposal and the discussion is needs-based. But it talks about a 24-month window. So they must demonstrate a need to use it within 24 months.
Paul Andersen: Thank you for that.
David Huberman: David Huberman from Oracle. Let's talk about how policy works today, okay? ARIN thinks about IP addresses as aggregates because ARIN has a mission for both conservation and aggregation. Okay? We don't think about them in terms of 1 million IP addresses versus 1.1 million address. We think of them as /13, /11, and /12s. We think of them on CIDR boundaries.
And this is very important. Why? Because under existing policy, existing transfer policy, 8.3, it says you will use the requested IP addresses in 24 months. So if you request a /16, that says to ARIN staff you will use half of a /16 plus one or half of a 16 in 24 months, because anything more than that you needed a 16. If you don't use half, you could have gotten a 17. That's where the hard math falls that justifies a 16 as opposed to a 15.
This policy doesn't change that at all. This policy says you have to use 50 percent -- you'll attest, excuse me, that you'll use 50 percent within 24 months, which is no different than what you're doing today, which is essentially attesting that you'll use -- use it in 24 months. Those are the exact same things.
This policy doesn't operationally, from an ARIN standpoint, change the way need is evaluated. It just clarifies some text, and perhaps that's good.
Paul Andersen: In favor or against?
David Huberman: I'm a member of the AC. I will do as the community so gathers consensus on.
Paul Andersen: Perfect. Thank you.
John, did you want to --
John Curran: So in looking at the history of the policy proposal and the current text, I agree with Dave, it doesn't change the threshold. But our understanding of this policy proposal and what the staff assessment said is that we would accept any credible officer attestation as demonstrated need.
Now, that's a slightly different operational practice than what we presently do, where it's not just what an officer will attest, we'll actually ask for quite a bit of detail to get to our confidence level. And to some extent this transfers that responsibility to the requester to say they have an officer attesting that they will use that amount.
To be fair, it's impossible to demonstrate you will use a certain number of resources, because you can't demonstrate the future. If you could demonstrate the future, you would be picking lottery tickets. But you can't. So no one can conclusively say they can demonstrate this.
But with this policy, we would be accepting an organization's credible demonstration, credible plan for utilization with an officer attestation, and we would be accepting it based on the attestation at face value.
Paul Andersen: I'd like to add one more comment following up on David's comment just now, which is here in the future, in 2016, a shade under 600,000 routes in the default-free zone from where I sit with my underpowered personal routers, their memory constrained, aggregation is still a good idea.
Paul Andersen: Two comments in queue. We're getting to the end of our time. If you do have something you'd like to add, I encourage you to approach the mic so I can manage the time. Otherwise, let's go to our rear microphone.
Jason Schiller: Jason Schiller, Google, ASO AC. I have a hypothetical question to try and understand this policy better. I am a legacy holder of a /8 that hasn't been used for many years, and I suddenly have a new business plan for a cloud offering. And it's going to be really, really great, and we think in the next two years we're going to have at least 18 million customers. My current /8 is currently 0 percent utilized.
To make this work, I need more than that in addition to my currently held /8, which is 0 percent utilized. Can I get approval for an additional /8 that I'm going to buy on the market with my money and I pinkie-swear promise we really do think we're going to use it.
John Curran: Jason, did you write all that down and give it to us in a way that shows that you will use 51 percent within two years?
Jason Schiller: An officer attests to the fact that we think we're likely to have 18 million customers within the next two years.
John Curran: That would be approved, your transfer would be authorized.
Jason Schiller: Even though I have 0 percent utilization of what I'm currently holding?
John Curran: Again, if you can show a plan that shows that you'll have over 50 percent utilization and an officer attests to the fact that they believe that is correct, then you would be approved.
Jason Schiller: Thank you.
Paul Andersen: Thank you. The microphones will be closed at the end of the next intervention. So please approach a microphone if you would like to.
Kevin Blumberg: Kevin Blumberg. I'd like to get staff and legal to clarify one aspect. It's not only related to this policy. It's come up a number of times at the mic, and I think we'll save ourselves a lot of time dealing with explaining in the current RSA reclamation and the requirements when it comes to reclamation. Because we talk about all of these things and you will do this and you will do that. But if you don't do it, what is the bar that is set in terms of ARIN actually going to reclaim space?
John Curran: If you obtain space from ARIN, i.e., ARIN assigns space or allocates space to you from the ARIN free pool, whether it's v4, v6 or ASNs and you obtain that space and you do it via fraudulent means, you will almost certainly lose it at the -- when that's determined. Okay. That's reclamation.
If you have existing resources and you transfer those resources to another party and you engage in fraudulent means, we can't reclaim the address space because you didn't utilize it. A legacy holder in the RSA, or actually any holder in the RSA, you'll see there's a specific provision that says we do not reclaim for lack of utilization, period.
However, if you engage in a fraudulent communication with us, ARIN can pursue that and can reclaim based on your fraudulent behavior. So it's one thing to say I missed my business plan. Okay, you missed your business plan. Welcome to the world. A lot of people miss their business plans. We all have invested in companies that have. The fact is it happens.
However, there's a difference between I missed my business plan and I provided you fraudulent information. Based on fraudulent information, ARIN can reclaim number resources, legacy or non-legacy. Based on utilization, ARIN will not do a reclamation.
Paul Andersen: The microphones are closing.
Chris Tacit, is there anything in queue?
Chris Tacit: Nothing more.
Paul Andersen: Microphones are closed. Last comment is for Rob.
Rob Seastrom: Thank you. The AC will take feedback received from the community under advisement for our discussion. And if we make Jason's recommended pinkie-swear change to the -- codified in policy, you'll see this policy up here again since that's a substantive change.
Paul Andersen: Let's thank Rob for his presentation.
Andrew Dul: Can I ask for a poll of the room to provide to the AC on how just -- if they support or don't support the policy as currently written?
Paul Andersen: Well, the poll question I plan to ask is whether the room believes the Advisory Council should continue to work on this proposal. Does that suffice?
Andrew Dul: No, I actually want support or nonsupport of the policy as written.
Paul Andersen: That would normally not be done -- I will defer to the Advisory Council chair.
Dan Alexander: Your question.
Paul Andersen: So the AC chair would prefer I stick with the question as written.
I'm now going to first make sure the polling team is in position. I see the thumbs up.
Very much like yesterday, but just in case, if you can hear the sound of my voice, here in the room or in remote, you are entitled to participate on this should you so choose.
I will first ask for those in the room, for those who are in favor of the question, and then again. The question again is: Do you believe the Advisory Council should continue to work on this proposal?
All those in favor of the question, please raise your hands nice and high.
Milton Mueller: To continue working on it, does it mean that if this proposal is okay as it is, then we don't need to keep working on it, we just need to pass it? How would you vote on this?
Paul Andersen: Milton, I apologize. I think because we never use that mic, I couldn't hear a word you said. Would you mind running over to one of those? Or can we get the microphone in the front, please?
Milton Mueller: I think this one is on now. The question is if you believe that this -- if you support this policy as it is, do you vote yes or no on this question? You say don't work on it, continue -- don't continue working on it, just pass it, or are you saying continue working on it?
Paul Andersen: I think I'll let Dan, because they're -- the one who interprets feedback, so...
Dan Alexander: It's simply a binary question. If you think we should continue working on this, you both agree with this work moving forward and/or you agree with this text as it is and/or you would like this to move forward, any preference to the positive of this eventually becoming policy, you would raise your hand that we would continue to work on this.
If you don't think this is a good idea and you think things should remain as is or you would like the AC to potentially abandon this effort, you would say we would not want to continue working on this.
Paul Andersen: By the way, this highlights why we do encourage the microphone participation and why the question is, because the AC may choose to leave it as is and move it forward, or they may think it's on the right direction but needs tweaks. So that's the flexibility we try. So always encourage to get those comments in so that can be considered.
So dealing with that point of order, we will try that again. I apologize. I believe we have to recount that.
So, again, those in favor of the question please raise your hand nice and high. Keep it up for just a minute. You may lower your hands. Reminder for those online to vote as well.
Those opposed to the question, please raise your hand nice and high. Leave it raised. Just takes a second. We have to make sure. Thank you.
Just require a moment while we have the tabulations, because we also need to give a little bit of time for the remote participation, which not only takes a little longer, but the webcast unfortunately can sometimes have about a 30- to 60-second delay. So we just need to let them catch up to the future.
Vint Cerf: Excuse me, Paul. Just while we're waiting, I was reading this thing that said will you please disclose to us all of the address space we're using.
It reminds me of those insurance policies that say: Please tell us if you have some other insurance company that's covering this.
Paul Andersen: On that note, the envelope has been received. On the matter of 2015-7: Simplified requirements for demonstrated need, today we have 102 people in the room, three remote, so that's a total of 105. On the question of continuing work, 32 in favor, two against. This will be presented to the AC for their consideration, and we'll put it back to John. Thank you.
Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks
John Curran: Okay. That was an exciting kickoff. We now have a second policy to talk about. This is Draft Policy ARIN-2015-9: Eliminating Needs-Based Evaluation for Section 8.2, 8.3, and 8.4 Transfers of IPv4 Netblocks.
Should be similar to the last discussion but more of it. I'll have Leif Sawyer come on up.
Leif Sawyer: Good morning. So like the last one, this Draft Policy is all about eliminating or changing how we evaluate needs basis for transfers in Section 8. Quick disclaimer. We've not done a review by ARIN staff or legal.
The text for this policy proposal is in your Discussion Guide. I will not be presenting any of it here on the screen.
We have attempted to do multiple rewrites of this text to clean it up. That will not be shown, of course, in the Discussion Guide.
Simplified problem statement here: Of course, due to the NRPM Section 8 transfer restrictions, ARIN can't always accurately or promptly update the registry database because they don't always know what's going on behind closed doors. There's a perception that there are transfers happening without any -- without a transfer market or without ARIN involvement.
And so the database does not accurately reflect what's happening. A proposed solution is to eliminate all needs-based evaluation for transfers, thus allowing people to come in and say we made this transfer, please reflect it in the database. Now we know what's going on.
A lot of discussion on PPML last year and earlier this year. Very difficult to determine really what's going on. A lot of conversation, but not a lot of outright support or negative opposition.
But there's a lot of concern with eliminating needs-based criteria in the community, as we've heard on the last discussion. There is a perceived unfairness for the little guys who don't have the economic pocketbook, the large-sized pocketbooks to participate in this.
So in the post-IPv4 runout, how do we balance our competing goals in transfer policy -- resource conservation versus registration accuracy? Couple of things to think about here.
So a number of questions for you. How do we increase the participation of transferors and transferees such that we can keep the database up to date and does needs-based requirements actually result in a more timely update? Or does a relaxed-need, like Proposal No. 7, does that help? Or what Jason mentioned, /22 with no needs-based evaluation or a slightly different sliding scale?
And in a transfer-only market, what IP resources is ARIN conserving? And should the AC continue to work on the problem of database accuracy? So I encourage you to get up to the microphone and help further this discussion.
Paul Andersen: Thank you, Leif. The microphones are open.
So microphones are open. Please approach the microphone either online or here. The first interjection will be from John.
John Curran: Just a little terminology issue here. I actually think the registry is quite accurate. But there's a question of what people think the registry reflects. The registry reflects the party who has the exclusive use of the entry in the registry.
It does not reflect if you think it's a right to a routing table, none of you gave me the right to issue rights to your routing table. So there's no way an address block represents that.
All it is is the person who can update the block and who has the exclusive uniqueness of that block.
So when someone says the database isn't up to date, what they're saying is that somehow they bought something but they didn't actually get what is the IP address block. Because the IP address block is in the number registry system and that's in the ARIN registry.
I just want to be clear here. We have people who are leasing addresses and we have people who are doing options for addresses. But none of those change who has the rights and the title to the address block in the registry.
So if someone comes up to the mic and talks about accuracy, I'll respond each time, because I have to keep the discussion accurate.
Paul Andersen: Thank you for the clarifying comment. Let's go to the front microphone.
Scott Leibrand: Scott Leibrand, ARIN AC, co-author of the proposal. To John's point, the attempt to make the database more accurate is not that the database is incorrectly representing what it represents, it is instead -- the database is not being updated in a timely fashion by individuals who are engaging in economic transactions that will eventually result in transfers.
Those transfers should be represented in the database in a way that should be visible to the public. What we are basically asking here is should we attempt to solve the problem that counsel identified in the last proposal. Should we attempt to get organizations who control addresses in some way to update those in the database more promptly, and is this a good way to encourage that? This is not about whether ARIN is accurately representing anything or not. It is about whether parties in the market are coming to ARIN at the time that they do a transaction and updating the database.
If we think that that is a valuable thing for the world to be able to know who controls what addresses, then the follow-up question is how do we encourage people to come to ARIN more promptly.
Paul Andersen: Thank you. Again, approach a microphone if you'd like to comment either generally or there's some very good discussion questions. So feel to pick on one. Rear microphone.
Jason Schiller: Jason Schiller, Google, ASO AC. Just to follow up on Scott's question. I want to modify the question slightly. I think the question we're really trying to ask is not should we record transfers that are done out of policy. I think the question is should we recognize and encourage them.
There are certainly some people that are doing transfers within policy. There's certainly some people that are doing transfers outside of policy. Whether that's some sort of a lease, whether that's a permanent right to use, whether that's a future that will eventually be drawn down when within policy need can be shown.
But I think in either case the question really is do we want to reduce the risk of these out-of-policy transfers and encourage more of it or not and is that good for the IP addresses which are a public good for the community.
That being said, I think the people who really want the database to be accurate, and that is to reflect who is the authorized holder of the address within policy versus those who want it to be accurate to reflect who are the people that have the right to use for some contractual agreement outside of policy, if that's really the tension here, then I would put forth an alternate proposal which is why not record both? Why not record under ARIN policy -- so you have Party A who has address space under RSA, and they are the source of a transfer to Party B who is a recipient. Why not in the Whois show that Party A is the legally authorized holder and user of the address space and they have an RSA with ARIN and they have the legal framework with ARIN and they have subdelegated the right of use of those addresses to Party B and record both of those pieces of information in the database and let the operators decide do they want to route stuff that's out of policy or not.
Paul Andersen: So I may have misheard it. You would not be in favor at least as it's written here; you'd rather see that direction?
Jason Schiller: Well, I mean, it's hard to understand what this policy is really trying to accomplish. If it's accuracy, I would rather address it by changing what we record in the Whois rather than giving more legitimacy to these out-of-policy transfers. I think we have justified need policy for a good reason, and I don't want to encourage more people to go outside of the process by legitimizing it and reducing risk.
So, no, I do not support this policy.
Paul Andersen: Thank you, sir. Front microphone. One second.
Dan Alexander: Jason, just so I understand right, because the framework you were suggesting in this kind of split system, isn't that essentially to some degree what we have now, couldn't somebody just do a reassignment to somebody else that they are in a sense using the space?
Jason Schiller: So my belief is post-June, when the new billing structure is in place, end users could decide to pay on what was traditionally known as the ISP fee schedule. I don't recall what it's called now. And in doing so they would get the same services that ISPs get, which includes reallocations and reassignments.
It's my understanding if I'm an end site with an RSA holding address space with ARIN and I decide to pay on the ISP fee schedule, that then I could reallocate or reassign addresses to my, quote/unquote, downstream customers, which is maybe just a specified transfer to a entity that is not getting transit from me.
Paul Andersen: So your preference would be maybe to take it out of the policy arena or at least the NRPM PDP policy arena and have as services that ISPs can be joined, could be available to end users for the applicable fees. John, sorry, did I mischaracterize?
John Curran: To characterize, Jason is correct that it will be -- with the new fee schedule, it's possible for end users to be able to do subdelegations. And that's one way to effectively record the assignment of a part of an entire block to an operational entity even though you have the permanent rights.
That's one way to do it. Another way could be the database itself could be changed. You can put an operational organization in if you wanted to record a lease of an address block.
So it is possible. ARIN records who has the rights to the address block. The question is whether or not you want to encourage people to record who is using the address block, which is a different question.
Jason Schiller: To answer your question, my preference would be that all transfers are within justified need. But if that's not going to happen, I'm not sure whether recording them is better for the community because we can verify and know who's actually using the address space, or is it worse for the community because we encourage more transfers that are not appropriately documented and justified.
So I don't know. I'm split on that.
Paul Andersen: One second. We have a follow-up question from the stage.
Leif Sawyer: If we wait until June and Party A acts as an ISP and allocates downstream.
Jason Schiller: Not acts as an ISP. Pays on the ISP fee schedule.
Leif Sawyer: Anyways, subdelegates down to their customer a block of addresses. There's no -- they do not have to do needs basis criterion between them, correct?
Jason Schiller: That depends. Does Party A want to get more IP space.
John Curran: Want to come back get more addresses.
Leif Sawyer: Right. Assuming it's a completely unused block that they're not using.
Jason Schiller: That depends. Does Party A need to get additional IP space. If in this example Party A is a legacy /8 holder that never wants to have an Internet business or use IP addresses for anything and they're never going to get more addresses, then that's correct.
If Party A is an ISP and they have customers, they're growing and they're going to want to get more space, then under current policy their space has to be efficiently utilized.
Leif Sawyer: Okay.
Paul Andersen: Chris Tacit, anything in the queue, hopper? Kevin Blumberg.
Kevin Blumberg: Jason, sorry. I had one more. I think it's really important actually for the community to do the thought exercise on all of these different kinds of scenarios. You've used one very sort of -- I wouldn't say extreme scenario, but in talking with other people in the community, one of the scenarios I've heard is company does a purchase, an asset purchase, a sale, whatever, and then farms out over time, they've got a /10 and over time they do a 12, a 12, a 12, as they fall into policy.
How does that help the community -- the space is locked up. Need is being dealt with over time. But it is not being reflected as to who actually is using that space. So I'm just trying to understand that sort of scenario where -- I'm trying to understand where the need plays into this when it's locked up and not going to be usable by anybody else and is being brought into policy over time.
Jason Schiller: I have two clarifying questions for your scenario. Question one, when they draw down a /12 at a time, is it within ARIN policy meeting justified need?
Kevin Blumberg: We can work with that, sure.
Jason Schiller: Question two, is all the addresses that Party B, the recipient, using registered to them in the Whois and properly justified?
Kevin Blumberg: The original space is completely unused. The legacy space, whatever space you want, it's going to a party who is then, because of ARIN's current policy, doing it over time. They're doing it over 10 years.
Jason Schiller: The question is Party B using any of Party A's space that hasn't been transferred and reflected by ARIN.
Kevin Blumberg: It's possible, who knows.
Jason Schiller: In the case where they are, that's out of policy. In the case where they're drawing down a /12 at a time and using it after it's been transferred through ARIN, that's within policy.
The remaining question, if I can boil it down, is how does it help to not reflect that there is some portion of a /10 which is being held for Party B and being used for no one?
And my answer to that question is futures are risky. If you buy a future from an organization that goes bankrupt, you lose your future. And I think if we legitimize it and actually affect the transfer immediately, then there's no risk of bankruptcy.
The risk of doing these out-of-policy transfers is decreased and there will be much more of it.
Paul Andersen: Go to John for a quick --
Jason Schiller: Did I answer your question, Kevin?
Paul Andersen: We're getting close to the mics closing. For my ability to time manage, approach the microphones quickly.
John Curran: Just to be clear, Jason, in the model where you have subdelegations, you have effectively a permanent lease. And you have the original address holder permanently in the situation. If that was an organization that just wanted to transfer and go on its way, you actually still have it operationally involved.
It's the main contact. It's getting everything from spam to law enforcement to abuse queries. In the case where the subdelegee is an ISP, this makes sense, they're providing services.
In the case where the party that's doing subdelegations is purely an address holder, you've enshrined a certain model for eternity.
Jason Schiller: I actually disagree slightly. I think when you subdelegate the address space, you can subdelegate the abuse contracts and the operational stuff as well.
But I agree with the rest of your points, which is the Party A in this example is now in this chain forever, and I think they have to be because that is the party that has the RSA with ARIN.
Paul Andersen: I think this thread we should just leave as. It's been a great discussion. If there is more, I would use this to remind you we have the PPML Mailing List where you can take this discussion 24 hours a day, seven days a week. It never closes.
Microphones will be closing shortly. Stage right microphone.
Milton Mueller: Is it on now? I can move to another microphone if you want.
Paul Andersen: That might be better.
John Curran: I'm suspicious of the quality of the mic you're at.
Paul Andersen: Definitely nothing on the speaker. Just kidding.
That's the Milton we know and care for.
Milton Mueller: Yes, my name is Milton Mueller. I'm on the AC. I'm sorry to have to speak about this. I wish more people in the community were speaking about this with AC members with well-known positions.
But I think one thing that prompted me to come to the mic is that I thought John's definition of registry accuracy was a bit tendentious. Tautological would be another word, a more accurate word. You're saying that if in fact the person leasing or offering an options contract is still listed in the registry and they're still under RSA, then the registry is accurate. But I think we're kind of being a little too cute there and we're ignoring the economic realities of what's happening here, which is needs basis is a barrier to trading in the market.
It's perceived as a barrier by many people who want and need addresses by some definition, are willing to pay for them and they would be blocked by the application, the strict application of needs justification. Therefore, they do an end-around. They go around your process and they do these leases and options contracts.
And so this means that the registry in fact does not accurately reflect what is actually going on with the address space.
I mean, this seems very simple to me. And the problem with that -- I mean, this whole debate is really about needs basis. It's not so much about registry accuracy. Accuracy is just one of the casualties of this anachronistic application of needs justification to a no long- -- an empty-free-pool world.
And I think RIPE has had this debate. I think we've been having it for several years. I think the tide is turning. Whether or not this policy passes, I think we're all beginning to realize that we have in effect a gray market which is an end-around bypassing the actual policy. And I don't think that we want to continue to have that happen.
I think we need to make -- we need to remove all barriers to have people reflect what they're actually doing to openly and quickly register what's happening in the ARIN Whois so that if needs basis is an obstacle to that, we need to really do something about it. That's my main point.
Paul Andersen: Milton, don't run away quite yet. John.
John Curran: Amazingly, I have no view on the policy proposal either way. But I actually agree with a lot of what you said. There's no doubt there's an economic issue, there's no doubt people are doing an end-around. That's all true.
When it comes to whether or not this is a workaround or whether or not this is an economic issue, I fully agree. However, I just want to reiterate, it is not a registry accuracy issue.
If you fail to be able to qualify for a car loan and instead you lease, you don't own the car.
Paul Andersen: Short, if possible.
Milton Mueller: That means the needs isn't being applied to the subcontract and so on. It's just going around the policy. So what's the point of the policy.
John Curran: I don't know what the point, but the title is still accurate if it's your name is not on it.
Milton Mueller: And, again, that's the tautology, isn't it?
Paul Andersen: First Owen. As you can see, he's been a little patient.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. You have an option to have policy or to not have policy. And if you're going to have policy that's not enforceable, then the benefit of the policy is reduced, but it's not necessarily eliminated.
Unfortunately, ARIN's ability to enforce policy is very limited, and so we have to kind of live with voluntary compliance to the extent that we can get it. To the extent that we are not getting voluntary compliance, I do not find that to be a credible or legitimate reason to eliminate the concept of policy.
This argument that because we can't stop everybody who takes a community resource that they're not entitled to from doing so we should not have any policies on who can take a community resource is absurd, in my opinion.
And we continue to have this discussion and this debate. RIPE has opted to say that it's perfectly fine to legitimize draft extortion, whatever other form --
Paul Andersen: Let's not characterize it that way if possible.
Owen DeLong: Okay. It's okay to legitimize the wild west of do whatever the heck you want without any regard to the community.
And that's their choice, and their community has opted for that. I don't think this policy will actually increase participation of those who want to operate outside the system in operating within the system. There are plenty of other reasons that they may want to operate outside the system besides just needs basis. Needs basis is a relatively simple one to get through if you actually care.
So I don't think it will result in more timely transfer requests and database updates, I don't think that it better balances the playing field, and I don't think -- and I do think that ARIN is properly conserving resources and trying to channel them to those organizations with legitimate need rather than having them gobbled up by people with deep pockets, regardless of need or regardless of duration of need.
So I personally think that this policy should go the way of all the other policies that have been just like it in the past, and hopefully the community will continue to say no every time these come up.
Paul Andersen: Okay. Thank you. Administration, if you wish to speak, I need to see you at least moving towards the mic in the next four or five seconds; otherwise, we are going to be closing the queues. The queues are now closed because I see no one moving. Go to the rear microphone, please. And I could ask if the remaining speakers please get your points across, but if you can be as succinct as possible because we're running a bit over time. Thank you.
Marc Lindsey: Marc Lindsey, Avenue4. I'm in support of the policy. If I stayed here long enough, I guess Milton would have made all the points I was going to make. So I'm going to get to the specific one I think needs to be reemphasized.
We transact in this space a lot. To Owen's point, can you have a policy that ought to encourage people to cheat, and I think the answer is people aren't cheating. People are using the existing policy, looking at it and structuring transactions to get what they want and still work within policy, but the net effect of trying to limit people's acquisitions to 24 months isn't working. Because they're finding other ways to control the space they want beyond that.
So why have a policy that can be worked around fairly easily at the expense of having the registry not reflect what is truly being transacted? So you ought to just accept the reality that the policy is creating uncertainties in a transfer market that are undesirable for the participants a bit because, as Jason points out, you can have the situation where there's some uncertainty if you have to worry about a long-tail transaction, what happens to those parties.
But those addresses today are not being used by the seller. So why not allow the current entity who has put money down, who has decided they can fund something for several years, not be constrained by an artificial 24-month limitation when they're not doing so in terms of their actual transactions.
So the policy is being frustrated and worked around, what's the point of the policy? If you told people we will recognize your transaction by looking at you as an entity validating the sources, validating the recipients, not for artificial constraint, you'll reduce the incentives people have to work around the registry.
It doesn't mean we all will, but it certainly will be a certain number of transactions that will be much more transparent in the registry than they are today because good actors behaving in their commercial interests will be inclined to go to the registry because it's the best place right now for public recognition of those transactions.
It's not determinative because people will do things. There's also pressure on dark transactions that are even beyond that. If the registry continues to put these barriers on, you're giving more opportunity for alternative registries to get light, because people say I am so frustrated with this 24-month limitation, I'd rather go to some other white pages and put it there because people can point to that say, see, here's another source of information that says I am now the recipient or controller of that address space.
So the more you try to constrain commercial behavior, the more people, with good actors, with commercial interests, work around it, defeating the very thing you're trying to do.
So my view on this is you can continue to do the same thing you're doing now. Keep needs there. People will transact in the way they have, buying four, five years of supply, incrementally transferring it over. Serves no one in this community's interest to not have better transparency in what's happening in that context. If you want to be in the dark, continue to be in the dark about that. Okay. But be aware of the consequence.
You have a perception that there may be certain address space that's sitting out there being held by one party, but in reality it's controlled by another. That to me seems like a bad outcome for everybody.
Paul Andersen: Thank you for the comment in support. We're running very tight on time. Marc, one follow-up question.
John Curran: I want to understand this. I think your point is well made that the people are structuring transactions to work around policy.
But I note as long as the policy is followed, this is similar in some ways to the difference between tax avoidance, which is legal, and tax evasion, which isn't. People structure transactions to minimize taxes. That's not wrong, it's just optimizing your circumstances.
My question is this: I know operational entities may engage in structuring transactions through number resources in order to meet their needs. But I'm not aware of any financial speculators who are doing it.
The risk of a financial speculator who engages in a structured transaction is very different than an operational entity. Operational entity will eventually make use of the resources and can often show they will have need at one point or another. A financial entity potentially is someone who would engage in pure speculation is potentially endangering their entire investment.
Do you believe that the activities of the current policies are limiting financial speculation?
Marc Lindsey: I think the answer is yes, there's uncertainty in the return, and one of them has to do with this idea that the ultimate user has to be in the public registry, has to be someone who has a need for the address space. So I think that that is one bit of uncertainty.
The biggest uncertainty is the pricing curve. It is so unstable. How long is the market going to last? When do I cash in? How do I cash in? I think the inherent instability of the market is a bigger deterrent from real money.
But I will also posit -- I am not at all saying I know someone who has done it -- but I can posit there's workarounds to the existing policy that would allow the very thing you're talking about.
There's nothing that stops Goldman Sachs from going to an entity that has address space and say: I want to give you $5 million --
Paul Andersen: Keep names out of it. I know that was hypothetical --
Marc Lindsey: Bank A. Bank A has $5 million and says, here, a source C, you have a /8. I want to hold that. And when I tell you in two years to transfer it to D, you will do so. That's within policy. Speculators right there, because there's money in -- there's liquidity in the system that's not being prevented by policy.
But instead what you're doing is transactions between companies who are normally operating, you're putting this barrier on it, chasing speculation, which you're really not preventing.
Paul Andersen: We've got to wrap up there. Very quick, the queue -- Vint, I don't know if you still have an interjection you want to make quickly. Okay.
Chris Tacit, any remote participation? Nothing. Front microphone, then rear, then we are complete. Please go ahead.
Alyssa Moore: Alyssa Moore with Cybera. I guess following on Owen's comments in the same vein. Is the solution to out-of-policy transactions apply more policy on top of it? I have a little bit of trouble with that. And I was kind of making the same tax evasion versus avoidance comparison as the last commenter was talking as well.
So I'm just not sure that more policy on top of policy evasion is the solution. And ultimately it legitimizes the out-of-policy transactions that are occurring. I think there's something that needs to come ahead of this discussion before this discussion is even relevant. Thank you.
Paul Andersen: Thank you for that comment. Last comment. Rear microphone.
Jason Schiller: Jason Schiller, Google, ASO AC. Owen mentioned the phrase levelling the playing field. Seems to me the most level playing field is the one that is needs-based where everyone gets what they need for the next two years. The only thing that makes this playing field somewhat unlevel is the fact that navigating the process is difficult for smaller organizations and those who haven't done it before or regularly. And I think a reboot of 2015-7 can and will address that, and that is the appropriate way to address it.
My concern is removing all needs basis will allow the organizations with the deepest pockets and the services that make the most revenue per IP address to concentrate the address space. And I'm very concerned that if you take a specific market segment, that one player has deep enough pockets to outbuy the other players and dominate that segment. And that's not good for the consumer and that's not good for IPv6 adoption.
I believe that the current regime does limit financial speculation and financial speculators buying up address space.
I also believe it's limiting the operators who think that they need a five- or ten- or 15-year supply of address space from buying up as much as they would otherwise.
So I think it's good that we're minimizing this behavior. I would certainly prefer it to be zero. And I certainly recognize that it's not zero. But that's the reality we live in.
And I think the very fundamental question is given that there is some out-of-policy transactions occurring with some amount of risk, do we want to legitimize that and reduce the risk and encourage more of it.
Paul Andersen: Thank you. Thank you for all that.
We have a few minutes. First, thanks to Leif for the presentation. Please give him a hand.
Paul Andersen: We're going to do a poll. Good for a poll. Same question as last time. Counters in position. Excellent. So the question is whether the ARIN Advisory Council should continue to work on this proposal through the process. First those in favor and those against. I'd ask those online to vote at their earliest.
If you wish to vote in favor, please raise your hand nice and high. Nice and high. Please keep it up. Thank you. You may lower your hands.
And those who are opposed to the question, please raise your hands. There we go. One more moment. Those online please indicate as quickly as possible. Thank you. One more moment for the results.
I'll do the public services. Snacks are next. My apologies for keeping you between that and snacks, but we try to find a balance between staying on time and not cutting off discussion, especially on a policy like this. At lunch don't forget to do table topics. It will be a whole new set or some -- some returning and some new table topics from yesterday. Always good. Oh, same ones. Same ones as yesterday, but new vibrant discussions. We always know this is not the kind of venue people like to be -- thank you, sir, as always.
On the matter of 2015-9: Eliminating Needs-Based Evaluation for Sections 8.2, 8.3, and 8.4 Transfers of IPv4 Netblocks, 105 in the room from the same distribution; nine in favor, ten against. This decisive information will be provided to the AC for their consideration.
John Curran: Okay. The good news is next is break. We'll have a refreshment break outside. We're going to curtail it just a bit to try to get us back on schedule. So it's supposed to be until -- refreshment break until 11:00. If I let you have a half hour, I'd have you at 11:15. Let's go for 11:05. You have 20 minutes. 11:05.
RIPE NCC Update
John Curran: If everyone will come back in and get settled, we'll get started. Oh, look, here they come. Okay. So welcome back.
We have the reports, regional reports going in, global reports.
So what do we have going on? First up is Andrew de la Haye, and he'll do the report for our friends from LACNIC. I'm sorry, RIPE NCC.
Andrew de la Haye: Good morning, everyone. I'm Andrew de la Haye, COO of RIPE NCC, and I'll give you a short update on what's keeping us busy on the other side of the ocean.
There's a lot of items going on. We see a strong membership growth and a change in membership. I'll go into a bit more detail in a bit.
We tried to do a bit of more regional approach than we're used to.
We see a lot of inter-RIR transfers, and I will go into that as well. And it's very interesting maybe for some of you, as there was quite a discussion this morning on these topics.
Assisted Registry Checks. It's basically something which is to improve the quality of the registry. And Leslie had a talk yesterday about the POC validation. This is a bit of a different approach. It might be interesting for you. And some other stuff we do.
Growing membership. We see up and to the right a strong membership growth in the RIPE region. We currently are above 13,000 members. It's considerable.
Who are these new members? That's the big question to us. We are currently working on a project on member demographics to really get a good hold on who these members are, and we see that the traditional members are becoming less compared to the total membership. So we see lots of new IT services companies, manufacturers and enterprises becoming members. In the past we might have seen some of them getting PI, provider-independent space. Currently they're becoming a member because out of the last /8 they can still receive a /22.
The hard part of this is that we want to introduce them to RIPE and RIPE NCC and encourage them to participate in the processes. And we're trying to do all kinds of things to make sure that they feel part of the system, so to speak.
Furthermore, we will do a big survey this year. And I know that last time we did a survey three years ago there were lots of people from the ARIN region as well that filled it out, and it will give us lots of interesting information on the service we're providing to you and all of that.
We do do a lot more engagement with the members, especially because they're new. We're trying to really get them on board. And we have multiple projects running for that. One of them is membership lunches, for example. So those areas where we have already staff around, we invite a subset of our membership for lunch. It's lightweight. It's very nice. Meetings are around two to three hours, and we talk to 20 to 30 members.
And the interesting bit is that those people that come to those lunches are different than those who go to RIPE meetings or regional meetings. And we get information from them firsthand, which is very interesting. We also explain to them about process, procedures and new services we would be providing.
A more regional approach. As you know, we have an office in Dubai and some staff in Moscow. We have a lot of meetings. MENOG, ENOG -- Middle Eastern NOG meeting, Eastern European NOG meeting -- SEE -- South Eastern Europe -- meetings. In all these meetings we're really trying to get closer to our membership. And they actually differ a lot throughout the regions. So that's what we're trying to achieve.
We also have a project currently going on which is about translations. We have 74 countries and even more languages to cover. We're currently focusing on two, Arabic and Russian, mainly, because those are large parts of our region. And it helps the engagement part. Especially, for example, policy updates we'll also provide in different languages, and we see more participation throughout the region by it.
In those regions we also see a big need of resources. And, as you all know, we've run out. So there is a processing pledge which is resource transfers. And all the Internet number resources in the RIPE NCC can be transferred. IPv4, IPv6 and AS numbers as well. This community, the community, the RIPE community, they set the policy with a focus on keeping their registry up to date and of high quality. And they did it by making sure that there's very low entry barriers to register.
So there's no needs justification for a transfer, but there is a 24-month holding period to allow people to basically stop the flipping mechanism, as we call it. So you can transfer without any needs justification, but you have to hold onto those transferred resources for 24 months. And that comes back to the discussion you had earlier today.
The numbers on the transfers in 2014, we had around a thousand transfers. That went up to almost 3,000 in 2015. And currently we have seen 402 transfers so far in 2016. So we see a bit of a decrease. Although these numbers don't show the mergers and acquisitions. And we do see an increase in mergers and acquisitions which sort of bypasses the 24-month rule. And the Board just did an announcement on a couple of these matters to make sure that the loophole that did exist is taken out of the policy.
We see a bit less resources being transferred. And, interestingly enough, the size of the resources is quite small. So it's more or less /20s and smaller that are being transferred.
This is a graph showing the completed IPv4 transfers. I don't want to go into too much detail here, but the interesting thing here is it's sort of balancing out at the moment, and we're processing 150 resource transfers a month, approximately.
Next are the intra-RIR transfers. There are, of course, inter-RIR transfers as well. The policy was implemented in September 2015, last year. Since then we have processed 19 inter-RIR transfers so far. It's 45 address blocks, one outgoing to ARIN from our side, 14 into the RIPE region from the ARIN side, and four from APNIC. AS numbers can also be transferred, but we haven't seen that yet.
And what I think, which is interesting to note, is that most of the address space that is being transferred into the RIPE region is legacy address space.
These are some numbers. It may be interesting to have a look at it online. Within the circles it's the amount of address space that is being transferred within the regions, and the arrows show in- and outcoming resource transfers.
With all these transfers going on and the value of a resource being higher than in the past, we do see a lot of hijackings. And we had -- in 2015 we had 134 hijacking cases. And they're very sophisticated. We see organizations reregistering expired domain names, falsifying documentation, having falsified notary stamps on documentation and all of that, which is quite a burden on our Registration Services team to figure out what is real and what is not, especially we're covering 74 countries, which also has some legalistic implications, of course.
But, yeah, we're still holding on, and it looks all right. It's sort of stabilizing. One of the things we do is urging our members to update their registry and really keep their registry up to date. That's something which is one of the important points for us this year, to explain to our members that this is very important.
To make sure that our members keep their data accurate and up to date and also to have less of these hijacking cases, we created the process which we call Assisted Registry Check. It's not the same as the POC validation. The process is different. But the intent is the same, and that is a high-quality registry and safeguarding our members.
It's a lightweight check where we give our members a phone call and we really talk to them about the registry, their contact details and those kinds of information sets. And we do on email as a follow-up.
The emphasis is adding value to the members. So it's not us really auditing them but it's really trying to help them to improve their data.
The intent of the ARC is that the RIPE NCC's key responsibility is to maintain an accurate and high-quality registry. And we did 2,200 ARCs so far this year. And about 95 percent, which is shockingly high, of those ARCs we had people that needed to update their LIR data, and that can range.
In the blue part, it's the actions taken from resource registration numbers that needs to be changed or LIR contact details that needed to be changed, which is the far most highest one. There's also the vulnerability for many of the LIRs if they don't keep their data up to date.
Next to these actions we also discuss any policy-related questions, transfer-related questions, and we provide them information about the tool sets that we're providing.
Finally, RIPE Atlas. This is our measurement framework for connectivity and reachability. We are almost at 10,000 probes across the world. It's very successful. And we have Philip Homburg here as my colleague who can give you all kinds of information on the RIPE Atlas project if you're interested.
Then RPKI. RPKI is still going strong in the RIPE region. Currently we have about 25 percent of our membership that's requested the RIPE certificate, RPKI certificate. And about 25 percent of the address space is under ROA as well. That's very high.
And the interesting bit is the last bullet. We do see an increase in operational usage. We have quite some members at the moment that are offering RPKI as a Service. You see that mainly in that space for their customer base.
Finally, RIPE Academy. RIPE Academy is our learning platform. It's an online learning platform, and people can get a certificate if they go through some of those trainings. I looked into some of the statistics and, interesting enough, 11 percent of -- which is the highest, actually, of the users and the people that receive certificates are from this region. So thank you for participating in RIPE Academy.
And we hope to provide this service to others as well. In May we'll have the RIPE meeting in Copenhagen. You're all welcome. And that brings me to the last slide.
John Curran: Any questions for Andrew? Okay. Excellent report. Thank you very much.
John Curran: Next up we have the report from LACNIC. Sergio.
Sergio Rojas: Good morning, everyone. I'm Sergio. I'm working at LACNIC in the Registration Services department, and I'll be presenting the LACNIC report.
As you know, LACNIC is one of the five RIRs around the world. We're covering 33 countries in the Latin American and part of the Caribbean region. We have two NIRs -- one in Brazil and the other one in Mexico. A number of our NIRs are a member of LACNIC as well. So including them we have a little bit more than 5,000 members.
We're 44 full-time staff in LACNIC from nine different countries like Venezuela, Argentina, Brazil, Panama, and even countries that are out of our region like Spain and Russia.
Here you can see the evolution of our membership since 2002, when LACNIC started with a few members. I think it was just 100 members. And now we have 5,000 to 153 members. Below you can see the full evolution of our membership as well but by category.
And more than 50 percent are in small/micro followed by small, medium, large category.
LACNIC is in the Phase 2 of the exhaustion period right now. That means that we are in the soft landing policy. We reserve a /10 for soft landing policy where the maximum allocation is a /22 and a minimum is /24, and the organization can receive an additional allocation every sixth month.
And we started these phases in June of 2014. In analyzing the behavior of the allocation in this period, we estimated that we will exhaust this /10 in January of the next year.
So after that we will start a Phase 3 that we have a little bit more than two /11s for just new members, and with the same restriction of prefix size, maximum allocation /22 and minimal allocation is /24, but just for new members.
Below you can see a little chart. And it's showing the way that we distribute the /10 for this period. And the blue part of the graph you can see the allocation that we have made to ISP providers, the red one is for end user, and the yellow or orange is the available space, that we have almost 37 percent available in this /10.
About policy proposal. I will not talk about every item here, but we have right now six proposals. The numbers 1, 2, and 3 basically talk about prefix allocation in IPv6 initial or additional for end user and ISP as well.
We have a very interesting proposal as well in number 5 that pertain to reserve a /15 for inter -- for critical Internet infrastructure like ccTLD, IXP, DNS operation.
I think you have already implemented this policy in your region, but we don't have it. We can allocate them, but someone in the community present a proposal to reserve a /15 per this proposal.
One of the initiatives that we have implemented last year is the policy shepherd, and the goal of this initiative is to have a new author submitting the policy proposal. Probably in the community there are a lot of people that have good ideas to improve the policy manual and they don't know how to start it.
So that's why we started with that. And we found it really successful.
And even last year we had two proposals supported by two different shepherds. Even one of them was approved, and the next one was sent to the Mailing List to be discussed.
Capacity building. We had several workshops in different countries in the LACNIC region. Even in our meeting, in both of them, the first day is the full-day training in IPv6. And then we have the campus.lacnic.net as well. That is learning portal where you can take IPv6 course.
We have two modules, the basic and the advanced model. It is completely self-managed. I mean, you take the course in your free time. Obviously you have to finish in a period of time. You can check on the annex and then get your certification.
And security and IXP, our project AMPARO is responsible for this. Last year we organized CSIRT training in Costa Rica, Paraguay, and Cuba, and for IXP in Argentina, Nicaragua, Honduras, and Panama. Talking about our event, our next meeting will be in two weeks in La Habana, Cuba.
So you are invited to participate to know how we work, how we do the things in our region. And, of course, your collaboration, your experience and your knowledge will be very welcome. So if you're planning to attend, we're very happy to receive you.
And that's it. If you have any questions, I will be happy to answer.
Vint Cerf: It's Vint Cerf, Google. A question about the IPv6 classes. When you teach them, do you teach them about running dual stack as opposed to running just IPv6? Because for a long time I think people are going to have to be capable of running both protocols in parallel, and in particular being able to run in situations where there's some of them are only -- some of the users are IPv6-only.
So the question is you teach both when you're teaching about IPv6.
Sergio Rojas: I didn't take the course. But, anyway, we always try to explain that is a good option to implement dual stacking instead of using another -- yeah.
Any other questions?
John Curran: Any other questions? Thank you.
John Curran: Next up in our global reports we have Adam for the APNIC report.
Adam Gosling: Thank you, John. Hello everyone. I'm Adam Gosling. I'm the policy guy at APNIC. These are our standard slides. They're not mine. Some I know more about than others, so I will try and skip over the ones I don't know so much about.
This is our vision. This presentation is divided into three sections -- serving, supporting and cooperating. Kind of run through them individually, and I guess that will become more obvious why they call that serving first.
That's the APNIC membership. We're on track for about 6,000, a little over 6,000 members this year. That's direct members at APNIC. We have a lot of NIRs. They've got around about 6,000 members. I think by the end of this year we're expecting close to 13,000 members in total.
We've been giving away a lot of IPv6. Maybe not as much as we'd like to. As you can see, most of those are allocations and most of them are the kind of standard default delegation sizes, 32 and 48 for allocations and assignments.
The last little circle over here, the blue area is our kind of like for like, one click. So if we've got v4, you'll get a similarly sized, appropriately sized v6-block automatically. But most people seem to go through the normal criteria.
V4 delegations still giving that out. We've got a bit. We've got two pools. We've got our final /8 pool and a returns pool, which anything that we recover from the community or anything given to us from the IANA go into this second pool. And our members are allowed to dip into each of those pools independently. They can get a 22 from each pool, giving them a total of 21.
As you can see in the middle circle there, most people go for the 22. So that's a total number from both pools.
I guess there's not a lot of information in here. Quite a lot of them are new members. The NIRs, the big blue area, the pool will include new memberships as well.
We're running low, as you can imagine. I think we've got like half a /8. We'll probably run out of the final /8 soon. Soon being maybe in another year. We're planning to implement a waiting list on the second pool, which is the returns pool. So we'll run out of the final /8, but we'll still have a returns pool so people will be restricted to a 22 only rather than the 21.
Transfers, going along, as you can see, it's kind of picking up slightly. These are the 31st of March figures. Looks like 2016 will be a pretty busy year for transfers.
People do use the preapproval service and the listing service. But not the majority, I guess.
You can see the orange part there. I don't know how good those slides are from the back. The orange part is the inter-RIR transfers. That's been pretty stable. But we'll see how it looks this year. Didn't check the figures behind this graph, but looks like it could be a big year for inter-RIR transfers.
ASN assignments, the orange there is the 4-byte. We've always been pretty good at giving out 4-byte ASNs. We don't have a lot of 2-byte numbers left anyway. So you can see the inflection point there is when we started out giving 4-byte by default. So similar, if someone can't use that, they can return it and, if they've got a technical justification, can get a 2-byte.
RDAP. Well, we implemented that last year. I won't go into that because I'm not an engineer. But I think that's all happening. It's been in production for a while now.
RPKI, we've been pushing this pretty hard, kind of full-on marketing campaign. T-shirts and stickers and so on. And we -- our member services team kind of proactively sit people down when they see them face to face and say, okay, here's your laptop, log in, make your ROAs. And that's had a good effect.
The statistic at the bottom is kind of the relevant one. We've gone from less than a percent to 3.24 percent in two months. It's been shown to work. It's a pretty cool T-shirt. I guess it's good incentive. But having a hostmaster sit with you and help -- actually it's working really well because whenever they kind of find any user interface difficulties, they're able to report back to the software engineering team and tidy stuff up. It works as kind of a troubleshooting function as well.
MyAPNIC, it's of course under improvement. Some stuff there in managing Whois and Whois updates, reverse DNS. It's something that's ongoing. It's a lot of work, as I'm sure you can imagine.
They did a little bit of work on the website. I was a bit hurt by that because I built the first one. Or the last one, not the first one. So the front page got a kind of full overhaul with kind of five dot navigations, and then the bottom half -- well, the bottom most of it is from our blog.
They overhauled the services Web pages as well, which is very focused on people, on kind of actions that members take, rather than kind of being in members -- sorry, information and statistics kind of used to be scattered through that. This is something that they're planning to kind of go through, the rest of the website as well, and give the inside look and feel that kind of fits with the front page. But that's an ongoing project.
Training and development is really big in our region. We put a lot of effort into it. We did a survey, Training Needs Assessment, last year, which came up with these. I won't go into too much detail to try and keep on time.
There's kind of a training that's probably shown better here. We're trying to move away from the kind of high-travel, face-to-face training. Obviously that's still there, but if you look at the first quarter, that's ten face-to-face courses, which would give us, if we were on track, 40 for the year compared to nearly 80 last year.
What we're seeing is we've done a lot of work to rejig the e-learning, which is kind of webinar-style e-learning, and tweaked the content, tweaked the schedule of those, and we're getting a lot better results or a lot better attendance.
We're also working with the RIPE NCC a little bit, picking up some hints and tips from them about how we can move this CBT forward.
And also video archives. We've been promoting that and putting more effort into getting training videos on YouTube, and that's working as well. As you can see, there's quite a fast increase there.
Technical assistance. This is another part of our development thing. This is kind of a much more hands-on where we take member services person and a kind of engineer, quite often outsourced engineer, and do a tour around a city or a country and meet with individual members and talk about their specific network and their needs and try and troubleshoot any problems they're having or give them advice how to deploy v6 or whatever they're missing, RPKI. That's when we kind of sign up an RPKI candidate as well.
Policy at APNIC was a little bit quiet in the last meeting. We had a couple of changes that were implemented from the previous meeting changing the criteria for IPv4 and AS numbers.
I guess it made it a little easier. Probably a little bit easier for enterprise as much as anything. We also, as part of the AS number policy change, changed the definition of it to move more away from the kind of multi-homing.
Part of the driving factor was things like the elastic bandwidth, people wanting -- both -- kind of justification for both changes I guess were along the lines of wanting to build their network for the future and architect for the future and have an ASN so they can turn it on and use it when they need it rather than having to go wait for 24 hours to give one.
In our last meeting -- I should stick on that a bit. In the last meeting we had zero policies to discuss, which is nice and easy for me. Quite relaxing. Instead we did some discussions around the Whois, which I mentioned yesterday, which was kind of helpful.
The discussions for Whois -- we used to have a Database Working Group, but we don't have one anymore. So that's kind of been adopted into the policy sea. We do a lot of NOG outreach, and there's a lot of NOGs in our region. I'll try to speed up a bit. We help RIPE out with their Anchor and Atlas deployments, fellowships, L-root.
IPv6 outreach with the ITU. Some of it is high touch. In Thailand we do a kind of annual workshop, five-day workshop in collaboration with the ITU. But we're also sponsored by the Australian government, do a technical assistance, which is -- I think it's quite a long thing, it's kind of seven days' work or something, where we run a bit of a workshop for the country and do this kind of high-touch one-on-one work with individual organizations. That's been really well received as well.
Adli Wahid, our security specialist, working pretty hard. He travels around a lot presenting for NOGs, CSIRTs, and LEAs. He's rarely in the office. He's in huge demand. But he's a great guy and very knowledgeable.
APNIC Labs. I guess most of you are pretty familiar with the work that Geoff and his team do. So I kind of won't go into that because I'm not really across it.
There is one really cute thing. I don't know whether you've seen this ASN visualization tool built by Byron. It's fun to play with, and I guess it's useful if you understand that kind of thing. But that's publicly available. Have a go, as it says.
It's a great way to visualize what a country network looks like -- or networks.
APNIC events. We obviously hold two conferences a year. We were just in Auckland. We'll be in Bangladesh later this year. And then we have a regional series of conferences we call ARMs. They're kind of subregional. And we did 16 economies last year, which is pretty good. I guess they'll be planning for the same sort of numbers this year.
As I mentioned, the blog, which now features on the home page. It's an award-winning blog now. The team is very proud of the award. It's quite a nice award actually. It's been going really well. They're getting good numbers, good traffic on it, and that's increasing.
I guess as an open invitation, we take guest bloggers. That can either be an interview or an email interview with one of our Coms people or you can write and submit.
There's some great content. I probably don't write enough. It's kind of cute. We have -- internally each year we have the Bloggy awards, but pretty much everyone wins. But you get a nice little trophy for writing a blog.
Our development program, ISIF, is a grants program for lots of different things. That slide is actually about research grants, which is a new thing. There's some more information you can read if you download it. Applications for those grants are open I think until the end of May.
Cooperating. So we work with anyone that wants to work with us pretty much. Global cooperation, IPv6, across IPv6, particularly with our colleagues in other RIRs and governments and the ITU, I guess, governments and government organizations.
I won't touch on that one. I guess we'll talk about that, RIR collaboration. We kind of try and pick the best ideas from the other RIRs and we share back when we're asked. G.G. Ames' (phonetic) photo is up there. He just did a long stint racing around the world. Well, not racing. I guess he was kind of on a long sabbatical where he went around and collaborated with a few researchers in different regions and enjoyed himself very much, I think.
Next, as I say, we're in Bangladesh. And after that we've got our 2017 meeting with APRICOT in Vietnam, and then we'll be off to Taiwan.
One last thing, our survey. So we have a member and stakeholder survey which we use to inform our strategic planning process. It's a stakeholder survey. So we welcome and encourage everyone outside the region as well as inside the region to participate. That looks like it opens in July. We're very social. Thank you very much.
John Curran: Any questions for Adam?
Andrew Dul: Andrew Dul, ARIN AC. This is much less a question for you, Adam, and more a question for all of the RIRs. Are you guys coordinating your online training materials in any way to make sure you don't completely duplicate things and are building best-of-breed and that kind of stuff?
John Curran: I can say that ARIN has a limited library of online training, and therefore it's well coordinated, not conflicting with the others.
Andrew Dul: Are you pointing to other --
John Curran: We have a small number -- we do ARIN-specific -- like ARIN Online -- training so there wouldn't be overlap.
We don't do general training, general technical training. Similar. So I think we wouldn't see a conflict. I don't know about RIPE and APNIC.
Andrew Dul: Are you pointing at each other, too, I think, where helpful?
John Curran: I don't think -- we haven't pointed people to training in our region. A lot of folks look for commercial services for that. But we're happy to do so if that's what the community wants us to do. We can build a directory or send pointers to the RIR training that's out there.
It's a fine line between doing what we need to do versus doing something that might be stepping in the way of commercial activity in the region.
Andrew Dul: Just a thought for consideration.
Vint Cerf: I just wanted to mention -- Vint Cerf from Google. I've been supporting Geoff Huston's research on IPv6 deployment and DNSSEC deployment through Google actually. He uses advertising mechanisms in AdSense in order to detect that data. And I've been very happy with Geoff's work, as I think many other people have. I wanted to reinforce the utility of that research program.
Adam Gosling: Thank you, Vint. If you haven't seen that, there's some great country-by-country statistics on v6 deployment on the Labs site. There's a lot of content on Labs that's well worth looking at.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Two things. The visualization tool really shows the by country brilliantly with IPv4 and IPv6, and I strongly recommend everybody in this room, when we're talking about IPv6 adoption, to look at their country and see the disparity between the number of ORGs, not the size, but the number of ORGs that are doing it.
The second thing is I wanted to go back to the AS, inter-RIR AS. So APNIC and RIPE both allow for it?
Adam Gosling: Yes.
Kevin Blumberg: Are there any restrictions in what kinds of AS, or is there no delineation in that?
Adam Gosling: Between 2- and 4-byte you mean?
Kevin Blumberg: Yes.
Adam Gosling: No.
Kevin Blumberg: Are there any plans that you know of in either community, if you would like to speak to this, to continue that practice, remove the practice, or is this something that we should be looking at adding into ours to make it a trifecta?
Andrew de la Haye: Andrew de la Haye, RIPE NCC. No, there's no discussion whatsoever on this topic in our region.
Adam Gosling: And there's no discussion in our region. To be honest, I don't think there's a huge demand for it. I would have to check what the numbers are. I can maybe try and check that overnight or late -- or -- and report later today.
John Curran: There's no discussion in our region until just a moment ago.
Adam Gosling: Thank you.
John Curran: Okay. We are now to our last RIR report in the global reports, and that will be Alan coming up to do the AFRINIC report.
Alan Barrett: Good morning, everyone. I'm Alan Barrett, CEO of AFRINIC, and I'm here to tell you a little bit what AFRINIC has been up to recently. If I can make this -- okay, yes. So membership has been growing. We're now up to, as of the end of 2015, almost 1,300 members. 148 new members during 2015.
Last year, 2015, we allocated almost exactly one /8's worth of IPv4, and that's the highest we've ever allocated.
We also allocated quite a lot of IPv6, about 4,400 /32 equivalents. That was actually a few larger blocks, a /20, /23 or something. And a lot of /32s. So it adds up to the equivalent of about 4,400 /32s, mostly for ISPs, so LIRs, and 27 /48s which went to end users. That's also the highest v6 allocation that we've ever had.
Also last year, in 2015, we allocated 159 AS numbers. We use an undifferentiated pool of 2-byte and 4-byte, and most applicants get a 4-byte ASN. But if they can show that that doesn't work for them, then we are able to allocate a 2-byte ASN.
So right now, as of yesterday or the day before, we had 1,290 members, and between them they held almost five /8s of v4 space -- that's like 83.3 million v4 addresses -- and more than 9,000 /32 equivalents of v6 space.
We also have quite a lot of legacy space holders in our region. We know of 351 organizations in our region who are not members but who hold legacy space. And between them they hold about 8 million v4 addresses. That's about half of a /8.
We still have 1.7 /8s of v4 in our inventory. So we're the only RIR which is still able to allocate v4 space according to our traditional policies.
We have a soft landing policy in place, which I'll speak about in a minute or two. We're encouraging v6 deployment. We offer training on v6. Free training. We ask the hosts to provide the facilities. But we provide the trainers. It's on site, hands-on training. We do not have any online training courses.
We have an IPv6 testbed where people can -- in a closed environment they can play with configuring v6 on various virtual machines and see how that works.
Also regarding v4 exhaustion, one of the policies under discussion is about use of v4 space outside the region. We also have a policy proposal on the table for transfers, and we have two policies on the table for changing our soft landing proposal.
So the out-of-region policy -- right now the situation around use of AFRINIC IP address space outside our region is a little unclear. The policies are mostly silent on what happens if you're an organization in Africa and you get space from AFRINIC but then you expand somewhere else and you want to use your space, the policies are silent about that.
So in practice we allow people to use their space anywhere, provided they have a base in Africa. But is this policy under discussion which will change that rule? And I can't remember the number. I think it talks about 20 percent usage outside the region.
But this is quite contentious. Partly because it's difficult to find how out of region use works. Seun, yes, can you clarify?
Seun Ojedeji: Thank you. I'd just like to quickly mention -- sorry. This is Seun, co-chair of AFRINIC Policy Development Working Group. I'd just like to mention that this policy has been withdrawn, so the status has changed. It's currently withdrawn. Thank you.
Alan Barrett: So, I'm sorry, I have out-of-date information here. It was quite contentious and the author withdrew it after seeing our position.
Okay. There's a transfer policy under discussion. The draft would allow interregional transfers as well as intraregional transfers. It would be needs-based. The recipient of the transfer would have to -- if the recipient is in the AFRINIC region, they'd have to comply with AFRINIC policies. If the recipient is in some other region, they'd have to comply with their own region's policies.
There's a cooling off period where you can't flip space very quickly. Again, this is quite a contentious policy proposal. There's a strong part of the community which feels that it would not be to the benefit of AFRINIC right now to allow interregional transfers because many people see this as allowing people from other regions to deplete AFRINIC's stock of IP addresses.
So formally it's under discussion, but there's quite a lot of controversy about it. We have two policy proposals on the table to change our soft landing policy.
But before I talk about them, let me say what the current policy is. The current soft landing policy is that once we get down to one /8, when we start allocation from our last /8, then the maximum allocation or assignment will be a /10. So currently there's no real maximum. If you could justify a /8, then you could get a /8. But the soft landing proposal says once there's only one more /8 left in the inventory, then you cannot get more than a /10, and that will continue until a second phase when there's only one /10 remaining in the inventory, then the maximum will become a /22.
So that's the current status. Yes, Vint.
Vint Cerf: It's Vint Cerf. And I'm looking at the chart, and what the chart says is different from what you just said, I think. It says in phase one, when you're down to the last /8, the maximum allocation is /13 and not a /10. You said a /10. So I'm confused.
Alan Barrett: I believe I can clarify that. The slide is talking about the proposal which is on the table. But what I've been speaking about is the current policy which is not on the slide.
So the current policy is in Phase 1 you can get a /10. The proposal on the table wants to change that so that in Phase 1 the maximum you can get is a /13.
Vint Cerf: Thank you.
Alan Barrett: That's one of the two policy updates on the table. The other one wants to say run at maximum speed until there's only one /13 left. And then when there's only a /13 left, the rules change that it's available only to new entrants. So people who already have space cannot come back to get more. But new entrants who have nothing will be able to get up to a /22.
So two competing proposals on the table for changing the soft landing policy. They're both under discussion.
We have a new IPv6 certification platform. We've developed an online testing framework. We have 520 questions about IPv6-related topics. It covers all six levels of Bloom's taxonomy, which I never heard of until recently, which is about knowledge, comprehension, application, analysis, synthesis and evaluation. So if you pass this test, then you can do all six of those things regarding IPv6.
Our test is certified by the IPv6 Forum. So the current status is we have the testing framework. We have many questions. Our test is certified by the IPv6 forum. But we've not actually issued any certificates yet. We're now looking for partners who can help us deliver the exam.
We feel that for the maximum benefit, the exam should be done in an individual environment so that we can have some trusted organization like a NOG or an ISOC chapter or a training institution who will hold a session in a room with an invigilator to see that there's no cheating. But the test itself will be online, and the end result will be that AFRINIC will give you the certificate, and our certificate is ratified by the IPv6 forum.
I thought I had a slide on training that seems to have disappeared. Okay. Let me talk about it. We do training on IPv6 and on how to interact with the registry, how to become a member, how to fill in the forms, how to do an addressing plan.
We hold several of these training courses around Africa. Every year we call for proposals for people who want to host a training session, and we're fully booked for this year. But towards the end of the year we'll be putting out another call for potential hosts.
Okay. And finally we hold two meetings a year like most of the other RIRs. Our next meeting is the 7th to the 10th of June in Gaborone, Botswana. So please join us for that, for the Africa Internet Summit and the AFRINIC 24 meeting.
It actually runs over two weeks, from the 29th of May to the 10th of June. The first week is for training and workshops and the second week is the conference itself. So if you want to attend from the 7th to the 10th of June, that would be great. Unless you're part of the training or workshops, of course.
Then our other meeting this year will be in November in Mauritius from the 25th to 30th of November. It's about eight days. Again, the first four days of that will be training workshops and such, and the last three days will be the main part of the meeting.
So if you can only come from the 28th to the 30th, that's fine. But if you can come for the whole time, that's also okay.
All right. Thank you. Any questions?
John Curran: Any questions for Alan?
John Curran: Thank you. Excellent job.
John Curran: Okay. We're actually going to get right on schedule. We're going to have the IANA report after lunch. So for now I'm going to let you go. Lunch is across the way where we had breakfast. And we're going to be on lunch from now until 1:30.
Important messages: There are, of course, AC topics at the tables, here we go, including joining the AC. Is there a different way to look at need? We had a little bit of that already. IPv6 for small organizations, and whether this policy change is as a result of the new fee schedule that may be necessary.
Please take your valuables with you. We do not lock this room, so take your valuables. Please be on time, 1:30, back here. Thank you.
(Lunch break 12:30)
Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
John Curran: Welcome back. We're going to be picking up on our policy block this afternoon. So that will start off with Andrew. So it's going to start off with Draft Policy 2016-1. Give me one minute; I just got to do something.
At the head table we have Vint Cerf, our Chairman of the Board; Dan Alexander, chair of the AC; we have Kevin Blumberg, vice chair of the AC; Ron da Silva, who is actually the ICANN Board member appointed by the numbers community and was originally on the NRO Number Council. Who do I have hiding on the other side of you? Milton Mueller, economist professor and member of the Advisory Council. There's our vice chair.
I can't believe this. I draw a blank with faces. John Springer, yes, member of the Advisory Council. That's probably diagnosable, seeing a face, not being able to do it. Luckily I'm not afraid of podiums; just faces apparently get me undone.
So we're going to do Draft Policy ARIN-2016-1, which is the reserved pool transfer policy. All right. Bring up the agenda of the afternoon items we're going to do.
All right. So we're going to do ARIN-2016-1: Reserved Pool Transfer Policy. We'll do the IANA update that we didn't do this morning. We'll have the IANA Transition panel. We'll have a Policy Simplification panel. We have Nate's Software Development Update, and we have the Open Microphone.
Next up, Draft Policy 2016-1. It says here Andrew Dul, but on the slide it says Amy Potter. So Amy.
Amy Potter: All right. So right now we have a couple of blocks that are reserved for specific purposes. We have a set of blocks that are reserved for v6 transition, and we have another set that is reserved for critical infrastructure.
The current text of Section 8, our transfer policy, does not distinguish whether or not this applies to all address space. It doesn't prevent these reserved blocks from being transferred to a third party that doesn't satisfy the original requirements that were placed on the original recipient of this space.
So there are a couple of issues here. First, the space was reserved for a specific purpose. And is able to move to another party that doesn't fulfill those original requirements.
Also, specifically with the 4.10 space, the address ranges that are reserved for v6 transition, transferring this space out of the region could complicate the single aggregate from which we're asking providers to let in announcements of smaller than a /24.
So this is a pretty simple policy proposal here. We will be -- we would be adding to Sections 8.3 and 8.4 text that prevent these address changes from being transferred.
One thing to note here is that this wouldn't be -- this wouldn't affect Section 8.2 transfers, M&A transfers. You could still transfer this reserve space as a part of an M&A transaction. So we would be just adding text to the bottom of the 8.3 and 8.4 that says address resources from a reserved pool, including those designated in Sections 4.4 and 4.10, are not eligible for transfer. And this same thing would be added to Section 8.4.
So we want to hear some feedback from the community. What do you guys think: Should we support preventing the transfer of reserve pool address space via 8.3 and 8.4 transfers.
Paul Andersen: Thank you. Thank you, Amy, here on our last Draft Policy of the meeting. Microphones are open. As everyone says: Lunch tastes good, but policy is better.
Scott Leibrand: Scott Leibrand, ARIN AC. I'd like to bring up for discussion of the group a modification that was proposed on PPML by Gary Buhrmaster and some revised text that I generated from that, specifically that we -- instead of disallowing transfers from these reserve pools entirely, we require that the recipient of any transfer from the reserve pools also meet the requirements of getting space under the reserve pool. So the text would just add that those recipients must qualify for those resources under the policy criteria for that reserve pool.
I personally believe that that would be a better structure, because it is possible that there are organizations which may be restructuring or otherwise changing in such a way that they want to use Section 8.3 or possibly 8.4 to transfer addresses that they control that happen to be under these.
And currently Section 8.3 is a very effective way to get addresses from one organization to another, even when it doesn't exactly qualify under 8.2 M&A. This would disallow that for these blocks. If the recipient organization intends to use them in the same way that the source organization was using them, I believe it would be more appropriate to allow that transfer but simply to require that the addresses continue to be used for the purposes of the reserve pool from which they're drawn.
So I would like to put in a plug for that, but also, more importantly, to get feedback from people in this room to see if it's an improvement on the policy or not. We haven't heard anything on PPML for or against that. I'd like to hear more dialogue on that.
Paul Andersen: Don't run away. Amy has a question for you, and then I have a question for you.
Amy Potter: Thank you for your question. Would you want that to apply just to 8.3 transfers within the ARIN region, or are you suggesting that also apply for 8.4s?
Scott Leibrand: I can't think of a good way to make that work for 8.4, so I'd be fine with it only applying to 8.3.
Paul Andersen: Keep trying to run away from me. But even without that change, would you be supportive of this policy?
Scott Leibrand: I'm undecided at this point, but leaning towards supporting it.
Paul Andersen: Thank you. Front microphone again.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I support the policy as written. I could live with the change that Scott's proposing or that Gary proposed and Scott is expressing with some limitations or modifications to it.
Basically there's three categories of utilization of the reserved pool space that come into play: DNS operations for root and gTLD zones, and primarily traditional gTLD zones, not the new "I can make money fast" project; and the deployment of exchange points being the second category; the third category being the 4.10s, the transition space for v6.
I can't imagine a scenario in which an 8.2 transfer would not suffice but we would still want to allow the transfer under that category. So I'm kind of disinclined towards supporting that.
And then in the case of the exchange point, you're either continuing the same exchange point operation, in which case 8.2 makes perfect sense, or you're not, in which case I'm not sure we want to allow the transfer. And the same would apply to the DNS operators.
So I'm not sure I see the need for allowing transfers on this stuff, even in those limited circumstances. I'd much rather see if the original need for the space no longer applied, the space should go back to ARIN.
I think this is one of those few cases where we've got a clear-cut case of relatively binary either you still need the space for the original purpose or you don't. And if you don't, you should return it to ARIN. It's not a matter of incentivizing you to renumber into something else or anything else like that that the current 8.3 and 8.4 transfers are intended to enable.
So I don't think those apply. I think we're fine without transfers. But I could live with a very limited set of transfer permissions, if that was necessary, to get the policy passed.
Personally, I prefer it as is.
Paul Andersen: Thank you.
Owen DeLong: Can I run away now?
Paul Andersen: You may, unless you want to bring your chair back to the aisle.
John Curran first.
John Curran: Briefly, just an informational point. We reviewed all 8.3 and 8.4 transfers done to date. Nothing from these reserve pools have been transferred via 8.3 or 8.4 transfer.
Paul Andersen: Useful information. Kevin Blumberg then Vint.
Kevin Blumberg: Kevin Blumberg, the ARIN AC and author of the proposal. This came out of staff or discussion clarification a couple months ago.
When I proposed this -- when I proposed this, I looked at the idea of allowing transfers and specifically excluded them.
I'd originally only included 4.10 because that was critical that it stay as a single aggregate, but felt that the reason for removing or not having transfers was the community set up the reserved pool to the detriment of the general population of the ARIN community. They did it because of the overarching benefit to the community to have reserved pools for extremely specific cases.
My concern with any transfer language in this is we're setting ourselves up for people coming and looking for ways to use the reserved pool while following the letter of the policy, not necessarily following the spirit of the policy and then looking at 12 months later affecting an 8.3 transfer, whatever the case may be.
If you need it, you should be getting it from the reserved pool. If there's a problem with the reserve pool, where we start running down on the reserved pool five or ten years from now, which is when we've recently looked at the projections, I think we can revisit it then.
But to open the gates before there's even a problem with transfers I think, like I said, sets a precedent and creates a situation that we will not be able to reverse from.
So I'd prefer not seeing it anywhere in the beginning.
Paul Andersen: Vint next.
Vint Cerf: Vint Cerf, Google. This is a question for Kevin. This scenario that I wanted to try on you is the positive case where the transfer is proposed and the receiving party intends to use those addresses for the purpose for which they were assigned to the reserve pool.
One scenario is it's returned by the transferring party to ARIN and then it is reassigned to the recipient party on the grounds that those are needed and they can justify it.
I was trying to figure out whether there was a case that you might worry about where the transfer takes place with the exception of these particular things. And somehow or other it's not possible to provide those addresses to the recipient party, even if they're needed.
But I guess you could make the argument if they go back to ARIN, the question is could they be snatched by someone else and then the receiving party, who intended to use those for the correct purposes, can't get them. Is that a scenario that we should worry about?
Kevin Blumberg: So in both pools we have thousands -- in the 4.10 we have potentially thousands upon thousands of available addresses that a party can come directly to ARIN and does not have to deal with the transfer market.
In the case of the critical infrastructure pool, can staff just clarify -- I believe there's been, what, six critical infrastructure or eight critical infrastructure assignments in the past year, somewhere -- under 10. It's a very small number.
Based on that, we have 10 to 15 years' worth before transfers even becomes an issue.
Paul Andersen: Thank you. Front microphone, then remote participant. Sorry, Vint, you -- no, we'll go front microphone, then remote participant.
Andrew Dul: Andrew Dul, ARIN AC, the secondary shepherd on this policy, but I'm speaking as a community member on this at the moment.
I think we don't necessarily do ourselves a service by creating second classes of addresses that are now nontransferable. We have gone down the road where v4 addresses are transferrable. And now making a U-turn and putting some in a box strands them and doesn't keep them from actually being used in a way that possibly could be useful.
I see very little downside, personally, to allowing these transfers to occur, if they actually do occur. They haven't to date. I suspect they might in the future. I don't actually think that that would be a bad thing.
Paul Andersen: Thank you. Remote participant.
Scott Leibrand: Scott Leibrand. Follow-up question for Andrew. Are you referring to opposition to the proposal as written and wanting to allow transfers of reserve pool space to people, to just anyone, or are you talking about my suggestion of allowing it to people who qualify for the conditions of the reserve pool?
Andrew Dul: I don't think we should be putting more restrictions on transfers. So I'm opposed, I guess, to both of those criteria as they are currently expounded on.
Paul Andersen: Thank you. Remote participant, John Springer?
John Springer: This is Christoph Blecker, the Walt Disney Company: I support the policy as written. I would be okay with Gary's/Scott's amendment for 8.3 transfers as it requires the same reserve requirements be met. I agree with Owen in that I don't see many cases where this would happen, and I don't think it would be that harmful if the same reserve pool needs are met.
Paul Andersen: Thank you. Weren't you just there? But before I do that, the microphones are going to close in a minute. Unless we see people. So if you'd like to speak, please approach a microphone. Rear microphone, please.
Jason Schiller: Jason Schiller, Google, ASO AC. I think it would be a travesty if addresses that are reserved for specific uses, because those are so very important, such as core DNS servers or critical infrastructure or v6 transition, be allowed to be transferred and used for business as usual. I think that would be terrible.
I think we should address that. I'm not sure whether I like the as-written proposal or Gary's amendment better. And part of me is debating on whether or not we could combine the two and make it such that transfers from the reserve pools are not permitted until the specific pool is empty, at which time transfers are permitted only such that the recipient meets the requirements of the pool.
Paul Andersen: Vint, did you want to address that?
Vint Cerf: Only to ask -- sorry, Jason -- if what you just said were taken literally, does that mean that some of the reserved addresses would just stick somewhere and not get used at all for their purpose and yet would accumulate a collection of unused addresses? It would be better if they ended up back in the pool or got transferred to someone who is going to use them for the same purpose.
So I think -- if I've misunderstood what you said, you should correct me, but it sounded like you didn't want to do the transfer, but then you just left them stranded at the source, which was prepared to transfer them but wasn't allowed to do so under your rule. So can you help me with that?
Jason Schiller: So the thought was the source would return them to ARIN, ARIN would reclaim them, they would sit in that reserved pool, and anyone who needed space out of it could get them back out.
But I think you do point out a very good point, which is does such a policy incentivize people that are holding this reserve space to not return it and to wait for that pool to deplete so they could transfer and monetize it.
And I think you're right in pointing that out. That probably is a problem. So I think we should probably either not allow transfers or allow transfers from day one.
I withdraw my --
Paul Andersen: Amy would like to ask you a question. All right. The question was resolved in the closing moments of your comment there. So thank you.
Anything, John Springer? Just checking in. Excellent. Front microphone, please.
Gary Campbell: Gary Campbell, Jamaica -- government of Jamaica. A quick question. If support were to be given to that policy provision, would any provisions be made for exceptions in the sense that would it be a case where everybody would be subject to the same terms and conditions, or would it make some special provisions for maybe special cases?
Paul Andersen: John is going to address that.
John Curran: So unfortunately the way the policy manual is written, we actually have to follow it pretty much verbatim.
There's a few areas where the community has specifically given us leeway, but with respect right now, presently these transfers would be allowed. If someone showed up with transferring this special space, we would be remarkably flexible because we're not prohibited from doing so. If this policy is adopted, because it would -- as written it would say we cannot do it, there would not be exceptions. We would be prohibited from doing so.
Paul Andersen: We've got a question here for staff from Amy. And after that we are going to close the queue. Now is your last chance.
Amy Potter: My question for staff is how often are we seeing people return reserved pool space freely on their own? Is this something that's happening on a regular basis or ever?
John Curran: To my knowledge it hasn't occurred. Give me a minute, please.
Paul Andersen: We will check on that. While we check on that, let's go to the remote participant. And the microphones are now closed.
John Springer: Sandra Murphy, Parsons: I support this policy, especially with Gary/Scott's amendment. The reserved pool was instituted to meet a particular need. Allowing transfer would permit elimination of the address's availability to meet that need. When the general pool is depleted, this could be readdressed.
Paul Andersen: Thank you.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I don't see any need for exceptions. And in terms of allowing transfers when the pool is depleted, we've got lots of time to decide that we want to start allowing transfers within this space when the pool is depleted well before the pool gets depleted.
We've got many, many, many policy cycles. If history has taught us anything, it's that looking that far ahead we are blind. And so I would not advocate taking an action now to deal with something that will happen so far in the future, because we almost invariably get it wrong. And why take another opportunity to get it wrong when we can wait until we have a higher chance of getting it right.
Paul Andersen: Still in favor?
Owen DeLong: As written.
Paul Andersen: Thank you. Double-check to see if John might have had his answer yet.
John Curran: A quick check says we're unaware of any circumstances where reserved space has been assigned. We will confirm this, but the answer appears to be it hasn't.
Paul Andersen: Final comment at the rear.
Aaron Hughes: Aaron Hughes, 6connect, ARIN Board. Just want to remind of one particular use case, which is for the v6 transition purpose. If a new organization starts v6-only infrastructure in the ARIN region and needs unique identifiers for loopbacks and protocols and the company gets acquired by another region, they're not going to renumber those interfaces. That would be a significant cost to the organization and may break the deal for an acquisition.
Paul Andersen: Okay. Thank you for that.
So did you have in your mind before or after I closed the queue?
Kevin Blumberg: It's direct response to Aaron. Aaron, 8.2 mergers and acquisitions are excluded. So if an organization was in that situation, that is allowed. This is -- only transfers to -- for in 8.3 or -4.
Paul Andersen: With that, we'll close the discussion. Let's thank Amy for the presentation assistance.
Paul Andersen: We'll now move to our poll. This is the last poll, so let's try to get heavy audience participation. The polsters are ready.
The question today on the matter of 2016-1 shall be: Are you in favor of the Advisory Council continuing to work on this proposal? Those that are in favor, please raise your hands nice and high. Come on. You can lower your hands.
For those opposed, raise your hand nice and high. Thank you.
One moment for the results. Thank you for your participation in the policy processes for this meeting. Always lively.
I'll use the silence to say I would like to thank the ARIN staff for the wonderful social. Did not everyone have a great time? Let's give them a hand for that.
Paul Andersen: Thank you, sir. On the matter of 2016-1: Reserved pool transfer policy, we have 86 people in the room, four remote. That's a total of 90. In favor, 28; against, love. Or nil.
This will be provided to the Advisory Council. Back to John. Thanks.
John Springer: Question from remote.
John Curran: We're getting back on track. We're going to pick up from the global reports. The one we didn't get to --
John Springer: Question from remote. Sandra Murphy, Parsons: John Curran sounded like he said, quote, not aware of any circumstances when reserved space has been, tick, assigned, close tick, period. Really? Transcript has not caught up. Think I either misheard, or he meant returned --
John Curran: Sorry. That's my high-speed Boston speaking combined with the valiant efforts of someone to keep up doing the transcript. Let's try it better.
Staff has looked. To our knowledge we are not aware of any of the reserve space being returned.
John Curran: So we're going to pick up where we left off. The one global report we have not had might be the most important one. We'll have Selina come up and give the IANA global report.
Selina Harrington: Hi. My name is Selina Harrington, and I am an IANA specialist at ICANN. And I'm here today to give a brief update on recent activities in the IANA department at ICANN.
Four of the topics that I'm going to touch on today are the annual customer service survey and some of the changes that we've made based on the feedback we received from the survey. Also talk about our audit and our IPv4 recovered pool allocations.
So our 2015 customer service survey. It's a survey we've done annually since 2013. Last year we sent 16 invitations to the RIRs. We sent them to the CEOs, the Registration Service managers, and also some other staff members who had submitted a request to us throughout the year.
Out of the 16 that we sent, we received seven responses, or 44 percent. Which is pretty good, but we'd like to get that higher on our next survey.
And overall the results were pretty good. As you can see, there's a lot of green up there, a lot of satisfied and very satisfied feedback. But we did have one person, who is that 14 percent there, responded that they were dissatisfied with the quality of our instructions.
And this is an anonymous survey, but that person did come to us to explain a little bit more about why they were dissatisfied. And it was because on our website in the numbers -- on the numbers page of the website, there weren't any instructions about how to submit requests for number resources or a link to the pages that we did have set up with those instructions.
And if you had looked at our root management page, we did have guides and instructions on that page for routine change requests, delegations, re-delegations, and we needed to do the same thing for the numbers page.
So we went ahead -- let's see -- and we added it. This is just a screen shot of the main numbers page on the IANA website. And underneath the IPv4, IPv6, and AS number sections we added a link to our procedures page.
And that link takes you here where, depending on what type of resource it is, you can find the instructions for how to submit your request to us -- what email address to send it to, what template to use.
I also wanted to briefly talk about the audits that we do. The audits that we do are service organization control audits, and we recently successfully completed two of them -- the SOC3 audit of the root zone KSK system, and the SOC2 audit of the IANA registry maintenance system, which are like our ticketing system, which is our T, or our RZMS system, which is our root zone management system, that we use to process requests for top-level domain managers.
These audits are conducted annually. The SOC3 one, this is the sixth consecutive year that we've completed it, and the third consecutive year for completion of the SOC2 audit.
And what these audits are focusing on are the availability of our system, the processing integrity, and also security.
If you want to find more information about the audits and reports that have been posted, you can find that at iana.org/audits.
Finally, this is a really bad slide because the print is tiny, but this is our most recent allocation that we made from the IPv4-recovered address pool. Somewhere in the middle there you'll see where ARIN is.
If you don't know, a few years ago address space was returned to us by a few of the RIRs, and we created a recovered address space registry. And then starting in 2014, I believe it was, there was a global policy that requires us to make allocations to the five RIRs every six months, at the beginning of March and the beginning of September.
So our most recent allocation was on March 1st. And each RIR received the equivalent of a /15. The next one will take place in September. These are a few links you might find interesting. There's a link to the registry itself, the global policy, and there's also a GitHub link where you can download the command line tool that we use to determine what the allocations will be to each RIR.
I downloaded that and ran it over and over again to see when our last allocation will be made from this pool. And if nothing changes, if no additional space is returned, nothing changes to the policies, the last allocation will take place in March of 2019. So in three years.
At the most recent APNIC meeting there was a question about, well, how much address space would you need to allow you to basically drain the pool at the September 2016 allocation, our next one.
So we looked into that. And we would need an additional 1,792 addresses, which is I think seven /24s. And if we receive that, then we would just have one more allocation and each of the RIRs would receive a /17 in September.
But as of right now, it looks like we'll have six more allocations and finish up in 2019.
And that's all I have today. Thank you.
John Curran: Any questions?
IANA Transition Panel
John Curran: Thank you very much. Lovely. We are back on track. We've had our presentations. Next up it is time for the IANA Transition Panel. And so it's going to be myself and Ron and Milton, and the others on the stage can escape for a moment if you wish. You can stay up here if you want. The panel's myself and Milton and --
Vint Cerf: There's room for everyone.
John Curran: Right. There's room for everyone.
John Curran: So I'm going to start off. We're going to talk about the IANA stewardship transition, and this is an interesting topic.
As I've said earlier today, the IANA is something that has been done under the auspices of the US government. The US government has had a contract for some time -- NTIA and the Department of Commerce has had a contract with ICANN since its formation for ICANN to provide IANA number services. And about two years ago the Department of Commerce issued a statement saying that they would be willing to transition their role, the role of the stewardship over this, to the global Internet community and instead arrange -- have the global Internet community, each affected community, arrange itself for providing the IANA numbering services it relies on.
I'm going to talk about one piece of that. I'm going to talk about, with respect to numbers, the registries that we just heard about. I'm going to talk about the arrangement that will exist between the RIRs and ICANN at the point in time when it's no longer being done under the IANA functions contract from NTIA.
So this is going to be the IANA Numbering Services SLA presentation. And let me just do the quick introduction.
So the SLA for the IANA Numbering Services, agreement for the provision of IANA registry services for the global number resource registries. This is the top-level registries, the free pools held by IANA, of IPv4, IPv6, and the ASN registries.
The principles by which this agreement were written was specified by the CRISP team. The CRISP team we heard about earlier. It was the consolidated RIR team that was responsible for proposing the plan of the transition.
Not only did they propose a plan but they also gave us principles to be used in drafting this agreement. And each of the regions had three representatives, and they came up with this plan that is part of what's being submitted to the US government.
So presuming that plan's adopted, we'll need to have an agreement that matches the requirements, and the requirements called for an agreement between the IANA Numbering Services Operator and the five RIRs. The five RIRs would jointly contract for an IANA Services Operator who would maintain these central registries.
Now, ICANN has done an excellent job to date. We don't have a lot of requests. We have a handful of requests every year. And they do a great job, as you can see by their satisfaction reports we just heard about.
The CRISP team proposal called for the IANA, based on its performance and stability, to be the IANA Numbering Services Operator. So we've been working, the five RIRs have been working, with ICANN for a contract for it to continue to provide these services under the RIR contract as opposed to under the NTIA contract.
So the drafting was done by the RIR legal team. We had appointees from the team coordinated with the CRISP team to review the work, to see if we were matching it appropriately. Public comment periods were done after each draft.
Now, the plan was actually done, the CRISP team plan was done in -- by January 15th, 2015. So we actually had the first draft in May of last year. Had a second draft in August. Had a third draft in October. Each one of these had a public call for comments. Each one was posted to the Mailing List. This is the IANA discussion Mailing List.
We're up to our fifth draft. Fifth draft was released on the 18th of March. And ICANN actually worked with us on the last few drafts, getting them closer to their expectations. And the final version is imminent, like I hit refresh before I stood up here. It's still not out, but today or tomorrow we should have the final version, meaning we're satisfied wit. ICANN's satisfied with it. It's not significantly different, actually, from the fifth draft. So people shouldn't be surprised.
But this has been a very public, very incremental process. Let's talk about what's in the proposed SLA. It's a five-year agreement with automatic renewal. So the RIRs by default have a five-year agreement with ICANN as the IANA Numbering Services Operator for ICANN to maintain these registries.
Something you should know. I'll say it only once here. The IETF has a similar relationship. They have an MoU that they want to enhance with ICANN for ICANN to provide the service to their 2,000 registries that they have. The IETF has a lot of protocols. Protocols have registries. They have a lot of them.
So we have our six registries and the IETF has its handful. The names community is organized within ICANN, has ICANN help coordinate that, has ICANN doing the IANA function. So it turns out we have one body doing all of this. It's problematic.
So they actually ask that ICANN break off the IANA team into a separate wholly-owned affiliate. And that will be called the PTI, Post Transition IANA. And the PTI is actually what the names community is contracting with, via ICANN, contracting with PTI to do its registries. The RIRs are going to contract with ICANN, and ICANN we're going to let subcontract with PTI because it's wholly-owned, not a big difference.
But I want to say we actually have an agreement with ICANN specifically. We'll have a right not to renew. If we decide we want to have another operator, we can within 12 months -- as long as we give 12 months, we can let them know we're not renewing.
It has -- that might be something to go for if we decided we wanted a different performance or we wanted some other operator. By default it does renew automatically. Everything's going smoothly, let it keep going smooth.
It has a right of terminate that doesn't require getting to the end of the term. You can terminate because you need to terminate for failure to perform. It's a whole process for discussing lack of performance and escalating lack of performance and having senior discussions about lack of performance and having mediation and having arbitration.
The fact is if there's nonperformance, there's a right to terminate. There's obligations for best efforts and cooperation in transition to a successor. If -- no matter why we're leaving, if we're moving to another provider, the IANA Numbering Services Operator will be obligated to facilitate that transition. Even if we're leaving, they have to facilitate the transition.
This contract was written, in a way, generically. We wrote it as the contract we want to use for the IANA Number Service Operator regardless of who it is. But on the other hand, ICANN has been doing a great job, and they were very helpful in working on this agreement. So it's fortuitous because the paying contract we're going to use with ICANN, if we ever did have to use someone else, would be very easy to do.
The agreement looks to be signed in the May/June timeframe. Other parties on the panel will talk about that a little bit. There's language in it that says we're going to sign it but it won't do anything. I love contracts like this; you're signing it and it doesn't do anything.
The term is condition precedent. And what it says, until this condition is met, the paper has no effect. It's meaningless.
The condition in this case is ICANN released from its NTIA IANA functions contract. So when it's released from doing it under the contract with the US government, then the contract is in full force and then they're doing the same function only under the contract with the RIRs.
That's it. I'm going to hold questions actually because we have two more panelists. When we get to the end we can do all the questions at once. So Ron or Milton? You want to come up here or do it from there?
Milton Mueller: So I can control the slides with this? All right. So why are these people smiling? Well, first reason is that this was taken before they did all the work to develop the transition proposal.
Milton Mueller: The second reason is that this could be considered a Constitutional convention, a Declaration of Independence kind of -- if you want to use an American analogy -- meeting in Philadelphia in 1776 and deciding to actually separate the Internet and its governance from the United States government sort of legacy control, if you will, over the IANA functions.
Now, this process was very complicated, and John gave you a great deal of detail about the numbers part of this. And I'm going to give you the bigger picture. So you had actually two groups. This is the what was called the ICG, or the IANA Stewardship Coordination Group, and it included ultimately 30 members from the different parts of the community including names, numbers and protocols.
And one of the smartest decisions they made was to break down the process of developing this transition proposal into three distinct parts. So they said to the numbers people, you form your own committee, which turned out to be CRISP, and you tell us what you want done with the numbers IANA, the numbers parts of the IANA.
And they told the names IANA to develop their own proposal as to what to do with the root zone of the DNS.
And the protocols IANA, of course, was somewhat autonomous to begin with, but still had to formalize it so the IETF working group IANA plan was in charge of that process.
Now, everybody realized that the special US government role was not really a technical part of the thing, but it was more of an accountability check.
And many people were nervous about turning ICANN completely loose. So in addition to the transition, the stewardship transition over IANA, there was a recognition that there had to be major accountability reforms in ICANN itself. Primarily ICANN as DNS policy maker, but some of the functions of ICANN extend into numbers quite a bit. Although they have less directly to do with protocols.
So you have two distinct committees working on that. The Cross Community Working Group on Enhancing ICANN Accountability consisted of five different members from each ICANN supporting organization and advisory committee and basically turned into or evolved into a fairly open working group in which people would join into discussion as individual participants.
Now, of course, you could probably -- you probably could have predicted that of these three distinct proposals -- I'll ask you all to guess, which one took the longest, was the most complicated and most contentious?
Names. Yes, you got it. No doubt about that. So when we say that this proposal was finally turned in as complete by March 10th, 2016, you'll remember John telling you that the CRISP proposal was pretty much ready in January of 2015, and the IANA plan proposal was also ready by mid-January 2015. So the rest of that time was consumed by the accountability reforms of ICANN itself.
That was a very interesting process. I won't go into the details about the structure, but essentially they created what's called an empowered community, which has a number of enumerated powers over ICANN such as removing individual board members, firing the entire Board, approving fundamental changes in the bylaws, and other kinds of conditions and certain other enumerated powers.
Another important part of this accountability reform was to limit and define the mission of ICANN in a fairly narrow fashion so that ICANN is not supposed to stray from that mission. And they created an appeals process which is more effective and more accessible than the last one.
So now the question is we sort of have the proposal finished. It's been sent from ICANN to the NTIA, the US Department of Commerce. Actually, what we're doing now is we have lawyers working on drafting bylaws that reflect the exact intent of the proposal drafters.
Of course this can be very tricky because if you draft it wrong, you might create rights, obligations, or processes that have unintended consequences. So this process again is dragging on a bit as there are debates and discussions about how well the language is being translated into the actual bylaws that will be adopted by ICANN.
Now, this was the -- I started preparing this presentation last week. This schedule is now obsolete. It has been pushed back at least a week, I think, but as you see, we were supposed to be done with the drafting of the bylaws by tomorrow, and they were supposed to be posted on the 20th of April.
I think we're going to miss that deadline, maybe. Maybe not. I've been looking at the list today, and we're still shooting some documents around and getting some approvals from various constituencies and working groups.
But in effect we are on track to give the NTIA something close to that six-month lead time that they said they needed to vet the proposal and get it approved by the various agencies of the US government.
So hopefully somewhere in the week of April 20th or 25th we will be seeing that final set of bylaws posted, and I would encourage you to look at that if you have an interest in this historic change in the ICANN environment and provide your public comments about what you think how well this reflects a proposal.
If there was any need for further modifications of the bylaws, that will take place near the end of May. And then the ICANN Board will finally approve these bylaws, and that will then go into this review by an approval by the US government.
As you know, people who were not completely -- well, a little bit of partisanship in the US government. So the transition was seen as an Obama administration initiative. So the people who were in the other party wanted Congress to have some kind of an approval authority over this transition.
So they passed this law as a budget writer, which prevented the NTIA from actually relinquishing its contractual control until the end of the fiscal year, which is September 30th, which is when the extended contract is supposed to end anyway.
In the meantime, after they get those final bylaws, the NTIA will look at the proposal, see if it meets its criteria. It will then have to probably go through some more congressional hearings. The first round of hearings which occurred immediately after the Marrakesh meeting in March. We're very positive. Not a lot of determined opposition, but there's still some rumblings among what I would call nationalist Republicans who are asking why we are giving up control of the Internet, why this might create risks that ISIS will take over the world or whether the Russians or the Chinese will control the Internet. Yes, they really are getting questions like that. I'm not making this up. I'm not sure how serious or substantial those objections are, but there are still some forms of opposition.
So with that I'll turn it over to Ron.
Ron da Silva: I'm Ron da Silva. For those that I haven't met, I'm group vice president at Time Warner Cable responsible for network engineering and architecture. I'm also on the ICANN board of directors, and it's in that capacity that I'm here with you today.
I want to come back to this. I know there was a similar slide earlier. But why is ICANN here? I thought I'd talk to that question by borrowing this slide.
And when John Curran talked about the five regional registries coming together to form the NRO, this unincorporated body, one thing they do is they appoint 15 members into this Number Council. And for John Sweeting, who was confused -- I don't see him, so he must be golfing --
Ron da Silva: In the ICANN bylaws there's defined this address serving organization. So what the NRO does is with this Number Council it fulfills what's described in the ICANN bylaws. That's why there are two different terms to describe basically the same function. And they're coming together to identify what resources they want to apply, and then with the MoU between the RIRs and ICANN they satisfy what's described in the ICANN bylaws as the ASO.
And a very important thing. I might be biased, but a very important thing that the NRO NC in fulfilling the ASO AC function is they appoint two of the ICANN board members, and these are your three lovely members of the NRO on behalf of the ARIN region.
And how that fits into the overall Board structure of ICANN is as follows. This beautiful, diverse picture of the Board, maybe it's reflective. I don't know. There is geographic diversity, gender diversity, ethnic diversity. Maybe the colors are appropriate.
What they mean is the orange people on here are placed by the nominating committee, and these folks can be from anywhere in industry or outside of industry, and really the nominating committee each year looks to add diversity and also fill in gaps in whatever the current composition of the board of directors has.
We have Lousewies that's here, also on the ICANN Board. She's one of these orange people. Ironically you're wearing orange. And you're Dutch. I don't think the other seven are Dutch.
So each of the supporting organizations, they're listed there in the next column, if you look at this chart and follow with me left to right. The two yellow people -- I guess I'm yellow -- are Seats 9 and 10 and appointed by what I just described in the NRO NC. And that would be yours truly and Kuo-Wei. And the ASO AC or the NRO NC is currently looking to fill the 10th seat obligation.
Kuo is stepping down, so he won't be seeking another term. Obviously there's some discussions and a process around how they're going to make that selection. I think you heard about that already.
Then the other two serving organizations, the green people and the blue people there, are the country code folks and then the general names folks. And then one other one is the at large.
Really if you take the eight plus those seven -- so eight orange people, six down the middle, that one blue guy -- that's 15 voting members of the Board. That's really the meat of the Board. If you add to that our CEO, we have 16 folks who are authorized to make decisions on behalf of the Board.
In addition to those 16, we have four liaisons that are appointed from various bodies. The Government Advisory Committee within ICANN has a representative on the Board as liaison. And the Root Server Advisory Committee and the Security and Stability Committee, each of those have additional seats.
Lastly the IETF has a seat. So all that, 20 folks. I was practicing some of this at lunch with Cathy. I hope it's now more clear. Yes? Good.
A quick shoutout to the rest of the ICANN folks here. I mentioned Lousewies. Albert isn't here. And Joe is over here, and Alain is over yonder. And you just heard from Selina on the IANA update.
Why ICANN? I get this question. Why in the world would a numbers guy want to subjugate himself to lots and lots of names-related policy and activity?
And for me it's just -- personally it seemed like the right thing to do. I spent six years here in this community on the Advisory Council. I chaired it, vice chaired it from a number of years. From 2010 until the middle of last summer, I was on the ASO as a member of this community and in that capacity was able to see what the global development policy process is for the numbers folks. Prior to that, in the AC, definitely helped shepherd through a lot of the policy here in this region.
A natural segue for me when I learned that Ray Plzak was stepping down and was vacating Seat No. 9, I stood and raised my hand and said, look, I'd be interested in doing this. I think I bring some unique perspective not only being in this community active in the Policy Development Process but then also in my day job, in my professional capacity as an executive at a service provider in private industry. There's a lot of other things that I can bring that's unique and different than the rest of the population of the current Board. So the community agreed, and here I am.
Now, what I wanted to get out of it, I was very interested in, okay, I understand what happens in the numbers space. What do these names people do? How do they, in fact, implement and identify and pursue their policy process around names?
And then those five years that I was on the ASO -- there was also a little bit of a selfish interest in here -- I got to go to a few of the ICANN meetings. It was actually quite delightful going as a numbers guy to an ICANN meeting because the content, if you look at it, some of it is interesting --
Ron da Silva: Which meant if I'm in some new interesting city, I could go take an afternoon, maybe go play golf with John -- he's still not here -- or get a little tourism in or a little shopping, see the local culture, enjoy some of the local cuisine.
In my fantasy I was thinking: This is great. Joining the Board means I'll go to all three of the ICANN meetings every year and see interesting places and enjoy different pieces of culture that perhaps I wouldn't see otherwise.
This is my schedule from Marrakesh. So I took out all my personal stuff. And this was just a little bit of work that survived and all the Board-related things going on through the week.
As you can see far left there, Wednesday arriving, before the meeting even started, and then leaving Friday at the end of the week.
Nevertheless, I didn't really see anything in Marrakesh other than the inside of conference rooms and every night got on a bus and went to some random restaurant where I had the same food I had the night before. The cuisine is great like one night. Second night it's okay. By the sixth or seventh night, I really didn't want it anymore. So, yeah, why ICANN?
But let me talk a little bit about since Dublin what's happened. And TNID really is a reference to the social in Dublin that night, and Dublin was this great experience that the ICANN meeting coordinators put together. We had several of the bars set aside in the Temple district. You can kind of wander from bar to bar. And there was a number of folks -- a number of number folks -- that eventually convened later that evening in the Temple Bar. Had a great time having our party there.
Since Dublin -- that's officially when I was put on the Board -- a few things have happened. First, that's Goran Marby. I don't know if you had a chance to see him or meet him. This is our new CEO. He officially begins I think next month. He's on board and learning and training and whatnot, but will be in his official capacity starting in May.
So coming in October we had a lot of extra meetings, a lot of extra phone calls, a number of face-to-face interviews. We had to narrow down the list, and the Board had to decide on a final candidate and negotiate an agreement to get Goran to join and convince him to leave Sweden and come to LA.
Another interesting activity, which you heard somewhat from here on the panel, is the CCWG. But I thought I'd provide a little Board perspective. Because for me it was two- to three-hour calls two or three times a week at all kinds of squirrelly times of the day. Gazillions of emails with no practical way to stay on top of those and also still have my day job functioning. That kind of went on and on.
And then there was an interesting dynamic between the community really wanting to drive the process and the community really wanting to own it and be responsible for all the content and yet a desire to have the Board chime in periodically.
Every time the Board would speak up, we'd get criticized about meddling in the process; but then if we don't speak up, we're criticized for not adding an opinion. So this was a bizarre dynamic that lasted through until we got the transition documents done in Marrakesh.
I've also joined the Finance Committee. This is particularly interesting to me. I love talking numbers. I do quite a bit of it as my day job. And just brought into ICANN, they have some 350 people spread all over the world. Majority of them are focused on helping with the names Policy Development Process and burn through 120 to 150 million dollars a year on fulfilling their purpose.
Now, for the CCWG piece of that, there was some $25 million so far that has been spent to develop a couple of emails. And most of that you kind of split between legal fees from various parties involved and travel support and meeting support, translation support, documentation support. All that stuff adds up. I think ARIN spends quarter of a million dollars to have this meeting. Right? So think of having 100 of these meetings. That's the order of magnitude of expense that was spent creating some email.
And a couple of other items. So what else have I been doing? And on the Board we've been looking to kind of assign different roles in different areas of oversight for each of the board members.
One thing I'm glommed on to is really an area that prior wasn't really comfortable or was a bit foreign to me, and that's in government policy development. So that took me to New York for the WSIS meeting, and I've been trolling all the IGF activities. Have jumped into the human rights stuff just in time to hear this renewed interest in sexual harassment policy and all this stuff out of Marrakesh.
And then one of the things I was able to do, I think, supporting the numbers community is in Marrakesh was able to draw a little extra attention around getting SLA moved forward. So that was good to see happening.
And then lastly I think Milton talked about the bylaws. I'm part of the bylaws drafting team, which means I get to read yet more emails and more documents. So all that so that on March 10th Steve Crocker can send an email.
That's all I have.
John Curran: Excellent. Thank you.
John Curran: We've got time for questions, about 20 minutes on any questions on IANA Stewardship Transition, ICANN, the relations between the parties, NTIA.
A room full of experts. That's great. Okay. Seun.
Seun Ojedeji: Talking about transition. I just want to thank Ron for the representation. I think it's a very good report.
And I would like to ask that the board members consider visiting each of the RIRs once in a while to give these updates and for the RIRs in the different regions to also meet the ICANN board members representing them.
John Curran: I'm sorry, repeat that last part slowly. I didn't hear the last sentence.
Seun Ojedeji: The last sentence is it should be good for board members representing RIRs to visit the other RIRs.
John Curran: Yes, most certainly. And we do a bit of that, we strike a fine balance between how much time we spend visiting other RIRs, because obviously if all of us visits all of the other RIRs, then we incur 5X costs we don't want to incur.
But, for example, I've attended many of the other RIR meetings. And the ARIN Board makes it a point to have a Board meeting, often two, at most of the RIR meetings.
We welcome people to our Board meetings as well. So I think it's important. ARIN's practice with respect to the Advisory Council is the Advisory Council has to take and send two people from the AC to each RIR meeting to track developments, and we've supported that in the budget since that was their request. So we have pretty good cross-pollination, and we welcome the other RIRs to send their people this way.
Questions about IANA stewardship transition -- one down at the end. Go ahead.
Ron da Silva: I was waiting for the light. On the request about the Board participating, there's actually -- I didn't talk about this. Between ICANN and the RIRs, specifically the NRO, there's an intentional effort now to get on the plenary at the ICANN meetings an opportunity for the regional registries to have part of the plenary to talk about what's happening, and then, conversely, at the RIR meetings, I've been -- since joining, I've been trying to ensure we've got participation by at least some Board member at all the registry meetings.
So Kuo and Asha were at the APNIC meeting. Lousewies and I are here. Lito should be at the LACNIC meeting. I think George will show up in the meeting in Botswana. I think we have a couple of people lined up for Copenhagen.
So we're trying to do that and I think starting to see some success and having reciprocal time on both meetings.
John Curran: Okay. Alain.
Alain Durand: Alain from ICANN. I'm not from the Board. I'm from ICANN staff. And this year I made a point to go to all the RIR meetings. So I went to the meeting in New Zealand for APNIC. I'm obviously here. I'm going to the LACNIC meeting and then to the RIPE meeting in Copenhagen and then to the AFRINIC meeting in Botswana. Because it's important for us to engage the community and to work together.
Milton Mueller: John, I question about PTI. As you know better than perhaps many of us, the problem with the names community was it was essentially trying to contract with itself when it came to the IANA functions, and this whole idea of separability was difficult to achieve in that environment.
Now, what we thought was one of the big successes of the transition was that we pulled IANA out of ICANN into a separate organization, a legally separate organization, without making it completely independent. Although some of us advocated that.
However, some of us felt that was a bit undermined when the address registries and the IETF decided to continue contracting directly with ICANN because of the economies of scale and sort of having all the IANA functions in a single entity.
And the argument you made at the time as to why you were doing that was very good in the sense you'd be contracting with something that had no track record, didn't exist and so on, but down the road can you see -- as PTI becomes more established, can you see fitting in better with the model and having the address, the numbers community contract with PTI instead of with ICANN?
John Curran: Milton, if you think about it, early on the CRISP team came up with a proposal. And the RIR executives were not on the CRISP team, it was members from each of the regions that were appointed that served on it.
They came up with a model, and the model said if the goal is to replace NTIA's contract for the number portion of that contract, then the easiest mechanism to put in place is another contract but prefer the same thing with the same entity. In fact, the first few versions of the SLA actually had the entire NTIA IANA functions contract as an addendum for reference, because they wanted to make sure they covered everything in the present contract.
So when we were busy finalizing and cleaning up this, it makes perfect sense for the RIRs to contract with ICANN because it's presently delivering the service. It's also the entity, by the way, that has financial resources.
If you contract with a wholly-owned subsidiary that has no actual resources and no performance record and it fails to deliver, it actually has no resources with which to put in jeopardy. You've literally contracted with a paper tiger. And right now all the financial reserves that we would need, for example, if we needed help transitioning or needed to assert damages are all held by ICANN, not PTI.
So there was no reason to change what the community specified. There were good reasons not to change what the community specified. And while I recognize it poses some challenges for the name community, which is simultaneously organized by ICANN, contracting with ICANN and using the IANA services of ICANN, that doesn't seem to be the number of the IETF's problem.
I actually know of someone who proposed a model that might have clarified this. Early on in the CWG effort there was a proposal for, like the IETF, a distinct entity or the RIRs collectively as a distinct entity, that there be a distinct entity for the names community.
If you had that, it could do something really innovative. It could contract with ICANN, just like the other two communities. That proposal, it was one of the professors of -- I can't remember. Economics? Could you -- who gave that -- actually it was you, Milton, who made that proposal. Unfortunately, that wasn't the path taken. So I'm sorry that the output is convoluted, but it is a self-inflicted injury on the communities that are not self organized.
Milton Mueller: But all the arguments you made are absolutely correct about the short term, but I'm saying five years down the road or if PTI has been performing and effectually it's a subsidiary of ICANN, would you contemplate contracting with it rather than ICANN?
John Curran: We have someone at the mic would you like to speak to that.
Bill Woodcock: Bill Woodcock, ARIN Board. I think it would be reasonable to consider all potential service offerers and could be particularly reasonable if they could see their way to charging less than the $300,000 per transaction that ICANN charges us right now.
John Curran: Front and center microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. There would have to be some benefit to contracting with PTI. And the only aspect of the numerous reasons not to that would change over the course of those years, as I understand it, from your description, would be they'd go from having no track record to having a track record.
But really the track record would just be that IANA -- that ICANN happened to continue to perform and PTI didn't have to do anything to ICANN to get them to perform. So I'm not sure it's a meaningful track record no matter how long it lasts.
No, I don't see any benefit to doing that. I don't see any improvement that comes from that. I think, as John described it, PTI is a self-inflicted wound on the part of the names community.
Milton Mueller: Just to clarify that. So my understanding is ICANN is going to subcontract the contract from the registries to PTI. And that PTI will consist of the current IANA department that has simply been moved into a different building and incorporated as a California public benefit.
It's going to be the same people, it's just that, I think John rightly says, in the current environment, if you want legal certainty and accountability, you have to contract directly with ICANN. But five years down the road I don't see why it would be the case. But I don't see why you'd oppose it either.
John Curran: If you want legal accountability and certainty, since accountability was a part of the process, that's the path we took. That's literally one of the key words we were seeking, so that's why we ended up that way. Vint, you wanted to respond.
Vint Cerf: Vint Cerf, Google. Milton, I think as long as PTI is a wholly-owned subsidiary of ICANN, I see no utility of contracting directly with it. If at such time ICANN can't perform its function under our contract with them and this function needs to be replaced by something other than PTI because for some reason PTI is not operating adequately, at that point then it's a very different ball game. But I don't see any utility, frankly in contracting with a subsidiary.
Alan Barrett: Hello, this is Alan Barrett from AFRINIC. On the issue of economies of scale and the advantage of putting all three branches of the IANA functions in the same organization, I think that is the plan.
We expect PTI to do all three parts of the IANA function -- names, numbers, and protocol parameters. Even though the contracts will be in different places, we expect the work all to be in PTI, and we do expect to get those economies of scale.
Seun Ojedeji: This is Seun. I went back to my seat after Vint made a comment, but I thought I'd come back and say something.
I think we need to clarify that ICANN having PTI as a subsidiary, ICANN still remains the sole member of PTI. So just to buttress what Vint said, it really makes no practical advantage if you actually contract with the junior instead of contracting with the senior.
John Curran: Understood. Would you like to respond, Ron or Milton? Oh.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I have a question for the panel. Yesterday Cathy Aronson did a great job describing the RFC to completely stop working on IPv4. In a similar vein, when can we look back on the IANA transitions in gleefully having been completed and done and what realistic timeline? Versus, you know, I realize that each person might have a different expectation, but realistically when do we expect this to sort of close out?
John Curran: Milton, would you like to answer that?
Milton Mueller: Supposed to be finished September 30th, 2016. That's when the current contract expires. If it goes beyond that, then you get into potentially another American presidential administration, which, quite apart from what you think of politics of any of the candidates, there's just a gap in these transition periods where nothing much happens and people are afraid to do anything. So you really want to get it done by the end of 2016.
John Curran: Vint?
Vint Cerf: You meant by the end of fiscal 2016, yes?
Milton Mueller: Right. September 30th is the end of the US fiscal year. That's when the NTIA can actually do it.
Vint Cerf: Except for one thing. The Congress has reserved the right to comment on this thing. So it's not 100 percent clear to me whether or not the sitting Congress in the US will actually respond even though it said it needed only 30 congressional days.
I noticed that this Congress is remarkably recalcitrant. For example, it doesn't want to consider a new Supreme Court appointee, and the committee that's responsible for that has asserted it refuses to consider anyone will refuse to meet. There's some high risk here, but that September 30 date may not transpire if this Congress fails to consider the proposal in a timely way.
Milton Mueller: Why, I'm surprised that Vint is so gloomy about these things. I think there's every evidence that there's bipartisan support for the transition within the Congress. There's, as I said, some nationalist Republicans who are raising questions, but they're not actively opposing it yet, as far as I know. And they seem to be in a minority.
But I think this is not a Supreme Court Justice appointment. Those people who have made ideological ideas on abortion or various other critical issues in US politics know that whoever you appoint to the Supreme Court is going to tip the court.
It's not clear that the IANA transition tips anything in any way that favors Republicans or Democrats. I wouldn't be making that parallel unless you are more deeply pessimistic about American politics than even I am.
Vint Cerf: So, well, I have to say, after watching the campaign in the US, I've been looking for property in Montréal --
Vint Cerf: Of course the recent Canadian elections make me think maybe I should move here to the Caribbean.
So now that I've insulted everyone in the room.
So, Milton, I think the worry I have is that there's a bunch of topics that are possible within, especially within, the senate to stop legislation and stop decisions from happening. And I think my worry is that there is a high element of politics behind all this.
The rhetoric you hear inflates this whole thing into a campaign-like altitude even though I agreed it shouldn't be there. But when people play politics, they'll take any excuse they can find.
So I think there's really work to be done. I would not be relaxed about trying to make sure that this decision actually happens in a timely way.
Milton Mueller: One thing to add there is that legislation is not necessary for this to happen. The little rider law that I mentioned does not actually require -- it does prevent the NTIA through the funding leverage from doing anything until the end of the fiscal year. If that were renewed, yes, that could happen, if there's a remote possibility that something like that could happen.
But unless you believe that the root zone is government property, which is an argument that we've I think pretty much shot down, if you look at the IGP blog or some other places, we've taken that and eviscerated that argument. So unless it's government property, you don't need congressional approval to transfer the control of it. It looks just like a contract to me. I think that's pretty much what it is. If the NTIA doesn't renew the contract, then it's done.
Vint Cerf: I'm sorry, we probably have to do this over a beer or something, but the thing is the current arrangement says that the Congress gets to look at and consider.
I mean the present agreement says they get to look at and consider for a period of 30 days. The problem is they didn't promise at the end of 30 days that they would say yes. So that's the part that I think is still at risk.
John Curran: Back microphone.
Seun Ojedeji: Thank you. This is Seun again. I just have two questions to the NRO EC. The first is just the -- is the NRO EC considering writing -- putting out a statement sometime in the future especially if there's a delay in the supposed -- pardon me.
If political activities taking up the process and it seems that a September date is not going to be realistic anymore, does the NRO EC or the RIR community, would they be considering perhaps but not restricting that this has to be something that needs to be done and we just -- yeah.
John Curran: I believe your question is what would the NRO EC do if the determination was made that the transition wasn't going to happen, would we contract and proceed in any case.
Seun Ojedeji: No, that's my second question. That is my second question. So the first is that --
Vint Cerf: Let me help, because I've got the headset on and I can hear you better than he can. This is great; the deaf guy hears better than everybody.
So the question is whether or not if it looked like this whole thing would not be approved by the Congress, is there any action that the NRO EC would consider taking in order to cope with that, and then the next question is would you do a contract anyway somehow.
John Curran: Understood. Recognize that you have attributed power to the NRO EC that doesn't exist. The NRO EC is actually five executives getting together trying to make sure that their staff work and play nice and also trying to make sure that the numbers only show up in one RIR at a time.
So we don't get to do anything that our boards don't tell us to do or that our boards have told us to listen to you and you haven't told us to do.
So the issue you raise is something that short of each RIR board making a determination to do something there would not be a coordinated effort.
I will say that it's important to remember something. ICANN has been doing a great job providing the IANA functions. A great job. That was confirmed in this process. It was reiterated. It's in the CRISP team plan itself. And if this transition doesn't happen, ICANN will continue to do its job. If this transition does happen, ICANN will continue to do its job.
You'll note the sentences aren't any different. It's very hard to say there's an urgent and pressing emergency regarding whether this happens or not.
Now, if it turns out that this does not happen for some reason, some of that would depend on what the reason is, but I would be talking to the ARIN Board going: Here's some things we can or cannot consider.
Here's some messaging we can send. Here's some people we can talk to. And we would talk to the other RIRs about that as well. But it wouldn't be a crisis that something is happening, it would be a, oh, wow, we put in thousands of hours of work as a community, tens of thousands, I believe, and we're not getting an output.
It would be a very, very significant event, but it wouldn't in and of itself be something that would require action before September 30th. What it would require is us to figure out are we willing to go through this some more, do we need to begin looking at other measures. It's not something you would ever have the NRO EC decide, it's something that each RIR community, your board at ARIN -- I mean, sorry, your board at AFRINIC, the board at ARIN, they would be weighing in to decide what's next here.
Go ahead. You want to continue, Seun?
Seun Ojedeji: Yeah, just a quick follow-up. By saying NRO EC, I definitely understand that you have to go through the community, but I'm just referring to the signature. Because you guys signed the letters, right?
John Curran: Exactly. Understood. Bill.
Bill Woodcock: I was going to say the first time this question came up was about a year ago when it started to become apparent that we weren't necessarily on track to make all of the deadlines and that that wasn't our fault and that we were done with our part.
And there have been several opportunities since then to take unilateral action and that the community, the numbers community as a whole has been unable to muster the agreement to do so. And while personally I think that's very unfortunate, I don't see that changing.
So the general attitude that, yes, well, the US government will get around to this eventually, we'll just wait for them, seems to be the one carrying the day. And I don't see that changing.
John Curran: To pick up on what Bill said, a lot of that, Seun, also relies on what happens. If there's a delay because there's an assessment being done and something is happening to that effect, then it is what it is.
If the answer is you need operational experience and all these new changes because at least one organization, ICANN, is going through some changes as a result of this, you could see the need that maybe you would need operational experience with the new structures.
There's things that would be we're moving ahead at a, some might say, excessively slow and prudent rate, but still moving ahead. That would need to be discussed by the community.
A different discussion would be no, having looked at this, having said we'll do it for the last 20 years, we've said now, no, we're not going to do it and the current structure shall remain in perpetuity, that would probably lead to a different discussion. We can't respond to what not getting it done by September 30th is until we know what the nature of what happens and why that delay or why that stop is happening. Understood?
Okay. Thank you.
Any other comments, last comments from the panelists?
Milton Mueller: I want to say I don't think there are any unilateral options. I don't see that being an option. It's not like people don't want that. If there were a unilateral option, we would have exercised it a year or two years ago. But there's a contract with the US government. When Jon Postel tried to take unilateral action in 1998, he was visited by the FBI, so the rumor has it.
So I think we just have to go through this process. And I'm not as pessimistic about this. I think the delays we're having are mostly about getting the stakeholders to agree on what needs to happen, and then the US government will pretty much approve what everybody is in favor of. And if they don't, there will be serious international consequences. And I just don't see the support for disrupting this process at this stage.
John Curran: Excellent. Ron, go ahead, last comments.
Ron da Silva: I certainly appreciate some of the sentiment around the risk that the US government could not act or act differently. I think absent that, it's certainly something that the industry can't necessarily control. Maybe impact, maybe affect, but not control.
I am happy to commend the industry as a whole that in spite of all those risks or perceived risks that we've still moved forward with an agenda. We've still moved forward with the process. We're on track, on schedule. Without any other foreign intervention, it should be done.
John Curran: Excellent. I'd like to take a chance to thank my fellow panelists, Ron and Milton.
John Curran: Now I have the good news. We have the refreshment break of the afternoon. We'll start promptly at 3:30. I'd like folks to run out, get the coffee, get your break, come back here 3:30 prompt. Thank you, everyone.
John Curran: Okay. Next up on our agenda is we're going to resume the afternoon's session. We're going to have Dan Alexander give a presentation on policy simplification.
Dan Alexander: All right. Bear with me through this presentation. I'm going to ask a lot of questions and offer fewer answers. But the hope is that this presentation will spur some new discussions.
Allocating resources from the v4 free pool was a primary function of ARIN prior to the depletion of the free pool. It wasn't the only function, but it was one that consumed a considerable amount of time from staff. The question then comes: What does the community feel are the important functions going forward?
There's many other topics to talk about, I mean, we could go on this topic for all day, but I tried to focus on three, and that's: Is there a different way to look at need? How do we get more IPv6 for small organizations? And with the upcoming fee structure changes, are there useful policy changes as a result of this new fee schedule?
The goal of this conversation is simply to drive topics to the Mailing List that could result in future policy proposals. I'm not recommending any specific language here. I'm only trying to gain some momentum around concepts that people could support.
And I'm also hoping to avoid what has happened in the past where we've sometimes run into the case where we end up with three or four policy proposals trying to solve the same problem and we kind of waste time debating the nine different ways to solve it.
And with that, I'm going to give you an eye chart. Where is -- sorry. I'm not keeping up with my notes and your slides. So I don't expect everyone to be able to read this one. It's more intended to download and zoom in on your laptop.
But what this shows is across the X axis there's 36 sections of the policy manual, and over the past 12 months how many of each section was used to approve all the requests that came into staff. It's divided up by v4 ISP and end user, ASN, IPv6 ISP, v6 end user, and transfers.
The numbers don't reflect every way a request could be approved. Sometimes a request could come in that could use several sections as justification for approval. But what staff typically does is whichever of the justifications are the most appropriate approval, that's the one that they use to base the decision on.
The one thing that jumped out at me when I started looking at some of this data is of the 36 sections, 18 of the least-used sections account for 2 percent of the approvals, where the other half of the 36 sections account for 96 percent of the approvals. If you narrow it down to the top nine sections, or 25 percent of these, that alone accounts for 85 percent of the requests.
Section 22.214.171.124, which is subsequent allocations for transitions, has actually been used ten times since it was implemented but zero times in the last 12 months. And 6.5.9, which is v6 for community networks, has never been utilized since it was implemented.
So we're spending a lot of time and effort debating need versus no need. There were four proposals submitted in 2014, six proposals last year, and there's three currently on the docket this year that are all addressing this conversation of need versus no need.
Is there a middle ground? Are there different ways to evaluate need for IP addresses other than the time-based utilization thresholds? 25 percent, 50 percent, 80 percent, one year, two years, 30 days.
We're spending a lot of time and resources going back and forth. To what end? The RIRs were managing the depletion of v4, but that work is for the most part completed. We need to answer the question as a community regarding what do we want the registry records to reflect.
When you look at just within Section 4, you know, can the distinctions between ISPs and end users be simplified? These are a number of conditions that are applied to both ISP and end users.
The distinction between ISP and end user services is understood, but do all these requirements still need to be applied to the different service levels that are actually offered by the registry? Some might argue that there's a fine line between trying to be responsible for the resources or are we deciding who is worthy.
Also in Section 4 there's a number of sections that may no longer apply, now that the free pool has been depleted. The retired sections have also been included in this simply to illustrate that we have done this cleanup work in the past. We have made a lot of changes over time as the policies have evolved.
And this isn't just about cleanup, but it's an evolution of what we're considering important under current circumstances. The policies aren't static, and their evolution doesn't have to go only in one direction.
When you look at Section 6, many of the same questions apply regarding the complexity of the requirements. Section 6 has 11 subsections, 24 third-level sections, 14 fourth-level sections, and three fifth-level sections. We're looking at Section 126.96.36.199.B Roman Numeral, you know -- we even have some sections that we're calculating N.
Now, to be clear, though, I'm not criticizing any of the previous policy decisions. These choices were made as circumstances evolved. They were a result of what the community was comfortable at the time. But we have to ask ourselves: Are we still where we were?
It was interesting because ARIN holds the ARIN on the Road events where they do the outreach to cities. They go around to cities where an ARIN meeting of this size can't always be held. So it gives the opportunity for a lot of people that don't normally make it to these meetings show up and find out more about what we do and have opportunity to ask a bunch of questions.
And I was at the one in Seattle, and I was struck by a question as an engineer got up to the mic. And he was like: Who is making all these arbitrary decisions and why? What is the difference if it's 50 percent or 60 percent, or 10 months or 12 months? What are these numbers trying to accomplish?
And it's really a very valid question. Are the requirements being defined truly serving the intended goals? So also we've got v6 coming on. A lot of people would argue it, but traffic's increasing quickly, and many small organizations still don't have an IPv6 allocation or assignment.
The new free structure that the Board put in place was an effort to fix some of the cost concerns, but we have to ask are there other policy changes that can occur to make it easier for small ORGs.
Staff presented this slide. And it's interesting because it's definitely trending up and it's a good thing. But it doesn't tell the whole picture, because once you dig into -- down into who actually has the IPv6 allocations, you notice that it's typically centered around the larger organizations, and the smaller organizations are still without IPv6.
So with the new fee structure that the Board adopted, hopefully that will help with a number of those issues.
But it also raises another interesting point in that end user organizations now get to choose the Registration Services plan and receive -- can receive the same level of services provided to an ISP. So they can get the additional ability to become a member, vote in elections and report reassignment information.
So I then always ask the question: If a network -- should the same network have different policy demands placed on it when the only difference is the level of services an organization is willing to pay the registry. Is there an easier way to do that?
So the question becomes how can we safeguard, how can the safeguards we're applying as stewards of the IP address better serve the organizations who actually want to use those addresses?
With that, I would welcome any questions or comments.
John Curran: Microphones are open. Yes, Vint.
Vint Cerf: Is your general proposal kind of a wholesale rewrite of all the rules be undertaken?
Dan Alexander: In the extreme case, yes, it would be, because I think anyone could argue that we're in a very different circumstance now as we have been over the last ten years. And a large portion -- as the eye chart shows, a large portion of the policy manual actually isn't even being used.
And the interesting thing is where it is being used, we have a number of all these like special circumstances, all these exception cases. Do we really need all those exception cases, or can we actually generalize the requirements for the resources to the point where one section could account for the 99 or the 100 percent of the requests.
Vint Cerf: Just as a thought experiment, I wonder what would happen if we wrote, just drafted for our own amusement, something that we would use solely for an IPv6-only environment and ask ourselves what does that look like.
I realize that's not reality. But if we did that, it might give us a clue as to what we might try to do with the residual v4 situation, which is more complicated for a lot of different reasons.
Dan Alexander: We've had similar conversations where -- along the lines of that exercise: What if we look at this, the Internet, 10, 20, 30 years from now, how should the policies be structured.
Jose de la Cruz: Hello. Jose de la Cruz, Internet Society, ARIN Fellow. I just have a question. The definition section, there is a definition for end user.
There's no definition for ISP. Is every user or ARIN client considered an ISP if they don't meet the definition for end user? That's number one. The second one is: Is the definition for ISP required.
John Curran: So if you look in the definitions, there is a -- where did it go? Okay. There's a local Internet registry definition, LIR. Amazingly, that's what we would call an ISP here. And an LIR is an Internet registry that primarily assigns address space to the users of the network services it provides. So in this region, if you are an entity that provides network services and you assign address space, you're an LIR, you use the -- we use the terms LIR and ISP interchangeable. That's where you'll find the definition.
Jose de la Cruz: Okay. Thank you.
Dan Alexander: Rear microphone.
Craig Mollerstuen: Craig Mollerstuen, United Utilities. I'd like to recommend, being a first-time user here, being a first-time attendee, what Vint was saying and what you were just saying makes a lot of sense. I'm an engineer by background and I'm currently a manager.
And I'm looking at your mission statement, because a lot of these same questions are coming up -- what are we trying to do? What is need? What is use? And a lot of them are tailored towards IPv4.
And I would challenge you to do exactly what you were talking about, which is to look and make a five-year plan and a ten-year plan and say when do we -- and you can't put times on them, right? But what has to happen before we retire these sections?
When you were having the conversation earlier about the reallocation of IPv4 numbers, I was thinking to myself: We're hitting that tipping point. I know you just had the graph that says small companies aren't going to v6 yet, but the big ones are and the big content providers are.
And I can see that tipping point, that fallover where the big guys, the Coxes, Comcasts and everything, are going to stop supporting v4 because most of the content their customers want are there and they're going to start returning IPv4 addresses and there's going to be a glut. And what are you going to do? You're going to need policies for all these returned and how your pricing structure is going to change and all of that.
So is it a lot of work? Yes. And could you spin a lot of cycles by trying to see too far into the future? Possibly. But your questions on what do we do, how do we simplify, I think with all of the bright minds you have in this room and in this organization, you can lay out a pretty good roadmap.
You've done an awesome job. I got into the Internet in 1983 as a user, as an engineer, as a manager. I've been watching from the outside. And you guys rock. You make all of our lives easier. Thank you for what you do.
And I challenge you to make your five and ten and 15-year plan. So thank you.
Dan Alexander: Thanks.
John Curran: One quick note you may not know. We don't do a 10- or 15-year plan because in the Internet that seems to be looking out at space so far away it's like looking for the death of the universe.
But we do a two-year plan. We do a strategic plan that covers the next two years. We also do financial planning. We've actually done financial planning out much longer. We've modeled -- and in fact the last fee schedule change, which set fees based on your v4 or v6 holdings based on the category that fits you, actually accommodates that full transition period back to IPv4 address return.
So the good news is this community doesn't really have to worry much about that, but do think about what you want the policy book to look like, what should the NRPM look like five years or ten years from now. Because it's quite possible, if you just incrementally change it to get there, you'll end up with a book several times larger than it needs to be.
Dan Alexander: Jason.
Jason Schiller: Jason Schiller, Google, ASO AC. I actually want to answer part of Craig's question. And I think when there is no longer a waiting list for unmet IPv4 resources and when there's no longer IPv4 addresses bought and sold on the transfer market, then we can probably dispense with a lot of the IPv4 policy.
I imagine at that time ARIN would have stores of IPv4 addresses more than there's demand for. And I think the thing that would be important at that time frame would be aggregation, how can we encourage people to give back what they've got to get a single block and to reduce the number of slots in the routing table.
Until that time, I think we probably need to maintain much of the IPv4 policy. I think that some of it is complex and we can simplify it. I think we can reorganize it to make it easier to read, more easier for people to skip the sections that don't apply to them.
And I think in a lot of ways we probably can bring some of the needs measurements of end users and ISPs in line with each other, just as we've done with the fee structure.
But generally I think we still need the policy and the corner cases that we're trying to protect, like critical infrastructure. That's still important, and it will remain important until IPv4 is irrelevant. We'll know when it's irrelevant when there's no longer a waiting list and there's no longer transfers. But I think that's not in the near future.
Alain Durand: Alain Durand speaking just on my own behalf, certainly not on any my employers', present, past, or future.
I've been here for a long time, and if I simply observe what's the purpose of the community, the longest time was to allocate services. When the free pool ran out, somehow need to reconsider what is the larger purpose.
That's why I really applaud your effort to look at this, step back and says what are we here for collectively. And when it is not about allocating addresses, what is it?
It's about, as you were talking about, maybe aggregation, making sure that the data that is there reflect the actual use of the database and thinking about who are the customers of the database, not simply does it reflect it according to how it's built but for people who are really using it. And keeping this in mind, while actually looking at those different policies, do they help or not.
Dan Alexander: Kevin.
Kevin Blumberg: So, Vint, you brought up a very important question or you made an important statement. And I'll remind everybody of the omnibus joke which is you never want to be thrown under the omnibus. And making radical, radical changes to the NRPM historically with the community hasn't worked.
That being said, when you look at the number of proposals that are now in the transfer -- that are now being done via transfer market that can be compacted down through a series of simplified policies individually just to look at them, yes, agree, move on, yes, agree, move on, I personally believe the community is more adept at dealing with small-bite-sized policies in that regard.
In regards to what Jason said with the waiting list, I think that's actually the gate in this whole discussion. We have to deal with the waiting list and this perpetual waiting list that is -- nobody's ever going to get off of because we're getting dribs and drabs back, almost nothing back, over the next five years.
So we're going to keep an entire Encyclopedia Britannica of policy for a /18 or 16 worth of space over the next five years.
I feel bad for anybody who reads the NRPM and is expecting that there will be space on the waiting list, that they will be able to get on the waiting list. So I actually consider the waiting list to be a detriment right now to policy. But I believe that we do have to address that to be able to really clean up the policy manual.
Dan Alexander: Cathy.
Cathy Aronson: Cathy Aronson, Kevin said a bit of what I was going to say. This is my 18th year on the ARIN Advisory Council, and the last big policy proposal we passed was the transfer policy which took endless amounts of time.
Anyway, I'm not really sure how in the bottom-up process -- how we rearrange this and get it passed -- get consensus. If people have ideas how we can accomplish that, it would be awesome. Because this needs to happen desperately. But I'm not really sure in my experience like how we make it possible. I'm just at a loss.
I think it's awesome that you're getting us all thinking about it and talking about it, but I -- I...
Dan Alexander: You touch on the -- you and Kevin touch on an interesting point in that the question kind of goes to this room and beyond is, do we want to continue taking these nibble-type bites at this problem or is the community ready for a big-bust proposal?
Cathy Aronson: The reason we have five levels of stuff is because of the bits and bites of little pieces of things that get tweaked and added. Anyway...
So anybody who has ideas for the AC on how we might accomplish this, that would be awesome.
Dan Alexander: We'll happily shepherd an omnibus.
Chris Woodfield: Chris Woodfield, Twitter. Sometimes it's useful to think of policy like this, look at it with a similar -- think of it as an analog to as one would look at, say, computer code.
All of these -- a code is written, inevitably bugs will pop up, and a lot of these additions and adjustments are in effect bug fixes.
So when looking at it through that perspective, a rewrite has very much a danger of losing the perspective and regressing, reducing a lot of those bugs.
One thing that might be useful is looking at some of the corner cases and finding out, okay, at the time this was introduced this was a problem. Are we now going to hit that bug again if we remove that bug fix. And in many cases that answer may not be no and that section can be cleaned up.
Something I randomly thought of is maybe a way of taking some of the more obscure clauses and marking them historic so they can be referenced in certain cases where the more general cases don't apply to a request but not part of the main policy possibly.
Dan Alexander: Okay.
John Curran: If you're going to be speaking, please approach the mics. I'll be closing the queue shortly.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC, but the radical comments I'm about to make are purely my own. And it's more really questions than any kind of firm suggestion, but I'd like to put it in this way.
So in my day job I do a lot of governance-related work, and I think what this exercise in this need is showing is that we have a governance challenge. And what I mean by that is that the systems that we've traditionally used, the PDP as it's defined today, isn't particularly well suited for a radical overhaul such as this.
Now, I don't know what the solution is, but one possibility would be to suggest some other temporary way of dealing with one omnibus change for this one particular need where you have to make such a global change.
And in other organizations, if you need to radically change the processes and procedures by which something is done, typically the Board would ask staff to come up with various options. Those would be considered, and staff would be asked to help in actually developing those options.
The reality is that no one member of the community is well equipped to do all of that. And if somebody came in with such a proposal, I'd be suspicious that it would be slanted perhaps with one organization's perspective. And that wouldn't be helpful to the community either.
So this is a big enough exercise. It seems to me we might want to think about it in a special way on a one-time basis and develop a different governance network.
It may be that we need a large subset or maybe the whole AC to take hold of this and as a group and work the problem.
It may be that we need staff's involvement to help with ideas for how the streamlining might happen. It might be the case that we might need their help with some of the initial drafting and then bring it back to the community for feedback.
And in so doing, we might want to adopt perhaps the approach that's been taken where we have some sort of fast track authorization so we can't tinker with it too much and end up disassembling it all at the end through too many cuts and bruises. I know it's radical, I know it's a big departure, but in answer to the question that Cathy posed, it's a governance problem.
And if we don't change the way that we apply our governance for such a massive exercise, I don't think we'll be able to do it.
And I've been thinking about this problem for two years ever since I joined the AC. Those will recall when I ran for the AC will recall that I was very concerned and wanted to promote NRPM simplification.
And, honestly, I've been banging my head against the wall of how to do that as an individual in the community. And so we need to think about this differently.
I don't know what that is. But that's my thought. Thanks.
Dan Alexander: I think it was Andrew.
Andrew Dul: Andrew Dul, ARIN AC. I want to disagree with Chris Tacit on this. I don't think we have a governance problem in terms of the PDP itself. I think we can do an omnibus through our existing PDP or a large-scale policy change if we don't want to.
But I think it needs -- for this to happen, we as a community need to put down our little knives or hatchets or whittles or whatever, when we have one of these, and realize we're not going to get everything we want when we take something from this and shrink it down to this.
From something large and shrink it down to something small in terms of text. So in doing that, we have to realize that the community has a responsibility to say I'm not going to get all of the corner cases and something that's smaller. That's just a fact.
And the AC has to say: We are willing to accept some level of people objecting to individual parts of this in order to reach a larger goal of simplification that makes it much easier for the community as a whole.
And I think this can be done for Section 4. I don't think this can be done for Section 6 for the IPv6 policy. But I think it can be done for Section 4. A number of us have done rewrites for Section 4.
We haven't published them publicly because we haven't felt there was a right time to do so. But if the community itself is willing to embrace that we are now in a different world, we're in a post-exhaustion world for our region, and that that takes a different mindset and that the corner cases that we used to have no longer matter in the same way that they did previously.
Dan Alexander: Rear mic. Jason.
Jason Schiller: Jason Schiller, Google. ASO AC. I think the approach to this that's going to work is for the AC to go through and clean up the text.
Do editorial changes, use consistent language, use consistent headings and how things are parsed out, go through and do a complete rewrite without changing any policy.
I think that's the first step. Try and clarify the language and shorten it as much as possible but still keeping it clear and still keeping the policy intact.
I think the second step is reorganizing the text to make it more easily personable. Possibly moving stuff, not to a historic document, but maybe to the end of the document.
Let's deal with the corner cases, but let's deal with them further on in the document so that most people don't have to read through it and be subjected to it if they don't need to use it.
And I think the third step is to look at those corner cases and suggest we remove one of them and see if there's an injured party.
If there's an injured party that says no, we need that, then don't remove it. And then try to combine it with something else. Can we then take this corner case and give it the same rules as something else that exists and maybe that gives the corner case a little extra space or a little extra wiggle room or a little extra leeway.
If the community is acceptable and amenable to that, in order to get a smaller policy proposal, then probably no one is injured.
That's, I think, the steps I would take if I was on the AC to try to push forward a big dramatic change like this.
Vint Cerf: It's Vint Cerf again, Google. I might take a different tactic, Jason. What strikes me as evident in this relatively thick document is that our model of the system that we're trying to manage has gotten more complex because it has gotten more complex and we're trying to deal with cases and scenarios that didn't necessarily exist in the earlier days of deployment of the Internet.
It might be an alternative, if I were trying to do this, would be to start out try to build a model of the creatures in the zoo that needed to be accounted for in the policies. And see whether I could understand and describe what their behavior is in this ecosystem.
And only with that model in hand then try to infer from that what kind of rules makes sense. Now, none of these -- anything that's been suggested so far including this suggestion sounds very easy at all. But having models in hand can help a lot, I think, in formulating the problem.
So trying to deal with the existing text is coping with a complex object which is accreted over time. Kind of like barnacles on a ship that slow the ship down.
And it may be that trying to do what Jason is suggesting might not end up with as conceptually clean a result as trying to make sure that our model of this ecosystem as it currently exists is more clear with that exercise than it is today, interpreting and inferring it from the complex rules that we've written.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. There's three sections of the NRPM that account for the vast majority of the text: 4, 6 and 10.
I think the remaining sections are by and large as succinct as they can be. Section 10 is dictated by global policy. It's policies that we have passed and that have been ratified subsequently by the IANA Board and therefore absent a global policy process they're somewhat immutable. So I don't think we really can look towards simplifying section 10 all that much.
Reviewing Section 6, it has become somewhat complex, but I don't think overly so. There are a few things we can do like deleting the HD-ratio table that no longer matters to any policy whatsoever and some cleanup items that we could do to shorten it.
But I don't think there's a lot of simplification to be gained there because we've actually made the policies relatively simple.
We've made them relatively generous as well. Yes, there's lots of things we may be able to do in Section 4.
However, the process of cleaning up Section 4 is probably going to take 3 to 5 years to get through the whole process.
It's going to be relatively painful. It's going to take a lot of time and effort and I'd rather much see the people involved in that effort involved in the effort to make v4 irrelevant instead. Thank you.
John Curran: I'm closing the queues unless there's any final remarks.
Anything you'd like to say, Dan?
Dan Alexander: No. The Advisory Council will be happy to work on the -- continue to work on this topic and welcome all feedback to the Mailing List.
John Curran: Thank you, everyone. Thank you, Dan.
Software Development Update
John Curran: We're coming to the end of the second day. We have one more presentation, it's the one we didn't get to, it's the Software Development Update. Nate Davis will come up and give it.
Nate Davis: All right. Good afternoon, everyone. I guess I stand between you and the beach at this point.
So I'm Nate Davis. I'm ARIN's Chief Operating Officer. And routinely I give this update at each of the ARIN meetings.
And the reason for this is that ARIN spends a little bit of money on engineering activities. And most of those activities benefit you, the community.
So this is my report that allows you to keep track, or we provide visibility so you can keep track of what we have done and what we're planning to do.
So some of the things I will cover, I'm going to talk about some of the projects we've completed since the last ARIN meeting in Montréal, some of the forthcoming initiatives that we have that we plan to work on.
Some of the items that influence what we work on and then the strategic guidance that we've received from the Board and it helps us determine those items that we work on.
Okay. So we have almost completed for the most part transfers, 8.4 specifically. We've automated that functionality, and we spent quite a bit of time doing it because as all of you know transfers have increased significantly at ARIN.
It was vitally important that we provided the functionality just both on the management side and also from the user perspective on being able to transfer those or automate those transfers.
We've also enhanced some point of contact record information. As Leslie mentioned earlier in her report, emails that have gone out are now revised for clarity.
We've also made some recent changes to accommodate the new fee schedule that Whois planned implementation is July 1st.
If you noticed, the main menu of ARIN Online, ARIN's Web portal to manage resources, has been revised.
It's actually been streamlined and polished quite a bit. And if you have not seen it recently we've expanded some of the sub menus and made some of the paths through the navigation more intuitive and consistent with commonly -- some of the commonly used functionality that's there behind some of the options.
As part of the SWIP Easy project, through ARIN Online, we also have now enabled users to delete networks and/or child networks for which they are authoritative.
Weren't previously able to do that through ARIN Online. Now you're able to.
And the resource management and request resources pages have been modernized as well. They've been streamlined and are a little bit easier to use.
This is some of the work that's been reflected in community feedback for us to take a look at our user interface.
We brought a person aboard to help with some of that. Jana Blacka (phonetic), who is back at ARIN offices, and she's been working with some of the community, perhaps maybe some of you, and talking to you about user interface and some of the preferences you have.
So some of these address some of the changes you have seen here before. Again they address the ASPs, the community feedback that we get through ARIN's suggestion process.
But it also addresses some of the things that we're hearing through the user feedback button that's located on each of ARIN's Web pages.
As a reminder, the user feedback button can actually be selected anytime you have feedback about a particular page. And those comments come back to ARIN staff and we evaluate and react to them accordingly.
Some of the forthcoming things we'll be doing is improving voting contact, management. Susan is going to talk a little bit about voting on Wednesday, tomorrow, and as a result of some of the changes that we have forth coming that tie in all voting functionality with ARIN Online.
We're also behind the scenes doing some improvement to voting contact management to make it easier for organizations as well as ARIN staff to manage voters.
We'll be deploying SWIP Easy, which is a Web-based tool to send in reassignment information.
We have REST services that allow organizations who have IT staff to programatically send in SWIPs.
But we have sort of this niche area where organizations that don't necessarily have IT staff but they still have a fair amount of SWIP information and want to send that in to ARIN, either do it manually or programmatically when they have time on limited resources. So we're trying to fill that niche with ARIN Online with a product called SWIP Easy that allows organizations to go in and manage large amounts of SWIP but do that relatively easy through a user interface.
We'll continue working on various ACSPs. We're also working on fully redundant services like Reg-RWS, registration, RESTful web services, to allow for rolling deployments. As you know, periodically we do deployments.
They sometimes take us offline for a number of hours. We're looking to do those in a rolling manner so that we minimize our outage times for deployments. And as always we have to take a little bit of technical debt and do some improvements on long those areas.
So what influences the things that ARIN works on? Like many organizations, we have a number of competing priorities. What you see before you is a list of those things that ARIN has to evaluate as we take a look at how we're engineering our solutions for the community and also internally.
And sometimes these are very strongly competing requests and sometimes they're very evident the things that we should work on first.
But anyways, we take this all into consideration when we look at those things that we deployed from a functional standpoint from the engineering team and that we make available to the community.
So one of the benefits that we have is that we have some great strategic guidance that we received from the Board. And that helps us take a look at the influences, determine how best to tackle them. In most cases, not in all cases but most cases.
The Board guidance that has been provided to ARIN staff and is visible to the community on our strategic plan that's available on the website really focuses on these three areas.
And it's continue to review and enhance ARIN Online including making significant user interface improvements per user feedback, continue to automate ARIN Online functions that support policy development, and then continue to focus on community-suggested customer-facing, high-impact software development efforts in a timely manner.
So that provides us the guidance that we need to work through all the competing influences we have we need to consider when we're deploying engineering services at ARIN.
That is the end of my presentation. And I'll be happy to take questions now or later on the beach.
John Curran: Microphones are open for questions.
Vint Cerf: There was a time when you had a fairly long queue of things that people had asked for.
Is there still a queue, and is it getting longer or shorter?
Nate Davis: Actually, we spent much of 2015 actually whittling down that list quite a bit. It's not as long as it's historically been.
We're still routinely getting suggestions. We're keeping it pruned, if you will, at a better rate than we have. But I will say that we've had to take some investment in infrastructure items, not necessarily community enhancements, i.e., the transfer software we just had to have in place and some technical debt. I think overall we're managing that backlog in a much better manner. So good question.
Any other questions?
Kevin Blumberg: Kevin Blumberg. With the net delete feature that's an RM minus RF to the record, correct, it's an everything -- I can't select individually at this time, correct?
Nate Davis: I believe it is. Is Mark available or Andy to confirm that?
Kevin Blumberg: I didn't want to test it by clicking without it asking me whether I wanted to continue.
The net delete deletes every child record, correct?
Mark Kosters: That's correct.
Kevin Blumberg: As an emergency situation, suggestion, call it purge, not delete. I believe SWIP Easy you're going to allow individuals, you'll be able to do it individually. But it really is a hammer or mallet kind of button and I don't think people are aware of.
Nate Davis: Good feedback. Any other comments?
John Curran: Closing the microphones. Last chance. If anyone's coming to the mics -- okay. Microphones are closed.
Nate, thank you for your presentation.
John Curran: You'd think we'd actually adjourn at this point. But there is one other item before closing announcements. It's a session we have at ARIN all the time. It's called Open Microphone. It's where you get to provide feedback to the room, the Board, the staff as to how we're doing.
So I'm going to move into open mic now. If anyone has any questions regarding things that have happened over the last day and a half, questions on matters that haven't come up, you have a question you'd like to address to the Board, we'll have an open mic session both today and tomorrow. I know it's sunny today and fairly early but we also have one tomorrow.
But avail yourselves to the microphones if you have any questions. I see someone approaching the mic. Excellent.
Janine Goodman: Janine Goodman with Avenue4. This is almost feedback on policy that was implemented in February, last February 2015, I should say.
So one of the issues that Leslie raised in her presentation, accuracy of the registry, was the issue of legacy holders coming forward. We discussed one issue as to why we thought that might be problematic.
But there's actually another issue we're coming up over and over with legacy holders who are our clients, and that's the language in 8.2 that deals with justification, if ARIN becomes aware of the number resources are no longer justified, that ARIN will work with the resource holders to return their transfer resources.
I know that 2014-9 was intended to reconcile conflict with the RSA Section 6 regarding the fact that ARIN could not deregister numbers. And so went in, passed policy that took out the word "reclaim" from 8.2.
And there's language that is certainly intended to make clear that ARIN is not going to yank the numbers away. But what we're finding is that legacy holders, it's not enough comfort.
It's almost the same issue you raised yesterday with the potential sellers who want to sell the /16, hold on a /24, you give them some reason to think it's not a big issue and it's just not enough.
We're finding legacy holders come to us and they say but ARIN can work with us on returning the numbers.
It's actually almost as much of an issue when they're using the numbers because they might not be using an entire block. And we've had legacy holders that will not do an 8.2 because they are concerned that ARIN will come back and take the numbers away and they don't feel like they can afford it.
We've gone through the history and shown how there's a policy. They took out the word "reclaim". And it doesn't make a difference. I want to bring that to the attention.
There's obviously 2015-9 taking away needs assessment for 8.2 that would address that. I want to make you aware that to the extent --
John Curran: Still an existing problem. Let's talk about this. People have to understand the process by which we would do reclamation or revocation of resources.
If you find yourself in that circumstance, it's a pretty big situation in ARIN. We have a long process you can find online that we go through. For example, for nonpayment it could be 150 days with us contacting you.
Revocation for other reasons, where literally we're doing it because of a violation of policy, is few and far between.
And in particular revocation contrary to the RSA to my knowledge doesn't happen because the RSA is an agreement that lays out your rights, and I wouldn't be reclaiming resources contrary to that.
So I do understand the number resource policy manual can give someone pause. The absolute best protection they have is a signed LRSA which gives them an absolute concrete statement that says not withstanding any of the following we will not reclaim number resources for lack of utilization, period.
I know some people look at that and go I don't want an LRSA because it disclaims property rights; it does. But it also gives a very big statement that's very clear rights that we will not be involved in reclamation for lack of utilization.
It might be an education issue here because the people who are shying away from the LRSA because they're not sure what they're giving up are always shying away from the rights it provides.
Janine Goodman: I know there was a discussion yesterday about the LRSA. So I don't want to go back into that. That was hashed out somewhat.
But I think for the same reason, you're right, they're reluctant for the LRSA.
But this is even before you get to the LRSA point. You can sit there and say, okay, you go through, because as soon as you apply for that transfer, their issue isn't even getting to signing the LRSA, it's I don't even want to let ARIN know that I'm out there and raise the issue and even apply for a transfer and get to that point.
John Curran: It's a difficult problem. I don't have a good answer for that one. Vint.
Dan or Vint.
Vint Cerf: So I saw a movie recently. It was something about a bridge and there's this Russian spy on one end and there's some other people. Maybe you need a procedure where the /16 comes in this direction and the /24 comes over here and they do a swap in the middle.
Janine Goodman: This doesn't even deal with that issue. This is literally about a legacy holder just to update their records and they've gone through various mergers over years. It can be complicated.
They want to straighten out their records and they won't do that. It goes very much to the issue of -- that does go to the issue of registry accuracy that Leslie was getting at in her presentation.
John Curran: It may not be the same issue as the /16 and /24 and a bridge, but it's a very similar situation about trust.
Your legacy holder probably needs to talk to the last five who have gone through the process successfully. Really would be worthwhile.
Dan Alexander: It might be worth noting the editorial process that's currently underway regarding the 8.2 update, regarding -- the Advisory Council was looking at it previously and there was actually a draft proposal created to deal with this return language.
We actually thought it was more editorial in nature so there's a separate process for ARIN to proceed or do a review of an editorial change, and that process was requested last month.
John Curran: For that particular section we're going to try to improve the language. Without changing the current practice or intent but to improve the language to make it clearer.
Janine Goodman: Maybe we'll take a look at that, see what it is. I'll just let you know the practical language in updating the registry.
John Curran: Scott, do you want to respond?
Scott Leibrand: To expand on what Dan just said. I have an email in front of me that says: The review period for this change is open until the 23rd of April, which is four more days.
The language that we are proposing to replace with says specifically that ARIN will work with the resource holders to transfer the extra number resources to other organizations or accept a voluntary return of the extra number resources to ARIN.
So hopefully that's clearer, but I would appreciate anyone with interest in this to go ahead and read through that and make a comment in response to the announced editorial process.
John Curran: Anything else on this?
Next issue. Rear microphone.
Stephen Middleton: Stephen Middleton, Verizon Communications. I have concerns about the increase of ARIN fees recently announced.
My primary concern, though, I'd like to voice is the timing. Budget increases take time. It takes a great deal of time in large corporations much like Verizon Communications.
We would like to see more time in preparing budget increases of four times or greater what we have been paying in the past.
John Curran: If I can speak. It is true the largest license fee change which will rollout in July, the largest IPv4 resource holders received a significant increase because what was prior a cap on the number of categories now goes all the way up and that category at the top level could represent two or four times increase in fees.
So it is definitely a significant change. We have been working on the fee change for several years. But working on it isn't the same as requesting budget approval.
So it is true that there were, while the fees went down for thousands of ARIN members, it went up for a handful, about 97 large organizations. I don't know if the Board wants to speak to this about the timing of that increase or anything.
Vint Cerf: I have a question. I don't know whether you want to say what the absolute dollar increase is in the case of Verizon. But that might be an interesting factoid to inform the discussion.
Steve Ryan: [Indiscernible].
John Curran: For the largest category, largest resource holders could have seen increases based on the total IPv4 holdings per organization.
Some of these organizations have multiple entities. But for an organization it could have seen an increase from 16 to 128,000 or $100,000 an organization.
Stephen Middleton: I believe the comparison between the two highest values is $32,000 could increase to as much as $256,000.
John Curran: The highest category, you're correct. I forgot. The community removed even the higher, higher category.
So I guess the question would be it was the view after going through a two-year consultative process that the fees should be proportional to the benefit of the resources, and therefore as the resources go up, geometrically the fees go up.
My question would be: It's not that principle you're concerned as much just the fact when it occurred you need more time to be able to respond to it.
Stephen Middleton: You're correct, within the budget cycle. Not saying that we wouldn't be concerned about the increase of fees issue itself. But what I'm concerned about is to try to be prepared for them.
John Curran: Understood. I think one has to object to an increase in fees. But understood the timing issue.
Thank you, Steve.
On this matter of the fees? Yes, Jason.
Jason Schiller: Jason Schiller, Google. ASO AC. I've looked at the fee structure quite a bit. I wanted to share what I've found with those in the room who maybe haven't looked at it.
For the end user, if they choose -- what is that called? If they choose the end user billing structure, it hasn't changed.
For ISPs or those that choose to have the service category fees, if you fall into the same-sized bucket as you did before, it doesn't change. What has changed is they've created some new buckets.
Previously there was a double extra small which cost $500 annually. And that was a /22 or smaller. And they've created a triple extra small which is a /24 or smaller and the fee has been reduced to $250.
So if you happen to have a /24 or less, you used to be a 2X small, now you're a 3X small and you pay less.
Same thing on the higher side. The old highest category was a double extra large, which was larger than a /12. And that was $32,000 a year. Now they've added a 3 extra large, which is larger than a /10 at $64,000. A 4 extra large, which is larger than, which is between -- I'm sorry, the 3X is larger than a /10 and smaller than an /8, which is $64,000. Larger than an /8 and smaller than a /6 is a quadruple extra large at $128,000.
Then there's a pentuple extra large which is larger than a /6 at $256,000.
If you're a very large player in the double extra large bucket, your fees went up accordingly to what bucket you now fall into.
And if you have a /24 or less your fees will go down because now you fall into the smaller bucket.
John Curran: Correct. Okay. Any other comments on the fee topic or any other topic? I'm going to be closing the mic shortly. Yes.
Adam Gosling: This is just a quick one. I wanted to address something that Selina mentioned in her IANA update.
It's about the returns. I was the person at APNIC that asked how much would the RIRs need to contribute back into that bucket in order to get rid of this trickle.
The last derogation that the IANA will give out is a /23. And we're going to wait three years for that or something. I thought it was a good idea for us to put it back in. And APNIC was willing or is willing to put it in, and I think I don't want to speak for RIPE, but I'm going to. They indicated that they would be willing to contribute.
I think it's maybe still in the discussion, but I think it's unlikely to go ahead.
John Curran: If I can paraphrase. The thought is currently the remainder IPv4 allocation policy has an algorithm that divides things up into even units.
If it divides up into even units, then the remaining, all returned IPv4 addresses at IANA could actually be passed out into even slices at the five RIRs and they'd be done.
Right now, as it is, that's not the case. When they do the division there's a remainder, which means six months later they have to do the division again and there's a remainder. And we continue to get small dribbles and drabs from the IANA for several years. Is that correct?
Adam Gosling: That's what I'm talking about, right.
John Curran: We haven't talked about it in the communities to my knowledge, that is the remaining IPv4 unicast address space.
Right now, when the IETF does a specialized or technical assignment, it comes from that same pool. So there's two consequences of rounding that pool to an even five buckets.
The first one is it may not stay at an even five because someone writes a wonderful Internet RFC and they allocate some IP unicast space for some IETF protocol and now it's not even again.
But the second issue is, if it is even, there no longer is IPv4 address space at the IANA to satisfy the IETF. That we've been talking about, because the IETF invented that v4 address space and it's nice of us to put it to use, but it's interesting, when we're so efficient, that we take the last block from the IANA, leaving none for any protocol work.
And so if we go about that approach, there needs to be a little bit of coordination to make sure the IETF can still do unicast IPv4 assignments for specialized and technical purposes for protocols that need that.
And we haven't done that coordination yet. So getting in there with five even straws to draw it down to zero seems impolite.
Adam Gosling: Thank you. That's what I was going to say actually. You said it very eloquently. Much better than I could have.
Thank you, John.
John Curran: Thank you for raising it.
Microphones remain open. On that topic or new topic?
Jason Schiller: New topic.
Owen DeLong: That topic.
Owen DeLong, Akamai, ARIN AC. I don't think it's all that impolite to round out the pool and suck it dry. I think it's pretty close to the point that the IETF is not working on v4 anymore anyway, and I think that should be encouraged.
John Curran: Okay. Interesting approach. I guess if they labeled it historic, then you'd know they weren't working on it anymore.
Okay. Back microphone.
Go ahead, Jason.
Jason Schiller: Jason Schiller, Google. ASO AC. I hope Mike Joseph is listening. I hope Mike Joseph is listening.
I lament the lack of a services document. Do we have an update on when we'll see one?
John Curran: So to have a services document I wanted to work with the Services Working Group to get that done.
We actually, the Board, this year, chartered a Services Working Group. We appointed the chairs. We called for volunteers, called for more volunteers. We selected the volunteers.
And if we get out of this meeting and go to our Board meeting, we will -- actually we'll impanel the volunteers. Then we'll have a Services Working Group.
I will work with them on a services document that describes ARIN's registry services.
Presently you're the one between us and that. Just want to focus that. Next question.
Thank you, Jason. That's a good reminder. We've been a little slower than we could have been and we'll pick that up.
The microphones do remain open. Last call. We'll have an open mic session tomorrow.
Jason. Yes, Jason.
Jason Schiller: I've been talking to folks in the community, and I get the impression that there's some frustration about the questions that are called at the end of the policy discussion.
And it seems like we feel like maybe more useful questions could be asked or perhaps multiple questions could be asked. And I think it doesn't consume that much time. So I hope the AC would consider asking more questions.
John Curran: So that is -- the questions that are asked are set by the Advisory Council chair. The AC members are all around. They have badges that say AC members. They talk to the Chair about that. You should talk to them and they'll talk to him.
And what will happen, if enough AC members think it needs to change, it will change or the new Chair will change it. So it works out either way.
But you have to talk to the AC members. There is a couple of parliamentary important little knits here, which is you can't ask a question that people haven't had time to discuss.
So if you were talking about should the boundary be /16 or should it be /20, and someone says I know, I know, let's do a poll, it should be /22 and reduce one every year.
If you didn't have time to discuss the merits of something, you can't poll on that choice. Otherwise, you violated all the parliamentary rules that allow for informed discussion.
It's also true that the AC used to do what I call free-formed questions. This was very exciting.
Having been at an AC meeting where they look at, well, it's this but if change this word, what about this, with this option. Would this vote against it only if this one wasn't going to pass, or is it against it if that one was going to pass.
It gets very complicated when you have multiple choices of polls. But if you have advice, certainly the policy shepherds of a particular policy have a lot of sway in it. Ultimately the Chair makes the call.
Dan, do you want to comment on any of this?
Dan Alexander: The thinking going into the meeting was that the recommended draft would get the question whether or not to move forward and all the other drafts would simply be the binary question to continue work.
I understand what you're saying about wanting to ask the different flavors of each. But in the past, as John had mentioned, we have slid down that slope of the moment one extra question is asked, then three people get up and want different flavors of the question to be asked. And it makes the conversation difficult.
The expectation was the Advisory Council take the feedback that was provided at the microphone to interpret whether all the subtleties of the suggestions being made rather than to use a poll of the room for that purpose on a draft that is not actually in a recommended state. I don't know if that helps. And we can always look at other options. But I'm just explaining why we did what we did today.
John Curran: Does that answer your question?
Jason Schiller: Sadly, yes.
John Curran: Same topic, Owen?
Owen DeLong: Owen DeLong, ARIN AC. I find the question: Should the AC continue working on this or not, to be about the most useless question that we could possibly ask.
Because in my experience by and large, unless it's been hashed to death and the community is simply tired of hearing us talk about that policy anymore, they will say yes to the AC should continue to work on just about anything.
And if they are tired of hearing about it, then they will say, no, the AC shouldn't continue to work on it, regardless of their level of support for it.
So I would prefer that we ask about support for the policy or support for the general intent of the policy proposal or something like that, rather than simply asking: Do you want the AC to continue spending time on this?
John Curran: Thank you. Good comment.
Dan Alexander: Just to follow up on that. While they're all valid points, this is all something that can be and should be hashed out on the AC list as a body prior to the meeting rather than trying to sort it out now, which is why we just kind of moved forward as we did.
John Curran: People might remember, we used to ask the inverted question. It didn't change the answer.
It used to be the bar was: Do you want to abandon work on this proposal? And people said no, no, it's lousy, but let the AC keep working on it.
There's a very low threshold for expending AC cycles. If you run for the AC keep this in mind, important note. There's a very low threshold for expending AC cycles.
The goal -- what's more useful is people saying I have an idea, it's not that we need to poll the room. Go to the PPML and say here's the phrasing that I think would solve the problem.
Because at the end of the day things that are coming here as Draft Policies are not going to the Board. They're going to come back to you.
So what they're really looking for is how do we get as many people comfortable with a version that it has community support.
So that's why the question at the mic of: Is there any changes that would make you support it, is an important question.
If you want to see something polled because you would support something under those circumstances, get on PPML and say that. That will actually probably have more influence than any poll would have had.
On this topic, back microphone, or new topic, Jason?
Jason Schiller: Same topic. The AC list that you referenced, that's the closed AC list, correct?
Dan Alexander: I was referring to the internal AC list.
Jason Schiller: Which is closed?
Dan Alexander: It is.
Jason Schiller: Thank you.
John Curran: Front microphone.
Chris Woodfield: Chris Woodfield, Twitter. I wanted to comment to what Owen said about the fact that it is rare that we vote to no longer pursue a proposal.
I think what happened here is that we had two proposals that were, from my reading, were mutually incompatible. And the decision was which one do we continue working on.
John Curran: Right. Each policy proposal in general is presented and considered on its own as if nothing else changes.
So you have to decide: Do you like A, just as A, or do you like B just as B? The question of if both got overwhelming support, what do we do, the AC is capable of handling.
The AC has the right to fragment, break and merge proposals if that's what it thinks takes the job to get it done. Look at each one, independent discussion as an independent discussion.
Kevin Blumberg: I think it's also important to realize that the most important aspect is not the vote. The vote is just a sanity check in some respects of the discussion in the room. And it's critical that the discussion expand as much as possible with the community.
As far as the question in regards to the questions that are asked, I think that the community has made suggestions, I think the AC has made suggestions, and I believe the moderators have made suggestions as to changes over time over the last three years; it has changed four or five times that I can remember.
There's no reason we can't change it. If you have a suggestion, there are lots of ways to do it. At the end of the day, we still need to be consistent with the questions to not confuse the room, which was one of the problems we had in the past. That was a huge problem we had in the past where we would change up the questions each time.
With that being said, we can absolutely work on clarifying some of the questions.
John Curran: Okay. Any other -- on this topic or any other topic? Microphones are open for open mic.
I'm closing the queues shortly. I'm closing the queues in five, four, 3.145 -- three, two, one. Microphones are closed.
That ends our open mic session. Thank you.
Closing Announcements and Adjournment
John Curran: Okay. Now I'd like to move to close. So big round of support for our network sponsor C&W Business and Google.
Don't forget the meeting survey. If you have the link, you can access it. You'll also get an email registration. We will do a lottery and we will draw for a 64 gigabyte Air 2. Very nice. So do the meeting survey.
We pay a lot of attention to the surveys, whole postmortem at ARIN making sure we have better readings based on your feedback. We love to hear it. Don't worry about being shy. Fill out the meeting survey.
Okay. Other things. We have a happy hour. It's a quick happy hour. It starts in 12 minutes. It's just an hour long. The place for you to get together, see each other, have drinks before you go out to dinner.
So it is at the Royal Pavilion. You folks know where it is. And we hope -- we hope you enjoy your time there.
And tomorrow we will resume at 8:00 AM, 8 to 9 is breakfast. 9:00 over here. We'll start the Members Meeting.
We have a day of reports from the staff. We are including -- then we have the Board and the ARIN Advisory Council report. Highly recommended. So everyone enjoy yourself. We'll see you tomorrow. Thank you.
(Meeting adjourned at 4:50 PM.)