ARIN 35 Public Policy Meeting, Day 2 Transcript - Tuesday, 14 April 2015
Table of Contents
- Opening Announcements
- NRO Activities Report
- NRO NC Report
- Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10
- Recommended Draft Policy ARIN-2014-1: Out of Region Use
- Transfer Experience Panel
- Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers
- Registration Data Access Protocol (RDAP)
- Global Reports: RIPE NCC
- Global Reports: LACNIC
- Global Reports: APNIC
- Global Reports: AFRINIC
- Global Reports: IANA
- Open Microphone
- Closing Announcements
John Curran: Good morning. I'm John Curran, President and CEO of ARIN. I'd like to get started on the second day of our Public Policy Meeting.
First, I'd like to welcome, thank our sponsors and give a big round of applause for Webpass, your Internet connectivity. Welcome everyone. I'd like to thank our webcast sponsor, Google.
And our refreshment break sponsors, Fastmetrics, ServerHub, and IPv4 Market Group.
I'd like to tell you this morning we have the NRO Activities Report, the NRO Number Council Report, and we have a set of policy discussions and we have a Transfer Experience Panel. Should be a very exciting morning.
Policy discussions. ARIN 2014-2 and ARIN 2014-1. So I'm going to remind everyone when you come to the microphone, identify yourself each time you're recognized, state your name and affiliation. Please be polite. Comply with the courtesies in the program.
Courtesies in the program mean we try to get to everyone first before you get up and speak a second time. Let the people who haven't spoken speak first.
We talk about issues and points. We don't talk about motivations or attribute values to other people.
At the head table I have Vice Chair Paul Andersen. I have Chair of the ARIN AC, Dan. I have Kevin Blumberg. And for jabber I have Leif at the end. That's two days in a row I've been getting them all right.
I'll start in, the first presentation is going to be the NRO Activities Report with Axel Pawlik.
NRO Activities Report
Axel Pawlik: Good morning. I'm quite impressed that -- at the RIPE meetings, we always have the unpopular slot on the Friday morning after the Thursday dinner. You're doing quite well. Thank you for coming.
The NRO update. You've probably heard a little bit about the Number Resource Organization. We want to be the flagship and global leader for collaborative Internet number resource management as a central element of an open, stable, and secure Internet.
Brief of introduction what the NRO is, what we're doing. Fairly straightforward. We have set up among the RIRs an MoU in October of 2003. It's a long time ago. The idea is to have a very lightweight non-organization that helps us coordinate the RIRs, stuff that we need to do to get in a very organized fashion.
So we heard it yesterday at some point that there was a time when ICANN didn't work so well. We had to wait a long time for numbers. Those times have long since passed.
But still at the time we thought we might want to be prepared if we need to do something there. Never really needed to do something, which is good
The mission of the NRO, provide and promote a coordinated Internet number registry system and promote the multistakeholder model and bottom-up Policy Development Process in Internet governance, coordinate and support joint activities of the RIR, as I said, act as a focal point for input into the overall RIR system and the idea there was a global policy at some point, and to fulfill, of course, the role of the ICANN Address Supporting Organization.
So RIR coordination, global collaboration, monitor and contribute to global Internet governance discussions. Those are the main focal points. And of course some of you heard yesterday during the whole long session about IANA stewardship transition, that stuff of course is in there as well.
So we have a couple of people, the NRO, you see the executive committee. It's 2015. That means I must be the Chair.
Oscar, LACNIC, is new in as CEO and he's Secretary of the year. John is Treasurer and sitting on the pot of money. Paul is on holidays in a way, and Alan is on the doorstep, coming in next week, I think, for AFRINIC. We have a secretariat hosted by LACNIC and Executive Secretary, German. He was over there yesterday; I don't know where he is today. He's busy keeping us all organized and point at the same direction. It's very good
We have a couple of coordination groups among our RIR staff there. The CCG is the Communications Coordination Group.
The PA -- I always forget that.
John Curran: Public affairs.
Axel Pawlik: Thank you. We have the engineers and we have the registration services group, and we have the IPv6 coordination group there as well.
So everybody is very busy and meets occasionally face to face meetings, but of course a lot of work is done on Mailing Lists as well.
As I said, the NRO is a very lightweight organization. We don't want to build up lots of overhead there. Still we have a couple of expenses. Of course, there's travel that we jointly fund through the NRO for ASO AC travel, Executive Secretary travel there. For communications, booths at conferences where we do them, the contribution for the IGF. The ICANN contribution still at the same level since '99, actually.
And now some staff cost there basically for command.
The budget, we basically share on a formula. Not really actually formula anymore. Basically we look at Registration Services revenue at the various RIRs and share the cost accordingly.
Operational information. We have on the NRO website. Of course you're welcome to have a look at it. Basically number status report. Policy overviews. Also now for IANA stewardship transition, lots of information from the CRISP team as well. We've been very busy the last two years or so. In setting up the governance matrix, showing in comparison between the RIRs how we are set up organizationally, how we govern our organizations, how you govern our organizations.
And it's getting more and more refined. We're still busy on it. It's quite an interesting, big document right now. And of course some Q&A on RIR accountability as well. We always talk about ICANN accountability, but hello. We want to be accountable, too. I think we are.
So stewardship transition is of course very high on the agenda. And you've heard about all this yesterday and we keep doing this. We have also participation in the CCWG, which is basically looking at ICANN accountability and I think you heard about that yesterday as well.
We have done quite some time ago a review, external review, of the ASO and had a couple of recommendations from that and have been looking at them and implementing them where we found that we were lacking or could do better.
Of course, that's something that I think all of the RIRs are doing. We do that jointly as well. Where we can do things better, when we hear about it, we are very open about that and want to improve.
The Internet Governance Forum has been the mainstay of Internet governance activities of the RIRs and of the NRO. Over the last couple of months, last half year or so, it's been overtaken a little bit in focus with the IANA adventure there.
But the IGF still remains our main focus on Internet governance. We will go to Brazil again to the tenth one later this year and we have a couple of workshop proposals there, as well as of course we find this thing so important that it continues that we also fund it in part.
And that's basically the update from the NRO. If you have any questions, you are very welcome to put them towards us.
If not, good morning. Thank you.
John Curran: Next up, Louie Lee to give the NRO Number Council Report.
NRO NC Report
Louie Lee: You see the title says ASO AC report. Well, the NRO Number Council is tasked to fulfill the role of the ASO Address Council. Lately all we've been doing is fulfilling that role, and we'll go into what that role is.
We are a Number Resource policy advisory body, and we are made up of 15 members, three from each region, two elected at large and one appointed by the RIR Board.
Details, you can see up on the slide. We'll get on to the meat of it.
The members, as you can see, we have a couple of changes coming up. Actually one coming up, Alan Barrett, as you just saw in the previous presentation, has vacated his seat. And the AFRINIC Board will be appointing a replacement for him. Ajay Kumar is new since our last meeting.
And I will introduce Jason Schiller, who is right over there, and Ron da Silva, right over there. And they are your ARIN region members.
So lately our meetings, we have scheduled meetings once every month, first Wednesday, and we could have emergency meetings in order to address any important issues.
Since our last ARIN meeting, we've held six teleconferences to cover our issues.
Our Global Policy Management activity. Global policy, what is a global policy? They are defined within the scope of the agreement. The global policy is a policy that's agreed across all five regions, and it has the component where it requires the RIRs to interact with an outside body. Usually it's IANA.
So an example of a global policy would have been one where IANA will issue a /8 to all the regions once it gets down to the last five /8s that it has in its free pool.
How global policy happens. So the communities would offer a global policy, do a proposal. Gets discussed around all five regions, using their own RIR PDP, Policy Development Process. And when there's agreement, it gets passed up to the NRO, the ASO Address Council.
We review that, not necessarily for the merits, but to make sure that the policy has passed through each region's processes accordingly and it has also considered all the relevant input, all the substantial input.
Once it's met those criteria, then we pass it up to the ICANN Board for ratification.
If there's no major issue that they need us to consider, they will ratify that and put it into practice. Usually for IANA to act on.
If there is an issue they'd like us to consider, they would send that global policy proposal back to us to either consider on our own, give feedback to the ICANN Board, or more usually we would ask the community for their answer of the ICANN Board's request.
We have a policy proposal facilitator's team that's formed every year to keep an eye on all the policy proposals going on globally to make sure that if there is one that pops up, that we track it. We can provide input on how it could maybe be a better global policy.
We can help the shepherds of each region's advisory body to work to get this policy worked through. And there is currently no global policy proposal.
The other thing we do is that we appoint two ICANN Board members to the Board. This year Seat 9 is coming up. It is currently held by Ray Plzak. We have an qualification review committee and an interview that is -- do the administrative tasks of doing the appointment. But the whole AC would be the ones getting feedback and making the decisions.
This year we have six confirmed candidates. Three from -- from three regions. One from AFRINIC, three from ARIN, and two from the LACNIC region.
And if you want to see the list of candidates, go ahead and go online to check out their biographies.
We have a timeline for this. And we are actually still in the interview phase in mid April, running a few weeks behind. But this week every morning, 7:00 a.m., we have a teleconference to do the phone interviews and shortly thereafter the whole AC will meet and discuss what we feel about the candidates. And then we'll have a vote and then offer the name up to the ICANN Board -- sorry, to the ICANN staff to do their due diligence before the name is announced.
Since our last meeting, the Address Council participated in two ICANN meetings. We held some sessions for the public to let them know what the CRISP team has been doing with IANA stewardship transition. We gave an update about the ICANN Board election and we met with other organizations that are in the ICANN community, along with the ICANN Board.
And if there's bits of details of what we've been working on, you can go to our website, and that's aso.icann.org.
Thank you. Are there any questions?
John Curran: Any questions for Louie? Any questions for Louie's hat?
Recommended Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10
John Curran: Next up we are going to go into our Draft Policy block. And we are right on schedule. Very good.
The first policy we're going to discuss is Recommended Draft Policy 2014-22: Removal of the Minimum in Section 4.10.
Policy text is up here. I'll have Heather Schiller come up and do the presentation. There's an intro. It's a Recommended Draft Policy. You really need to know what it's been through.
In theory I could have just done it off the Discussion Guide. It's not that different. ARIN 2014-22: Removal of the Minimum in Section 4.10. Originated in October 2014. Heather Schiller and Rob Seastrom as the AC shepherds. Was presented at the NANOG 63 Public Policy Consultation. It was advanced to recommended Draft Policy in the March meeting of the AC. It's online and in your Discussion Guide.
The proposal will modify existing policy, the NRPM 4.10 dedicated IPv4 block to facilitate IPv6 deployment. The current policy sets the minimum allocation as /28 to a maximum of /24. This proposal changes the allocation size to simply be a /24 with no maximum and no minimum.
We've issued one so far out of this pool. One /24. We can implement it very easily. There's no legal impacts. Minimal resources involved. Standard implementation window. Three months from ratification. We'd update our staff and guidelines and training.
And now I'll turn it over to Heather. There we go. Much better.
Heather Schiller: Really straightforward policy. It doesn't all fit on one slide. So RIPE did some analysis to identify exactly how reachable blocks smaller than /24 were.
And it's pretty bad. So that's one of the main reasons for changing from a /28 minimum to a /24 minimum, basically ensuring the folks getting the space will be able to use it globally on the Internet.
It doesn't have the full text. But you'll be able to see that online or in your policy guide. It's really straightforward. Any questions? There really haven't been objections to it at the NANOG PPC. I think a lot of operators supported it. There really haven't been an objections.
Paul Andersen: So just as a reminder, this is a recommended Draft Policy. So it might be the last opportunity to discuss. The first speaker, please.
Alain Durand: Alain Durand. I'm speaking on behalf of myself only. I was the one who introduced back in 2008 the notion for this policy.
And the reason back then was to make sure that we will have addresses for a really, really long time to enable the deployment of IPv6 for new entrants.
The reason it is important for IPv6 new entrants, not talking about people who want v4, but people who really want to do v6, is for reasons that I explained in RFC 3901, also known as BCP 901. I'll read it, just an excerpt of it.
First off, DNS IPv6 transport recommendations guidelines. It says every recognized server should be IPv4 only audio stack. Every DNS zone should be served by at least one IPv4 reachable authoritative main server. The reason for that is to maintain the continuity of the namespace. If you're in IPv4 only or IPv6 only, you can see the exact same namespace. So you need to put some glue into this, and that glue, for lack of a better word, if I overlap with DNS terminology, to essentially mandate that you need to have this little bit of v4 space.
So this is really, really important in the future for any new organization who wants to be IPv6 only to have a little tiny bit of address space.
The concern I have with this policy proposal change is that if you go to /24 allocation and you start from a /10, you have 16,000 allocations possible.
A /28 you had 206,000. It's a very, very different number. So I have concern that we may not have enough addresses to last for 10, 15 years where IPv4 may seem relevant or maybe longer depending on which projection you believe. So that's really my concern.
I do not support this proposal as written. I will be more intent to support it if it was something like a timeline associated with it saying we will do that maybe for the next 18 months and during that 18 months we will engage in a conversation with the service providers to make sure that the specific block that has been reserved for this policy, this/10, is clearly identified and is filtered updated on this particular block to accept /28. This communication was deemed really essential when we discussed this policy back in 2008 and apparently has not really happened so far.
And I suggest now is the time to do it.
Paul Andersen: Thank you. So not supportive. Thank you very much for your comment.
Next speaker, please.
Aaron Hughes: Aaron Hughes, 6connect CEO. One thing I brought up probably in a minor way during Cathy's IETF summary was the need for managing uniqueness for 32-bit identifiers for protocols in a v6 only network such as OSBF or BGP. And part of the reason for the initial size allocation of /28 was the desire to have v4 uniqueness to enable equipment to function with v6 only, not to create the routability of v4 or reachability of that v4 space.
Because today you cannot turn up a network with v4 only. It's worth considering defining what facilitate IPv6 deployment means.
And I find it interesting that we continue to talk about reachability of that v4 space rather than enabling v6 deployment.
Paul Andersen: Not supportive as written.
Aaron Hughes: I could go either way. I think it's a valid point. We should consider it as operators rather than think about how this is reachable and changing bit boundaries everywhere, on every border. And I think we got stuck in the mud with reachability versus v6 deployment.
Paul Andersen: Thank you. It's always helpful if you can preface after your name and organization if you are in support or not because it just helps understand the comments.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, speaking strictly as myself because no one else wants my opinions them. I do not support it as written.
For those who don't really remember the history of this policy, I'm the original author. So you can blame me for the current state of it.
Whether it becomes routable or not, as Aaron pointed out and Alain pointed it out, there are reasons that we need this and we need it to last long.
We originally proposed this as a /8 with /24 boundary as the limit on the lower end so that it would be routable.
And everybody screamed that a /8 was too much, blah, blah, blah. And we don't really need everybody to get a /24 for their last little bit of v6 or v4 to facilitate v6 so let's make that smaller. And we did.
And we went to /28 on the allocation size and we went down to /10 on the pool size because we were able to make the numbers work that way and it looked like it would last long enough.
Moving back to /24, without going up from /10 is going to cause problems in the future that we were trying to avoid by putting this policy in place.
So I think we should look at the history and consider this very carefully and not just say that the current state of routing is what we have to live with forever and base our decision solely on that because, as others have pointed out, this doesn't all have to be routable. And the current place where the filters happen to be does not mean that's where they will always be or even that they have to stay there for this particular block versus other blocks.
Paul Andersen: My queue is rapidly depleting of speakers. If you wish to speak, I'd ask that you approach a mic or type very quickly; otherwise, we'll be closing the mic shortly.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I do not support the policy currently. It may be appropriate in the future.
However, at this point I think it's premature. Everything Owen just said is true. I would say we haven't done one thing. Although, this is part of the one thing I think we need to do. And that is we need to begin outreach on what the purpose is and the fact that we have this block and its intent -- our original intent was to be able to allocate /28s and if you want to route those, you need to change your filters.
We really haven't done that outreach. We really haven't done much.
What the RIPE data is is a representation that we haven't done that outreach, not that we've failed our intent. And I'll leave it at that.
Paul Andersen: Thank you. If you wish to speak, you need to approach a microphone before Kevin is finished speaking because at that point the microphones will be closed. We'll go to Kevin Blumberg.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, and author of this proposal.
I'm ambivalent. I would love to see everybody in this room get what they want in terms of changes to this policy to make it viable.
But this policy really isn't for anybody who is in this room. You already have your v4 space. You already have your v6 space, hopefully. This is about new entrants, which has been mentioned many times.
And so we're kind of shackling a new entrant to not really doing -- being able to do anything. This policy originally came out in 2008. We've had seven years to get the operator community on board. The operating community is not bound by us. The routing table is not in our purview.
And that creates an interesting problem, where we are forcing operational practices on a community without having that outreach, without having really any leg to stand on. And the only people that are really affected by this are the new entrants that we've got this policy set aside for who find that they can't use this space.
So just something to consider. I would be happy to do outreach and see if anything happened with it. But my question for this room is: If you had 97 percent reachability on a /28 in five years, would that be good enough to run your internal DNS critical infrastructure portions? Thank you.
Paul Andersen: Thank you. We'll now close the microphones and leave the last comment to with whatever remote comments you have.
Leif Sawyer: This is a jabber comment from Christoph Blecker, Walt Disney Company: Not in support as written. I don't think we should make number policy based on today's routing situation. If people start being issued 28 blocks and have no other choice, eventually network operators will relax their route filters.
Paul Andersen: Thank you very much for that. If there's no last comments -- with that, thank Heather for her presentation, and we'll move on to the questions.
So I will ask to engage our record keepers. Thank you, Heather.
Paul Andersen: As a reminder, this is a Recommended Draft Policy. I'll be asking for those in the room for a show of hands for those who support the policy as proposed and those who are against.
So I'd ask first that the remote poll be opened. And, again, it's a good stretch break after last night's social. I'll ask on the matter of 2014-22, Removal of Minimum in Section 4.10, those in favor of the proposal as written please raise your hand and keep it up until our counters have -- no hanging chads or anything.
You may lower them. I'll ask now those opposed to the proposal, please raise your hand nice and high.
You may now lower your hand. And I'll speak slowly so the remote participants can get in since there's a little bit of a lag on the video. Please stand by as we wait for the envelope, please. I could sing as the others have, but we'd have to clear the room for the next proposal. And that wouldn't be a good thing. So...
Thank you, sir. On the matter of 2014-22, Removal of Minimum in Section 4.10, the number in the room and online, 111. In favor, 14. Against, 14. Am I reading that handwriting correctly? Is that a nine? In favor, 14; against, 14. This input will be provided to the Advisory Council for their consideration.
Recommended Draft Policy ARIN-2014-1: Out of Region Use
John Curran: Okay. Moving right along. Next policy is Recommended Draft Policy ARIN 2014-1: Out of Region Use. And I'll do the introduction and then I'll have Milton give the presentation.
Okay. So this started in December 2013. The shepherds are Milton and Tina Morris. It's been presented at NANOG 60, ARIN 33, the Public Policy Consultation at NANOG 61 and 2, ARIN 34, presented at the Public Policy Consultation at NANOG 63.
It was advanced by the AC to Recommended Draft Policy in December 2014. It had an updated legal assessment. Actually was reposted just this week and again this morning in March of 2015. The text is in your guide, along with the updated legal assessment.
The policy would allow out of region use of ARIN issued resources so long as the requesting organization is presently an ARIN registry customer and using the equivalent of a /22 IPv4 or /44 IPv6 block or an ASN or on infrastructure physically within the ARIN region.
So if you are presently an ARIN customer with one of those assignments, v4, v6 or an ASN, use the new infrastructure within this region, then you can request resources for use which are entirely outside of this region.
So we've never considered your demand for resources outside the ARIN region as a justification for new Number Resources. We would now consider it under this policy.
An officer attestation would be required to verify the resource request is not a duplicate if one made to another RIR. Obviously, if you just requested from another RIR for addresses to numbers for infrastructure and then you come to us and ask for addresses to number the same infrastructure, that wouldn't exactly be good. So we have to tell you you're only asking from us.
Currently, ARIN policy requires organizations to show justified need for resources to be used specifically within the ARIN region in order to receive Number Resources from ARIN. If the Draft Policy were adopted, you could now request resources for use for your infrastructure and customer demand in other regions.
When processing resource requests in other region, ARIN staff would include any address space registered in another RIR and currently used or available to be used in evaluation. So if you had address blocks registered to you in another region, we would say you already have address space. You have to actually have need that was unsatisfied.
It adds a new requirement that we review utilization outside the ARIN region, which has implications for staffing. It could be complicated in some circumstances.
It would be put in the NRPM as 2.1.7, Out of Region Use.
Assessment. Three slides. I'll go through them briefly, but you have the full thing. This is a complicated issue when it comes to legal aspects, because ARIN has 15 years of experience operating in the region. And this would exacerbate uses that are out of region.
So the first one is that we do have a -- Milton, are you okay?
Paul Andersen: He's going to cover these slides.
John Curran: Understood.
We do have an agreement to be part of the ASO. The ASO agreement includes a reference to a policy called ICP 2. ICP 2 is the policy for establishment of new RIRs, and it sets out some agreed principles for RIRs, including that they should each serve a single region.
There's some question as to how we would reconcile this policy with the intent behind ICP 2 to have RIRs serve a single region, and that's been discussed on the PPML Mailing List a bit. I'm sure we'll be discussing it later.
If the policy is adopted, we could arguably become jurisdiction to governments outside of our service region, their laws and similar. Even though we'll be contracting with a party in our region, the fact is we're providing resources which would use equipment outside the region. And we have had cases in the past where people get confused about whether or not we're subject to their jurisdiction as a result.
There are some countries that if you asked for resources entirely outside the region, even though your entity is here in the US, when you ask for them and you tell us it's for use in a certain country, we may not be able to fulfill that.
And so we just note that even if the intent is that we could, there's export controls and embargoes, for example, where we probably couldn't knowingly issue your resources if the justification was on a country on a certain list. So you need to keep that in mind.
Finally, this obviously would attract the attention of some governments. Governments would wonder if we're supposed to be serving the community in this region, why are we issuing addresses for entities in this region who are going to use the Number Resources entirely out of the region.
One could argue that we're still serving the entities in this region. One could argue that we're not. We're serving their subsidiaries and related partners somewhere else.
It may not match the expectation of some of the political entities. And then there's a fraud issue here. We currently have more difficulty processing requests that involve customers and resources that are being used to some extent out of region. And that does happen.
People justify things based on equipment in this region and cite customers that are in another region. It gets very complicated.
Very hard to validate. We've worked with other RIRs on occasion. But our ability to validate a request coming in under this policy obviously is not the same as our ability to validate a request that comes in for resources for use in the region.
So that's the legal assessment. It's a significant policy to implement. Now, there's a little bit of interest here. This policy allows us to issue Number Resources from the free pool. The free pool is rather low.
This policy may take five or six months to implement, because of the complication involved.
I could argue it may not be possible to get this policy done in time to actually have resources issued from the free pool per the policy. You just cannot tell.
Additional time to review resource requests for out of region use will now be included in the analysis, and engineering efforts to handle it could be substantial. We haven't actually -- we need to assess based on when we see the policy and the degree of automation that's possible.
I'll now turn it over to Milton, and he will do the AC introduction.
Milton Mueller: Hello, everybody. So I'm going to spend most of my time here repeating what John just said.
This is a summary of the policy. It basically is designed to allow out of region use. The policy is designed to make sure that there is some nexus, some kind of connection to the ARIN region, and you see the requirements there.
They're presently an ARIN registry customer. They can't be complete strangers and currently be using the equivalent of a /22 v4 or /44 v6 or ASN on an infrastructure physically located within the ARIN region.
And, again, in order to -- as John said, in order to avoid duplication, we are having an officer attestation.
Here's the problem statement. There is an ambiguity in policy. It neither clearly forbids nor clearly permits out of region use.
This whole policy got started with an earlier proposal, was an attempt to eliminate or ban out of region use and to tie the use of the resources more directly to the service region.
And that turned out to be completely unacceptable to the community as a whole. And so the next step was to say, well, then let's legalize it and try to define how it would work.
So that's what this proposal does. That's the problem statement that we're trying to solve is to clarify this and make it unambiguous regarding what is the status of out of region use.
Note the boldface there: Staff has been counting utilization as in region only when the least specific prefix is routed from within the region.
John spent quite a bit of time on this. But I'll go over it again, just because it's so much fun.
We did get a statement from the council that the requirement for this in region nexus improved the proposal. There were concerns about the policy's consistency with ICP 2. Council is concerned the absence of any real need for in ARIN region will result in additional fraudulent requests. And then there's these larger questions about -- basically about the nature of regional and territorial exclusivity within the RIR system.
But as we recall from our discussions, there are no actual legal reasons to prevent the implementation of this policy, if the community wants it.
Here's a bit about ICP 2. It's titled Criteria for the Creation of New RIRs. It's not itself Number Resource policy, but has an important role in defining aspects of the RIR system. It tells you when you're creating a new RIR that its service region should not overlap with existing ones. But it doesn't discuss directly the relationship between the use of resources and the RIR service regions.
So this debate is one that we should have here today about this relationship between the proposed policy and regionality, if you will.
IPv4 scarcity is a big factor in assessing the policy. As John noted, it may become a moot issue. But there is a sense that because ARIN has a free pool that has lasted beyond APNIC, in particular, and perhaps some other RIRs, that there would be attempts to grab some of those resources by utilizing this policy, and in fact it's already going on without this policy. So there's some fear from the council that this would exacerbate that issue.
So let's open it up for discussion.
Paul Andersen: All right. We'll open the microphones for any discussion that people want. First gentleman.
Mike Joseph: Mike Joseph, Google. I think it's very important to recognize that the idea of servicing is distinct from the idea of routing.
When the RIRs were formed, the idea was that your RIR would be local to you, near to you in your time zone and service you in your language.
We can see this in the way the Caribbean is split up in fact between LACNIC and ARIN.
There was never a concept that RIRs would have some sort of private entitlement to addresses that would be split between them. In fact, when any RIR ran out prior to IANA exhaustion, it simply got more from the IANA free pool.
So this idea that we would somehow have a dedicated resource pool specifically to protect North American interests just isn't consistent with the idea of the RIR servicing.
An entity based in the ARIN service region should be able to be serviced by ARIN in their language, in their time zone, in their currency.
There's never been -- prior to a couple of years ago when ARIN changed its interpretation of section 2.2, there has never been a problem with any entity receiving resources from ARIN and using them globally.
Even today, provided you have an aggregate that covers, that is announced at least in part within North America, you can be serviced by ARIN.
Yet, miraculously, we don't seem to have a problem with ARIN running into legal troubles in many other countries, despite the fact they've been doing this, well, since they were founded.
We don't seem to have a problem with RIR shopping any more than we do now. And, quite frankly, the idea that we would somehow require entities based in the ARIN service region to set up legal offices in every region they want to operate to require resources there is a little bit absurd.
So I understand that staff and particularly legal assessment has raised a number of risks, but, quite frankly, I think some of those risks are a bit of a red herring.
At the end of the day, you know, you have to get your addresses from somewhere. And we're not really talking about the free pool at this point. We're talking about being able to be serviced from your home RIR.
Paul Andersen: Okay. In support or --
Mike Joseph: Yes, I'm in support of this proposal.
John Curran: Question from staff. When you discuss the regions, you talked about the purpose of the regions being for the ability to service someone in their language and in their time zone. And that's a big part of the Regional Internet Registry System.
Presently, the scope of policy also applies to a region. So ARIN's policies apply to resources in the ARIN registry, which are resources within the ARIN region.
I guess the question is, to the extent that resources in another region are in the ARIN registry, okay, so resources --
Mike Joseph: Resources used in another -- you mean resources announced?
John Curran: Issued for use and wholly used in another region.
Mike Joseph: Issued by ARIN.
John Curran: Issued by ARIN per this policy, if adopted, would be address blocks issued by ARIN but wholly used in another region. Okay.
My question is that some of the regions might wonder why their policy doesn't apply. Do you see that as a problem?
Mike Joseph: Has it been a problem for any of the resources currently in ARIN's database used outside of ARIN's region?
John Curran: Whether or not that exists, I don't know. But my question is --
Mike Joseph: I think we know it exists.
John Curran: If we are consciously doing it, do you see that that might be a problem?
Mike Joseph: It doesn't seem likely to be a problem, particularly because no one has resources in the free pool at this point.
John Curran: Now I'm going to ask the converse. If that happens in the ARIN region, okay, so entities, RIRs have resource blocks in the ARIN region, for example, an RIR were to say that they're transferring an address block from an ARIN region entity to another RIR region entity who happens to have a subsidiary in the US, that is very similar to what we're talking about.
It's them providing registry services to a block wholly within the ARIN region because it's a subsidiary of an entity that's in their region.
Once that happens, that transfer would no longer be subject to ARIN's policies. That's okay, though, because it's not about policy continuity, it's about servicing people in the language through the organization they're working with, correct?
Mike Joseph: Absolutely. That transfer could go to an entity that's not using it in the ARIN service region. The ship on keeping our address space in our region sailed quite some time ago, in particular with Section 8.4.
John Curran: I'm not talking about keeping address space. I'm referring to --
Mike Joseph: Controlling address space.
John Curran: This means people can transfer address space to another region in the ARIN region.
Mike Joseph: Someone can transfer --
John Curran: If they have an --
Mike Joseph: Why is that more offensive than transferring address space to another region for use in that region?
John Curran: I'm not saying it's offensive or not. I'm just saying I'm not sure our transfer policy is applicable in that case.
Mike Joseph: I'm not sure it wouldn't be. If you have a multi national in some other region that wants to receive address space that they might later use it in North America or that they might immediately use it in North America or that they may never use it in North America is really orthogonal to the transfer policy.
With respect to this policy, we already have no mechanism by which to prevent another RIR's address space being used in North America. I can speak to a major US carrier, carrier active in the US that's using APNIC space. We've seen carriers use RIPE space in the US.
This has been happening for a decade. So there's no current mechanism nor is there any really desire in the Internet community to require address space to only be used in the region from which it is assigned or allocated.
So I don't know why we would seek to institute such a requirement now. And in fact it's only in the last couple of years with ARIN's reinterpretation of Section 2.2 that it's gotten even more difficult in this particular region to use address space globally.
John Curran: I want to clarify. To be clear, my question is is adopting this policy would reflect that it is not necessarily the case that address resources should be in the registry for that region and may have implications to a lot of our other policies if applied by other RIRs.
So my question is: You don't see any concerns with that; and if that's the case, those shouldn't hinder this policy.
Mike Joseph: It's already the case, and I don't see any concerns with that.
John Curran: That's all I want to hear.
Paul Andersen: Mike, don't run away. I appreciate you've been up here a bit, but I think Milton had a follow up question. Sorry, Milton.
Milton Mueller: John, in the discussions on the list, we have established that neither you nor the council have any
objection to some of the resources being used out of region for a multi national, right? And I think the big line of division here is you're saying that none of the need that would justify the request would be in region, as long as we had this nexus, right?
So the implication is that --
John Curran: I'm not sure what you're asking.
Milton Mueller: The implication you're giving me is let's suppose that they needed a /16 and only let's say 10 percent of that was actually needed in region, the other 90 percent was going to be used out of region, you would be okay with that, counsel would be okay with that; is that correct?
John Curran: I'm okay with anything that you guys adopt. Couldn't care less. Right now we don't count need if it's based on out of region use. If you say I'm going to use it and 70 percent of my demand is from another region, we don't count that 70 percent.
Milton Mueller: Okay.
John Curran: If you pass this policy, we'll count that 70 percent.
Milton Mueller: That's what I wanted to clarify.
Jason Schiller: If the use out of the service region is part of a global network and the addresses are used in part in the service region, in part out of the service region, the use out of the service region in that global network today is counted.
John Curran: Is counted. That is correct. If the request is spanning and it's from a global entity that's requesting from our region, we'll count their use globally.
When they come back and say I have an address block entirely within another region, we don't allow the request unless there's some use in the ARIN region.
Paul Andersen: Thank you, Jason, for that clarification. Milton, did that address your question?
We'll go to Leif for another question.
Christoph Blecker: Christoph Blecker, Walt Disney Company: While this policy may not be implemented before the IPv4 free pool is exhausted, would this policy apply equally to other Number Resources like IPv6 and ASNs?
Milton Mueller: Yes. The answer to that is clear. It's yes, right.
Paul Andersen: Next speaker.
Lee Howard: Lee Howard. So I don't bury the lead, I oppose the draft as written. This feels like an end run around Section 8.4, Inter RIR Transfers, which I think -- I can't tell whether that's intentional or not, but I think that may be a ramification. I think we need to address that in the text more clearly, what the implications are specifically for transfers. Because, as John pointed out, it will probably only be able to apply to transfers. And I'd like to see it rewritten with that emphasis in mind.
Paul Andersen: Thank you.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, speaking strictly for myself. I do oppose the draft as written. However, I do not oppose the intended concept. Contrary to the statement just made by Mr. Curran, I have had a number of clients for whom I have sought address space for use in and out of region combined who have been told that they can get the address space for the sites they have in region, but that they cannot get address space for the sites that are not in the region from ARIN.
Further, they have been told that their existing out of region usage does not count as valid utilization of their ARIN issued address space.
So it would be nice if that problem could be solved without needing some sort of written policy to get ARIN to do what has been said. But that has not been the case in recent history.
Paul Andersen: I'll ask for response.
John Curran: When you come back for additional allocation, that might be the case. The circumstance is whether or not when you make the application, what you say you're doing with the address block and how you're routing it.
We're happy, again, to have the situation clarified by the community. But you've got to provide clear policy on what you want us to do. Right now it is not clear in the policy because we are an RIR that's supposed to serve this region.
We actually asked whether you're going to use it in region. If you put in your application you're not, you're going to break it up, then, no, you will not -- the stuff that you're not going to route in this region we will not consider. And that's been documented in a Policy Experience Report several times.
Paul Andersen: Any comment, Owen?
Owen DeLong: We weren't asked whether we were going to route it in region or not. We were asked where we were going to put the addresses on machines. And what we said we were going to put on machines in locations, not in the region, irrespective of where we were going to route them, which was never asked of us, caused ARIN to tell us: Pound sand.
Paul Andersen: Hang there for a second. Milton has a question.
Milton Mueller: You said you oppose the policy, but you just gave us several arguments in favor of out of region use. Can you tell us why you oppose this policy as drafted?
Owen DeLong: I believe the language as drafted opens up a number of rat holes and areas and that this particular cure is actually worse than the disease.
Paul Andersen: Owen, you don't get away that easily. Go ahead, Milton.
Owen DeLong: I'm trying not to monopolize the mic.
Milton Mueller: How is it worse than the disease? I don't understand how this -- I just want to get your --
Owen DeLong: I think reading counsel's objections, several of the objections are valid. I don't think all of them are necessarily correct, but I think that this does create too much potential for abuse of the address space by entities that don't really have strong ties to the region and are simply trying to circumvent policy.
I believe that the policy proposal as currently written allows for too many loopholes and too much potential for abuse.
Paul Andersen: Thank you very much, Owen. Leif, anything in the queue?
Next speaker, please.
Please approach a mic, by the way, if you would like to speak. The queue is depleting.
Andrew Dul: Andrew Dul, ARIN AC, speaking for myself. I generally support this policy and concepts therein. I am hedant to the issues that were raised both by staff and legal assessment.
And I would like to propose a specific change to the policy to potentially alleviate some of the concern.
And the potential -- the change that I'd like to suggest is that we require a small percentage, perhaps 10 percent, of an additional allocation or assignment request be used in region.
And if we could discuss that here, that would be helpful, I believe, to the AC. And I would also like to ask if staff or legal would change their opinion of the current draft if such an amendment was added to the policy.
Paul Andersen: So that's -- first, Milton, I don't know if you wanted to comment on that, and then, John, if you --
Milton Mueller: I would like to. I think this is -- you're really dancing around a paradox here. Either the number space is a global resource, in which case the fact that you happen to be in a region, why shouldn't an RIR serve all of your numbering needs regardless of where they are.
Or you're going to -- if you're going to tie the number space and fragment it by region and say you have to have five accounts in five RIRs if you're going to be in all of these regions, I mean, be consistent about that.
And even go all the way and let's go to NIRs and have it all tied to jurisdiction so that the law enforcement people will be happy.
I think we really have to think seriously about one or the other and these kinds of thresholds like the 10 percent, it seems very arbitrary to me.
I don't see why, if you're using 90 percent of the request outside the region, why does that not pose the same problems that counsel is concerned about than if it's in region. We already have some kind of a nexus requirement. So how does that threshold --
Andrew Dul: I agree with most of your arguments, Milton. I'm attempting to provide a solution around the objections that have been raised by the legal assessment and the staff assessment of the policy to see if we can alleviate some of those issues.
I don't necessarily --
Milton Mueller: Political compromise.
Andrew Dul: Yes.
Paul Andersen: You're in support of the policy, but you're just suggesting something you think may make it palatable to those who are opposed?
Andrew Dul: I am in support of the policy and suggesting an enhancement that would perhaps alleviate some of the concerns that have been raised so far.
Paul Andersen: Just one second. Quick staff response.
John Curran: Andrew, actually the earlier drafts of this policy had exactly that. And the staff and legal was much shorter than in this one.
Paul Andersen: So Jason --
Andrew Dul: I take your comment that adding such a requirement would alleviate some or most of the issues raised by staff and legal with the implementation of this policy?
John Curran: It depends on the language, obviously. But I guess I'll say many of the paragraphs in the staff and legal assessment of this policy come in the current version, which makes clear that the resource usage could be exclusively and entirely out of the region.
So when that appeared, many more staff and legal comments appeared.
Paul Andersen: Microphones will have to close shortly. Thank you, Andrew.
Jason, did you have a quick interjection?
Jason Schiller: I just want to make sure I understand Andrew's suggestion of the change, and that is for each aggregate that is asked from ARIN, some percentage of that be used in the ARIN service region? So, for example, if you're an existing ARIN member, using a /10 of address space in ARIN and you need a /22 for your European expansion that you want to use exclusively in Europe, you could not do that? Is that correct?
Andrew Dul: That's correct.
Paul Andersen: Thank you.
Scott Leibrand: Scott Leibrand, Twitter. I believe that the ARIN staff's insistence on dealing with individual blocks as if they are somehow a distinct entity that must be used partially in region if you're going to use some of it out of region is ignoring the way that addresses and address holdings actually should be considered, which is as a whole in aggregate based on the holdings of a company.
So if a company, like Jason just mentioned, has a large quantity of address space, is primarily headquartered in the region, is a multi national but has expansion desires overseas, and they wish to acquire addresses from ARIN, presumably via transfer, by the time this gets adopted, we are attempting to create, in my opinion, stupid hoops to jump through with regard to usage of some of that addresses in region for no good technical reason.
The desire to maybe not allow an organization with just a business nexus to get addresses solely for outside the region, if they have no presence here and no operations here, might be sensible.
But the considering of these address blocks as individual blocks that must be considered identically makes no sense to me.
I support the proposal as written. I would support a number of modifications that have been raised to make it more palatable. But I think we really need to consider whether this -- whether what we are doing is simply ticking boxes and making bureaucratic hoops to jump through that make no sense.
I really don't understand why we can't just say yes, you are getting address space, you are an organization, region, you're dealing with ARIN because you're here and ARIN is here and that is the way business runs and let people get the addresses they need via transfer and use them wherever they want, without having relationships with every single RIR on the planet in order to be a global company. That makes no sense to me.
Paul Andersen: Thank you for your comment.
John Curran: I have a question for Scott.
Paul Andersen: Quickly.
John Curran: Scott, that was -- what you just said was what ARIN staff said in ARIN 31 in the Policy Experience Report and said: Is there better policy that can avoid this problem?
So in Barbados we gave a Policy Experience Report that said this is an issue that people are coming to us with, how should it be solved?
That led to an earlier proposal of this draft but it wasn't a draft to say all address usage should be out of region, it was one to better define circumstances where someone could get an address by coming to ARIN.
Scott Leibrand: Right, if I remember the discussion there, the community basically said quit putting so many restrictions on how exactly we can do this, and so the AC went back and they put together a policy that has fewer restrictions and now ARIN staff is saying no, no, no, we need restrictions.
John Curran: We're happy to implement the policy as is. There's no problem with it. There is a staff and legal assessment that says what will happen. That doesn't mean it can't be implemented. If this is what the community wants, then we'll implement it.
But you asked the particular question. Your question was: You don't believe that the block usage requirement that ARIN presently implements is correct. And I'm saying we're not sure it's correct either, and that's why we brought it to the community.
Scott Leibrand: My point, though, is that ARIN staff seems to be talking or ARIN staff and legal as a whole, which I know you guys are not the same, are talking like out of two different viewpoints in that there is John saying you can do whatever you want, then there's very strongly worded cautions against doing what we want.
And I do not understand why ARIN staff and legal is so concerned with doing what we want.
And maybe you're not -- maybe it's a perception issue, but -- I don't get it.
John Curran: Read the staff and legal. If the risks that occur there occur, okay, none of them say ARIN disappears. It says we spend more time processing requests.
We will get asked by governments what does the ARIN community think it's doing. We will be approving requests we probably can't validate. None of them says ARIN will go out of business, ARIN will be litigated into not -- it says this will cause all sorts of interesting problems that we have to deal with including questions to the community, including issues to deal with, but if that's what you want, it's a normal course of business, if that's what the community wants.
Scott Leibrand: Okay.
John Curran: Nothing in those strongly worded things say this is a risk that ARIN cannot as an organization undertake. The Board of Trustees is going to look and go, wow, they really want this and here's some issues, but at the end of the day it's got to decide whether the risk is reasonable.
Scott Leibrand: Okay. Thank you. I like that clarification. It certainly puts it in perspective.
I would say that it's important for --
Paul Andersen: We're getting tight on time. If you can keep it to a tweet level. You are from Twitter.
Scott Leibrand: I have some practice at that. Is this policy proposal necessary for ARIN to do what the proposal intends for IPv6?
Paul Andersen: Who are you asking? Are you asking John?
Scott Leibrand: John. I believe in previous -- that's the challenge of putting tweet level or tweet length things into question.
I've heard in the past that we already do the right thing for v6. Is that true or not? We already do what this policy proposal intends in v6.
John Curran: When you come to ARIN and you ask for a v6 block, you're generally saying a little bit of it is going to be used in the ARIN region. Once we give you the block, there's usually enough that you can use it absolutely everywhere and not have any trouble. But that's present circumstance, okay.
If you were going to come to ARIN and you were going to ask for a v6 block and say, by the way, none of it is going to be used in the ARIN region, you might have a problem today. I don't know why you would say that, but you would have a problem.
Scott Leibrand: I think we need to be very clear that this really only matters for transfers. And I do support the proposal.
Paul Andersen: Thank you very much. We have a bunch of speakers in line, and a few up on stage and remote. So if you could keep your comments succinct and new, that would be appreciated, as you can do.
Next speaker, please.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I'm speaking strictly on my own personal behalf.
I've thought a lot about this issue, and it's troubled me a great deal, about how to deal with the legitimate need versus some of the risks that have been identified.
So the problem statement is to clear up ambiguity regarding out of region use of ARIN registered resources by clearly permitting out of region use while addressing some of the concerns expressed about unlimited openness to out of region use.
So the first thing that troubled me was the fact that we're addressing some of the concerns. The other thing is in looking at whether the proposal conforms to the principles of Internet Number Resource policy, it seems to me that the policy is likely to benefit in the way that it's intended to benefit, a relatively small number of global networks obtaining resources from ARIN.
On the other hand, we've identified substantial legal regulatory and operational risks that could really dilute the operation of the RIR system or at least making it very difficult if not impossible to determine what policies apply to registered resources, both in and out of region.
This could occur by making ARIN resources subject to the laws of out of region countries by inviting greater in region government scrutiny, if there's disagreement with how we're doing things, and perhaps most importantly by inadvertently facilitating fraudulent transactions and inviting other RIRs to serve the world to a much greater extent than is the case.
So we have to ask ourselves: Why is this happening now because of IPv4 scarcity especially in other regions?
Now, it may be true that some fraudulent requests get through now, but do we want to adopt a policy that increases these risks substantially and accelerates IPv4 exhaust.
When I look at all these factors, it seems to me that the proposal doesn't meet the requirements for proper Internet Number Resource policy. This does not enable, in my view, fair and impartial Number Resource administration.
The proposal would benefit a relatively small number of global networks, but would do so by increasing legal regulatory and operational risk for ARIN in a manner that disadvantages the community as a whole.
There are simply too many potential unintended consequences. This is not good stewardship of numbering resources.
I'm not saying we don't need a clearer policy to address the problem. We do. But the cost of this particular proposal to the community simply outweighs the benefits by too wide a margin, in my view.
We need to go back to the drawing board and come up with a policy that clarifies the issue while ensuring that those requested resources from ARIN have some sort of material connection to the region.
We may need to work on what that materiality test is so that policy implementation can be predictable and understood by the community as a whole.
But swinging the gates wide open now as the current proposal would do is not the answer due to the increased risk of unintended consequences. For those reasons, I vigorously oppose the proposal.
Paul Andersen: Thank you. We have a question for you, and two questions --
John Curran: You twice said the proposal is going to benefit large global corporations. Is that correct?
Chris Tacit: The ones from in region would be intended to.
John Curran: I don't know who it will benefit. But I want to point out at the present stage of depletion and the way that allocation policy works, it's unlikely we will see a large global corporation come in to request -- because there's not much space left -- to request a relatively small snip of space based entirely on the fact that they intend to use it in another region.
I'm not saying it's not possible, but the number of such large organizations who might catch the window of this policy is probably a very, very small number compared to, for example, many small organizations who could take advantage of this and for whom the address size available is significant, monetizable, et cetera.
Paul Andersen: Quick question from Milton.
Milton Mueller: Quick indeed. Hopefully this is a yes or no. You say -- you talk about swinging the doors wide open and the need for some kind of connection to the region. Are you familiar with the policy's requirement for a nexus?
Chris Tacit: Not closely, no.
Milton Mueller: Okay. So there is one. You might take a look at it. If you do take a look at it, you might want to explain why you think that's inadequate, because I didn't hear any reason.
Chris Tacit: Sorry. Are you talking about this policy's nexus requirement? I am familiar with it, because I think it just opens up the potential for fraud too much. I mean, it makes it extremely hard operationally to avoid situation in which fraudulent requests will increase.
Milton Mueller: One other question. So if, again, we have this network that's requesting resources and 90 percent of them are going to be used in region and 10 percent out of region, you're okay with that, but you don't think any of the same problems are raised?
Chris Tacit: Look, I'm saying we need to shift the debate from materiality in a way that reduces the risk. This a risk management issue for the organization, in my view. That's what it is. And what I'm trying to saying is that we're way too far high on the high risk aspect of the continuum.
As John pointed out, previous iterations that define the solution somewhat differently had a lower risk assessment associated with that.
Milton Mueller: I don't understand how 10 percent and 15 percent is not a risk. I don't understand the percentage relationship to the risk. Can you explain that?
Chris Tacit: As I said, it's not simply about the quantity, it's about what it opens the door to in the way that it's constructed. So I'm not going to try here and fashion a solution on the spot, because I don't think that's easily doable.
I'm just saying that my bottom line message is we're way too far on the continuum of high risk for reward relative to the intent of the policy which is legitimate. I have no issue with the intent and what we're trying to do.
I just think that the way that we're going about it in this iteration, if this goes forward, is too risky for the organization and could actually create a whole host of problems.
Paul Andersen: Milton, is that okay? Thank you.
We're going to go next to remote participant. Having said that, before we do, if the queue is kind of long and we're also getting to the end time, when he does his comment, that will be the close of the mic. So I see the gentleman behind, right there, at the end. Wave your hand if you think you're last in line. That will be last unless someone can sneak in quickly.
Leif, if you can -- you're next, Kevin.
Leif Sawyer: This is a question directed at Andrew from Jon Lewis, Highwinds. He's saying: What you said makes no sense. If you're requesting space for an out of region POC, how can you use 10 percent of it in region?
Paul Andersen: If you can quickly respond at the front mic, that would be great.
Andrew Dul: What I would say is while what I proposed may not make sense in some situations, the idea was to add a rule such that we move the bar toward requiring an entity to have some additional need within the region to basically substantiate the continued nexus of the organization's use within the region.
I have a proposed text adjustment if you would like to talk about it at some point.
Paul Andersen: That's done on the Mailing List I think at this point given time.
Kevin Blumberg has been next, and then we'll clear the lines. And the lines are now closed.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, speaking on my own. I don't support this policy. I support the concept at the highest level, but I really don't support where this policy has gone down.
We use the word "we." I've heard the word "we" mentioned probably 100 times. And "we" applies as the community when we're talking about our community, but really when we're talking about the global RIR community, you should be changing the word to "I." "I" want this. "I" want that. I know there's other people in this community globally, but I, I, I.
So I really want to just go back to that concept and ask is this best suited as a global policy where we as the community go to the RIRs and say we would like your permission, we would like to have a situation of a home base RIR concept in the most simple form and have the community agree -- the global community, not the individual region that wants its piece of cake its way, but doesn't realize that the other regions are allergic to that piece of cake, too.
So that's my view on this.
Paul Andersen: Thank you for that comment. Okay. I know we have a list, though. If you can try to keep your comment as best you can under a minute, I'd appreciate it.
David Huberman: David Huberman, Microsoft, and I've got a lot to say.
Paul Andersen: Thank you for your consideration.
Well, we're here to work. And we take a lot of breaks and we eat a lot of food and we do a lot of drinking. Maybe we should do more working. Because we spend money. And this is more effective than a Mailing List, in my opinion.
Lee, where did you go? There he is. Lee Howard. So, Lee, you got up to the microphone and you talked about a runaround around 8.4. And the problem I had with that opinion was 8.4 today only works for APNIC and is about to work for RIPE in August.
I know companies like -- rhymes with like to loft. And companies operate on different continents, and some of those continents don't have reciprocal needs based policy. And the machines still need to be numbered and the network still needs to be built and the network still needs to grow.
And if there's space available -- in the post exhaustion world, all you're doing is buying IPv4 address space. Okay? As a reasonable consumer, you're going to buy it where you can get it cheapest.
If that cheapest is at ARIN and you need to use it in Argentina, you've got to be able to do that. Okay. ARIN policy does not tell staff what to do right now. And that's a problem, because the staff have a different goal than we do as network operators.
The staff have been inundated for years by fraud. And so many of John's comments on behalf of the Board or on behalf of the staff or however it is you talk are so much from the viewpoint of fraud, because it's what you deal with every day and it's one of the biggest risks to the organization.
In a post exhaustion world, we need to rethink how we're doing this. As a community, all of us need to rethink this.
Current ARIN procedure is to say you cannot have a block from us, v4, v6, or AS number, unless you are routing the least specific or routing the AS number in the region.
And you know why that procedure exists? Because 10, 12 years ago it was important because people did this thing called RIR shopping. This was a very real thing. A company who -- a person who wanted to anycast in Europe could not do so properly. They could not get the /24s they needed to do their anycast, which at the time was one machine, one IP address out of a /24, because RIPE rules did not allow it.
So they come to ARIN, which has a specific policy that did allow it in that case, and they said hey, you give us your space. And we said no, you don't meet this procedure, which is trying to stop RIR shopping, because that was seen as a bad thing.
But v4 -- in the policy discussions, we have to assume v4 is not available from the RIRs.
Milton very kindly asked for a discussion about regionality. He asked for it on the list and he asked for it here. And we're getting bogged down on existing procedure, which is completely predicated on a v4 free pool. So I would like us to think about and discuss on the Mailing List and at future meetings that we really have to rethink things in a v4 exhaustion world.
Okay. And that's all I have to say.
Paul Andersen: But don't -- I know I said a minute, but that didn't -- I didn't say about these guys. John had a question and then Milton, too, I believe.
John Curran: I agree with everything you just said. I want to ask: Do you believe to solve that problem of the going forward, post depletion world, it's best solved by addressing an allocation policy via 2014-1?
David Huberman: As I said on the list the other day, I think the comfortable answer to that is put this in post exhaustion at ARIN, because then you're primarily dealing with IPv6 addresses, the IPv6 blocks, and we as a community should be happy to give anyone an IPv6 block who asks for them, no matter where they're at, and an AS number, which, mathematically, I'm sorry, these are basically infinite now, for now anyway.
Paul Andersen: Famous last words, right?
David Huberman: No, I don't buy into that. I know you don't mean it like that, but you hear that in v6 all the time, and it drives me nuts. Yeah, I think I'm fine with it in principle, to answer your question.
Paul Andersen: It's actually my fault, were you in favor or against? I apologize if you did state it, because I missed it.
David Huberman: I'm not speaking in favor or against the policy. It's general commentary. I have the utmost respect for the work that Steve Ryan has done tirelessly on behalf of this organization and this community, and when he espouses very strong words, it behooves us to listen.
At the same time, many of the arguments that are being championed by Milton are also persuasive. And as an operator, many of these issues affect me directly. So I'm not in favor or opposed. I'm not going to vote on this.
Paul Andersen: Next comment, please.
Mike Joseph: Mike Joseph, Google. Again.
Like David, I have a lot of respect for ARIN counsel. We've worked with them for years, and they've produced a very thorough legal assessment of this as they've done for most other policies.
But at the end of the day, as John pointed out, it's imperative that we as a community understand that the legal assessment is typically going to be a more cautious one. It's designed to outline potential risks and possible corner cases that could result to the ARIN organization.
But like any organization, legal advice is just that. It's advice. And ultimately we need to adopt what's necessary for our organization and for the community as expressed through the Board and through the AC.
And so while I appreciate the input from counsel on this, I think that input notwithstanding this input is important.
Earlier it was suggested that we might somehow tweak the policy to add sort of arbitrary utilization requirements like 10 percent of each new block to somehow assuage this legal requirement. But, first off, this community considered exactly that, and it was rejected. So I don't think that's likely to surface again.
More to the point, it doesn't really serve a purpose. It's kind of absurd. We already have blocks today. I can get a block from ARIN, use it for a while in region and then decide at some point I need to use it out of region; that somehow that changed the use of that block that subjected ARIN to that country's laws, it doesn't. It doesn't in a way that hasn't happened for decades.
And, quite frankly, you know, one of the earlier comments mentioned that the reason we're seeing this today is because of v4 exhaustion, but that's not true. It may be an ultimate reason, but the reason we're seeing this today is because ARIN staff changed interpretation of Section 2.2 approximately two years ago when, as David pointed out, they instituted a procedural change to begin asking requesters about regionality of use.
And that's why we have this policy here. And that's why it's important. This is not affecting a couple small organizations, a couple -- a few corner cases.
I would argue that this is affecting a significant double digit percentage of ARIN's address holdings, because there's a massive amount of ARIN's address holdings used by multi nationals or used on global networks.
And this is a real technical problem. This isn't simply a matter of having a choice to go to other RIRs. If I have to run a circuit to Europe, do I have to get half a /30 from ARIN and half a /30 from RIPE now? This is ridiculous.
We've used our number space globally since its inception. We must continue using our number space globally. And today, even today, and no disrespect to John, we still can't manage to articulate exactly what the bar is for an organization to get address space.
If they mention the right incantation on an address request, it seems to be okay, but if you somehow slip up, as Owen did, it just doesn't work. And this is an untenable situation for ARIN as an organization and for us as a community.
So we must move forward on this. We've been debating it. As John mentioned earlier, it's not up now, but this has been under debate for multiple sessions. And we have to move forward on this, because today it is completely unclear to organizations and to ARIN staff what they ought to do with respect to space that's used globally.
And, finally, on the question of RIR shopping, as David pointed out as well during his comments, there is no reason anyone who is RIR shopping at this point would prefer ARIN. We have more strenuous policies and higher prices than other RIRs. So there's no financial reason and there's no policy reason at this point that entities who are transferring address space would shop.
If you're in RIPE or APNIC, you can do a Section 8.4 transfer, which is easier than this because it doesn't subject you to ARIN's detailed justification requirements, which are greater than the required in most other regions.
If you're in LACNIC or AFRINIC, congratulations, you have space there anyway.
So there's no concept of a free pool left with respect to this policy.
This is about making sure that entities that have global operations can actually operate. And, by the way, they already do. So this really just clarifies how ARIN interacts with them and tries to normalize it. So I continue to support this policy.
Paul Andersen: Thank you very much.
Bill Woodcock: Bill Woodcock. This policy is a mess. It talks about allocations and thresholds and amounts and ratios and
it's got everything but the kitchen sink in an attempt to address all of the symptoms. And every time somebody suggests yet another problem, then there's yet another symptom that needs to be addressed. And somebody suggests glomming more text on to it, and it just becomes a bigger and bigger pile of garbage.
What we have here is a problem that is a serious problem that is affecting all of our constituents. And the problem is that we've got mounting bureaucracy that makes it difficult to do our jobs. This is an issue about organizations, not an issue about addresses.
The problem is not that we need to keep ARIN members from taking some of their blocks and using some of that space in other countries, because that's just what we need to do for our business. Right? That's who we are and how we make our livings.
The problem is that we don't want organizations that are not ARIN constituents to come here and raid the remains of the free pool or utilize our policies in preference to their own or whatever.
So this is essentially a security problem, and good security poses a high barrier to unauthorized people and a very low barrier to authorize people.
It doesn't create huge bureaucratic headaches for the person who is supposed to be doing the thing, and it creates insurmountable obstacles to the person who is not supposed to be doing the thing.
And bad security is the kind that a hacker gets through easily and an authorized person has to write their password on a Post it note and type it in and it's 18 characters long and they've got to use the option key. Right? And that's the problem we're in right now.
We've got something where we've glommed on all of these procedures and it's become a huge mess and it's difficult for staff to implement, it's difficult for legal to justify, it's difficult for us to work our way through the bureaucracy, it's unpredictable, and it doesn't work.
So more of that is not going to make things better. What we need to do is step back and look at who we are, because it's we, the set of organizations, that are trying to identify itself.
Because we want to serve us to the exclusion of people who are not us. And that has nothing to do with address space. So the easy way to do this that would require global coordination, not on the part of the RIRs, but on the part of the RIR constituent, is for every constituent to say: These are the RIRs or this is the RIR that I identify with. This is the one I want to do business with and I'll follow that one's policy as long as that one's policy allows me to get my work done globally.
That's a hard solution, because it requires a lot of coordination. This is inherently a hard problem, but we need to not be looking at the addresses, we need to be looking at how to identify the organizations.
We want to be serving the organizations that are principally North American organizations, the organizations that have a significant business presence here more than they do somewhere else, the organizations that are serving customers in the US that have bank accounts in the US, that are legally and financially responsible in the US.
Because ultimately this comes down to liability. If somebody commits a crime using addresses and routing and so forth associated with an organization, do we have a handle on it? Can we go to the FBI and say -- or the RCMP, or whatever -- deal with it here, go arrest the person, go subpoena them for whatever? Or is it in the Ukraine? If it's in the Ukraine, we shouldn't have been servicing them in the first place. We should not be giving them address space. RIPE should.
Paul Andersen: I assume by the US you mean US, Canada, and parts of the Caribbean.
Last speaker, please.
Elvis Velea: Hi. Elvis Velea, v4Escrow. I've been observing mostly the policies and the discussions of the policy proposal in the ARIN region. I have not been very active.
Just to respond to something that the previous speaker said, I fear that we're moving into a direction that I'm not very sure if it's the right one, and I fear that we're actually moving into a direction where there will be competition between the five RIRs.
I'm not very sure that's the right movement. That's the first comment.
Second comment is could someone tell me how can they demonstrate where I'm using my IP address? Am I using it here because I'm connecting to my VPN back at home, or am I using it back at home because it's routed there, or am I using it on a machine that's in between because who knows who is listening to my traffic.
It's very difficult and almost impossible to actually demonstrate what will be used within and outside of this region. For this reason I'm opposed to this policy proposal. I don't think ARIN should continue to create more and more difficulties, and I actually think that we should -- we -- I actually think that ARIN -- because I'm -- still consider myself part of the RIPE community more than the ARIN community -- I think that the ARIN community should step back a bit, look at what RIPE has done and call people and listen and understand what the liberal community of RIPE is trying to do, because -- and I know this is not agreed by most of you here, but this will never fly globally.
The RIPE community has become extremely liberal, and it will never accept another policy that will just add barriers, my point of view.
Paul Andersen: Your view. Just to be clear.
Milton had some reply comments and probably some closing.
Milton Mueller: Totally confused by your statement. You gave a convincing presentation as to why you can't identify, why regionality of the address space is irrelevant, and then you said you're against this policy. You said you're against ARIN erecting new barriers. This policy is trying to reduce barriers, to become more liberal. What's your problem with the policy?
Elvis Velea: I think right now ARIN is trying to impose some numbers on how much could be used inside and how much could be used outside the region.
Milton Mueller: No, look, there it is right there in the summary. That's the nexus. You have to have that to be considered eligible. Other than that, there's no ratios. Woodcock was wrong, there's no ratios in this policy. There's just that nexus. Okay. So am I right that you actually support the policy?
Elvis Velea: Well, given that, I'll have to come back and reply by email.
Paul Andersen: Has to be a quick interjection.
Chris Tacit: So, look, the issue I have is that this nexus does not guarantee solving the problem that Bill Woodcock identified which is the material connection to the ARIN region. This nexus can be simulated or used by illegitimate parties from other regions to raid our resources.
And I don't think that's the intent. The intent is to solve a problem and facilitate legitimate business operations of ARIN members. So we need to find a way to ensure that there is some rational connection of those people to the region. I just think this isn't the way to do that.
Paul Andersen: We've kind of already hashed that. So the microphones are closed.
Milton, was there anything you wanted to ask quickly?
Milton Mueller: I would like to call for a vote.
Paul Andersen: That's where I will go if we had no other comment. I appreciate all your patience. I'll verify that my counters are -- and then just as a quick clarification, I know there's been some people suggesting some amendments. We will be voting on the text as in your Discussion Guide.
So I will ask, just like before, first those in favor of the proposal and then those against.
So I'll ask the online voting to begin, and then those in the room who are in favor of proposal 2014-1, Out of Region Use, please raise your hand high and keep it there until I ask you to lower it, please. As high as you can get it. I realize it's been a while.
Especially those in the back, keep it up until we ask you to lower it.
Thank you. You can lower.
Now I'll ask those who are opposed to the policy to raise their hands nice and high, please.
Thank you. We'll wait for the tabulation.
John, if you want to give the break info as efficiency.
John Curran: We'll be going into break in a minute. We're not delaying our return from break, which means when we go into break you will be back here -- I guess we have to delay it five minutes. You will be back here at 11:05. We'll do our transfer panel at 11:05 a.m.
You can go now, but if you want to hear the results, you need to stay.
Here come the results. It's not like Michael's between you and break.
Paul Andersen: Very quickly. Those in the room, 118. Those in favor, 17; against, 11. This will be provided to the AC for their consideration. Thank you very much.
John Curran: See you back at 11:05 promptly.
Transfer Experience Panel
John Curran: If people will come in, we'll get started. I'd like to get started with our IPv4 Transfer Experience Panel.
I have Sandra Brown from the IPv4 Market Group; Jack Hazan, Hilco Streambank -- out of order -- David Huberman from Microsoft; I have Elvis Velea from V4Escrow; and I have Marc Lindsay from Avenue4. Yes, thank you, Marc.
All these people have been involved with transfers. And since we've had a transfer policy for some time, we figured it would be good for people to have an opportunity to speak about their experiences with the transfer policy because that will help inform the community and look at our policies and see how they're doing.
Everyone has a brief introductory statement. So we're going to go through those, and then we're going to open it up for questions.
We have two microphones for questions. You should probably use two lines when we open it up. We have an hour for this panel.
Amazingly, I wasn't sure if that was enough time, but I will see how that goes.
I'd like to start it out with opening remarks. So if we can get up Sandra's slides, she's first. Sandra Brown.
Sandra Brown: Thank you and good morning. And thank you to ARIN and David Huberman for putting this forum together so that we can have a chance to talk with you.
How is that? Thank you.
As I was saying, thank you to ARIN and to David Huberman for the opportunity to speak with you this morning.
I just have a couple of slides. And I don't so much want to talk to all of my content because these are slides I've had from other engagements, but I wanted to make a few points specific to the topic at hand and then leave the slides with you so that you'll have some extra content if you want to refer to them in the future.
So, first of all, I wanted to give you some information on the purchase process. Just a couple of points I wanted to make here.
First, when buyers come to us, we encourage buyers to get free IPs from ARIN before they make a purchase.
And so if you're thinking about the process, the purchase process, the point is, do you want a three-month supply and go back to the well with ARIN every three months, or do you want a 24-month supply from the transfer market so that you don't have to keep going back to the well?
So that's the idea behind free and having to go back eight times as often or going back once every 24 months.
Second point is it's good to get help to do the ARIN justification, especially if you don't have a lot of internal expertise at the process.
If you're a big shop like Mr. Huberman's here, you'll obviously know how to do it. But if you're a smaller shop and you don't do it very often, then get some help.
And that's something we can bring to the table as a broker is to get you some help so you don't have to struggle with the many questions that ARIN asks that are very difficult to answer in some cases.
The other point to make there, of course, is that when you do apply for IPs, your existing blocks have to be 80 percent used, and that's every block. Not the aggregate of the blocks. So that's been a discussion point within ARIN for some time.
And then you have to show how the IPs are going to be used. And that can be very difficult, and that's something that specifically the assistance we give will get you through.
The next point is that -- compliments to ARIN -- the ARIN pre-approval process has gotten much more streamlined than it used to be. And it's good to get pre approved and not -- I think someone made the comment yesterday during the meeting, it's good to get pre approved and not say, I want to buy this company's /16 block, line up with the seller and then find out you're only pre approved for a /17 and find your commercial process has gone astray.
So, therefore, get pre approved. Learn what size block you're approved for, and then get lined up for your commercial process.
Okay. So those are the points I wanted to make on this slide.
And taking you to my next slide, just one point I wanted to make here, and there's some information here about what due diligence a buyer should go through.
And I want mostly for you to take this away with you, and the point I wanted to make verbally is that we recommend you check the IP for blacklisting and, secondly, for blocking. And a lot of people don't think about blocking because it's not very visible.
So what we recommend is if you're going to use the IPs for functions such as email, even internal email, then make sure that you check that you can -- by testing the IP specifically for email that you can actually email on them by pretesting.
And my last slide is on negotiation points to deal with between buyer and seller. Again, I want to leave most of these points with you.
So our experience as a broker is that we've never found auctions to be successful. So the main reason for this is that buyers don't like to compete for the same block.
So you'll find as a seller you want to list your block, you say, oh, put my block up for auction? And you can't go to a bunch of buyers. They just don't want to compete for the same block. They'll say, well, find me a different block. Because right now, to be honest, within ARIN region, there are more sellers than buyers.
Second point I'd like to make is that we recommend payment via escrow. And it's probably a little bit because IPs are a fairly new asset in terms of buy sell, and it gives the buyer some comfort that they're going to get the IPs when they pay for them, and it gives the seller some comfort that they're going to get their money without losing the asset.
Last point I wanted to make verbally is that buyers often only look at the price. So they say, ah, I'm going to get these for a certain price. Price is all that really matters to me.
But there's other factors you really gotta be conscious of. IP quality. The efficiency of the seller. Sometimes you get a seller who has really, really got a lot of corporate process, who is really, really crummy at following up and getting things through ARIN.
And you wait six weeks versus some sellers will do things in two days. You want to make sure you get an efficient seller. You want jurisdiction of the legal agreements to be right. We've never had a case go to court, touch wood, and we hope we never do.
But we hope we never do. But you want to be able to have the cord handy if you need to.
And last but not least, you want to make sure that the legal content of the agreement is good.
So those are the points I wanted to make in my opening statements. And I don't know how you want to do Q&A.
John Curran: Turn it over to David. When we get to the end, we'll do open questions for everyone.
Sandra Brown: Okay, thank you. Over to David.
David Huberman: Hi, everyone, I'm David Huberman from Microsoft. We put this panel together with John. We wanted -- we're at a point now where we've been making transfer policy here at ARIN for a few years, but the market is really established now and there's some lessons to be learned, some real lessons to be learned.
So we asked folks to participate, and Microsoft allows me to participate to share some lessons learned in hopes that it both helps you as a buyer or as a seller, or as a member of the community. When you think about transfer policy, you see some real world implications of that policy.
Some of you are my competitors. So there's a lot I can't say. But I have found some things that I can say that I think will help you as a buyer or a seller be more successful when operating in the transfer market.
The first thing is when you're a buyer and you go looking at an organization to buy their address space and you see it's not routed in the DFZ anywhere and you see it's not blocked anywhere, you might want to ask them if they're using it on the back end.
We bought an address block which everything was great. Everything was fine. We went to closing, and then it finally trickled down to the engineers who actually operate the network. They said we're using this space on the back end.
So you want to ask that question at some point during your negotiations. This is more corner case. But for the larger operators out there, when you're buying address space from a large company, make sure the seller and the seller's broker actually have the authority to sell you the address space.
There was a situation where a block was being brokered that had competing brokers and competing employees in the company trying to sell the block and lay claim over the authority. As a buyer, that represents risk to your company, to your network. That's probably somewhere you don't want to go.
So the due diligence step at the early stage of a transaction is really, really important.
Now something more practical that has to do with ARIN policy. Make sure you don't lock in accidentally your space into ARIN because of ARIN NRPM 8.4, the anti-flip language. The anti-flip language is really -- the devil are in the details there.
If you don't set it up so that you can do an 8.2 transfer to a different subsidiary on a different continent, you can -- well, pardon my language, you can screw yourself. Because you're buying space for use around the world and you're going to buy it from whoever has got the space that you want at the cheapest price.
And if that buyer is in the ARIN region but you're intending to use the space in Chilé, if you don't build in the ability to move, to buy the space as parent corporation, 8.2 transfer it to your own subsidiary corporation and then 8.4 it to Chilé, you actually get -- the stuff gets stuck for a full year in ARIN's Whois, which is contrary to everything you're trying to accomplish and why you spent a whole lot of money.
Those are some lessons I wanted to share with you. I hope you found those helpful. Thank you.
John Curran: Jack?
Jack Hazan: Thank you, David, for setting this panel up, and ARIN for allowing us to share our experiences with you.
I'm just going to give you just a little of my background, only so you could understand my perspective in establishing how we go about going to market with the address blocks that we get.
If anyone told me, I don't know, 10 years ago when I was an attorney, I was a bankruptcy attorney, that I'd be selling Internet numbers, I would -- I don't know what I'd do. But I certainly did not expect to be doing this. But really it's sort of -- after retrospect, it's actually an interesting match.
So our company, Hilco Streambank, sells and values intellectual property generally. So the IPv4 business is only one division of our company.
We look at global intellectual property. And sometimes I confuse people when I say -- we call intellectual property IP, so we'll have to say intellectual property. So we sell all trademarks, patents, copyrights, domain names and Internet numbers.
When I tell people we sell Internet numbers, it's not in this crowd, they look at me like I'm from outer space.
In any event, number one, we have a background in selling all types of intellectual property. And this is a natural fit.
I also was a bankruptcy attorney whose focus in a lot of my practice was establishing sale procedures in bankruptcy cases. So we were charged with looking at a company that had particular assets that not always were regular assets that people fully understood, not always assets that there was complete clarity over how they're owned, what sets of rights people have to them.
And we were charged with establishing sale procedures that made all the constituents in the case comfortable that their rights were protected and that made buyers comfortable that they were buying something and getting at the end of the process what they set out to buy.
And so with that lens on our practice, we saw this opportunity and went forward to try and establish a system that worked.
Our first sale took a while, a lot of head scratching in figuring it out. But through our experiences, I think we've progressed to address a lot of the concerns.
And I'll just share with you just some of the issues we've seen and how we address them. Just going a little out of order, just to Sandra's point about auctions. I don't disagree with Sandra that many people are not comfortable buying in an auction. And we understand that. Although, in bankruptcy, it's usually an auction because it needs to be a public forum.
But there also are reasons and there are people that would prefer to buy in an auction because it's clear -- it's a little bit more transparent and they know what other people are bidding.
And so we've set out to go both directions. We do many private, confidential sales and negotiated sales and go through the contract process, and some companies are particular over the terms of the contract.
But on the flip side, we saw a need for transparency in the market. And a lot of people that we went to, I'm paying X for addresses and how do I know that that's the right price? Maybe it's two times X or 10 times X or .1 of X.
And so we created an online auction platform that if you take a look at it, you'll see we actually -- you don't have to be a bidder, and anyone -- the public can go on and see how much addresses are trading for and in what regions and how many transactions we're doing.
And so the auction process has its positives, and we'll go either way depending on the needs of the parties.
Just to maybe -- sorry if I'm repetitive of some of the points that Sandra made as well, but pre-approval -- so one of the biggest hurdles that we came across in our transactions was I'm buying this but I don't know if I can get it because I have to go through ARIN approval.
So we've worked through ARIN on many transactions, and hats off to their staff. I mean, they've really progressed over the last few years to a point where I think we've dramatically improved the time that a sale takes place, and they've been pretty diligent in answering questions and clarifying things for buyers.
The pre-approval system is -- I highly advise, if you're going in for a transaction, to have pre-approval. If not, we do transactions that are subject to approval. But there's a risk of not closing a transaction because of it.
On our auction system, we openly encourage pre-approval. And, in fact, if you win in auction and don't get approved, there's a fee you have to pay. So we, through establishing that, encourage people to go ahead and get pre-approval.
Some of the other issues we dealt with, the auction platform also helps -- we saw a need -- we started doing /16 sales and higher, which the time involved in doing the transactions warranted -- the reward for it warranted the work that was put into it.
We received many requests, both from sellers and buyers, or you want to call them transferees, for sales of /24s, /20s, /22s. So we saw a need and a big marketplace out there for the smaller blocks as well.
We addressed that with the online platform as well. You don't have to negotiate a contract. You click "buy" and the terms and conditions are outlined on the site. And so everyone knows what their terms and conditions are. If they read it, if they clicked "I agree," they are what they are.
But we've enabled people to buy and sell smaller blocks. So I thought that was helpful.
And with the transparency on top of it, that created an atmosphere and a system where people can trade in these assets without -- or assets -- I don't know if that's the right word, but trade in addresses in an efficient manner that suits the amount of money they're spending on it.
John Curran: Okay. Elvis.
Elvis Valea: Hi, everyone. My name is Elvis Velea, and I am the CEO of V4Escrow. I'd like to thank ARIN, John and David, for the opportunity of being among the very cool individuals here creating policies and procedures for an IPv market to succeed.
I remember when I was seven years old, under communism regime of Ceausescu where we did not have enough to eat, we did not have enough to drink, and my parents did not have any opportunity, and I remember my father turning on the TV and watching some Serbian TV because there was nothing on Romanian TV.
And on the Serbian TV station the Berlin Wall -- well, he was looking at the Berlin Wall going down. And at that time I had no idea why they were so excited. And as I was experiencing their emotions, I saw that the communism both in Russia and Germany was collapsing as the Wall came down.
In my head I sensed that there was opportunity; that there was this feeling that I got in my body watching my parents celebrating the Wall going down and the Romania Revolution going on at the same time.
I had a feeling for the first time I was going to be okay. I was going to be here, and I was going to have opportunity, too.
This is what I do every day as a business. I feel that same excitement I felt as a kid when the Berlin was going down or when the revolution started in Romania.
There was a long break until I had the feeling again. I went to school. I started working in Internet cafes and call centers before I became a network administrator and technical expert. I felt the same shivers when between 2000 and 2007 I was part of the development of the Internet in Romania.
I then went to work for Regional Internet Registry, the RIPE NCC. And as I was working for the RIPE NCC, there was this new revolution that I -- revolution that I sensed coming. And I'm so excited to be part of it as I felt what was going to happen, and I started to get that one feeling one more time.
As I see this market transition from something that used to be a number to something that runs the world, I feel so privileged to be a part of this process.
I come from a technical background. And I started V4Escrow when I realized that once IP addresses are going to run out, the RIR world we live in is going to change from a quasi regulatory, five body institution to free market. I started studying a lot about the free market and learned how things are going.
I started learning about the efficiency in enabling this free market, and I started to get the technical skill set and appreciation for what this industry would need to do to get to that place. And I'm excited to be part of the time when this is actually happening.
In 2014, the market has transparently moved more than a /8, and V4Escrow has been a significant part of that market. This transparent transfers do not include future contracts or legacy transfers. At NANOG 14, in March 2014, I predicted that the whole /8 would be transferred within the year, and that prediction was spot on. At NANOG 15, just two weeks ago, I predicted that three to four /8s would be transferred in 2015.
Most people predict things because it flatters their ego and it highlights their expertise. I predict things because I love my job and I love this market.
And the reason why I was able to predict things so accurately is because I'm involved in it every day, and I take it to such a level of detail that it's exciting for me to know where it's going. And I feel my predictions and my numbers drive the spirit of this market.
I am proud to have been selected as the expert broker, executed in several of the largest transfers in the RIPE region. V4Escrow has brokered over 2.5 million IP addresses in 2014.
I'm here right now to announce that in 2015 V4Escrow will become one of the most important IPv4 brokers in the ARIN region as well.
While these IP addresses comes from saturated markets, there are countries in the world, especially in Asia and the Middle East, that have been late in joining the Internet table.
These countries now need our help to reach the same adoption of the Internet as the Western countries have.
While these IP addresses come from saturated markets, there are still leftovers from the industry that does not need them.
The industry in the Western countries has reached a level where they have enough IPs. The free market is based on the inventory moved from a market that does not need it to a market that badly needs the IPs.
Hence, the market moves things to the best use of the resources. When was the last time that you saw an article about IP addresses in Washington Post or Computer World? Just last week I was interviewed and featured in both.
We are part of something big right now. The market of IP addresses runs the world. I mean, why is Google here? Why are AOL, Apple, Twitter, Akamai, or Microsoft here? Why are 6connect, Comcast, Cox, Time Warner, Verizon, NTT, et cetera, et cetera, attending this meeting? Because these are the most important decisions that we can make. Today. Today matters the most.
If you guys have any questions about transfers and about how I predict both the size and the pricing in this market, please come up to the microphone or see me on the break and talk to me.
I'm proud to be the CEO of V4Escrow and to be able to be part of the market of IPs and the way the Internet works. Thank you very much.
John Curran: Thank you, Elvis. And, Marc, go ahead.
Marc Lindsey: Yes, I'm Marc Lindsey, and I'm president of Avenue4. Avenue4 spun off from a law firm. I'm a lawyer by training. And we got into this space several years ago, mostly advising large companies in connection with the underpinnings of the market as it was emerging, understanding what they had and how they deployed it. And increasingly those early large sellers typically turned to us to kind of complete the full cycle of transactions.
So that's sort of my perspective. It's good to share sort of perspectives. We simply almost exclusively represent large sellers in that space. And based on that experience there are a few things I wanted to share with you with respect to the insights that we have in the market.
One is that the market is inefficient. What Hilco is doing is a good attempt to bring transparency and efficiency into the market, but there's still some difficulty in getting kind of a trusted platform where you can completely go through and having buyers and sellers meet.
So still right now the fundamental way of big transactions get done -- and we mostly do larger transactions -- but big transactions get done is you find a buyer and a seller, and you match them. It's not particularly efficient. There's no real clear price transparency.
Now Hilco has some numbers on their auction platform. But transactions, a lot of transactions don't happen in a public way.
Intermediaries here at the table, we probably know pretty close to any particular time, given size, what the price might be. But you as buyers and sellers don't really have an independent way to verify whether what you're buying at a particular price point is the accurate price. Now, at some point in time the market will move to more efficient means to make that happen.
We want to be a participant in that. But right now that price transparency doesn't really exist. There are some points I want to talk about what ARIN can do to help on that, not on price, but transparency.
There's also the Ts and Cs. Again, because we're lawyers, our advisory firm, Avenue4, does the full soup to nuts. We'll bring in a seller, we'll do the due diligence on their numbers, we'll then match them with a buyer. We'll structure the transaction, help them go to closing. And, to the extent they need it, we'll facilitate the transfer and work with them for any post closing, post transfer conditions.
But negotiating those terms and conditions is still a battleground, right? There are certain norms that are evolving, and I'll talk about those norms in one second.
The principal vehicle today used to convey IPv4 assets in the secondary market is through an asset purchase agreement. People are treating it like an asset. They're treating it like property. No matter what anybody else in the community believes, that's the way these transactions are happening.
Now, the challenge is because there's a set of uncertainties at law, as to whether there was really title in that fashion, there's this delicate dance that buyers and sellers go through to say: What am I conveying? What am I getting? So there's a little bit of discomfort for buyers and sellers in that space.
We spent a fair amount of time in our transactions navigating that risk, making sure that buyers can have some meaningful thing that they walk away with, and sellers aren't exposing themselves to potential secondary remedies in the event that there's some outcome, some output of a legal decision that might not be favorable for how norms are evolving.
But for all intents and purposes, most transactions treat v4 numbers like an intangible asset. There are different transaction structures that a lot of clients are involved in. Most of them are one and done closings. There are a fair number of options and forwards being done at the larger sizes.
So you all talk about sort of restrictive policies on transfers, and one of the points I want to make is that restrictive transfer policies have their place of doing certain things, but fundamentally people are being engaged, like me and others. We like it. It's good. It's creative to find ways to work around those policies, to achieve business objectives of the buyers and sellers at issue.
Now, not violating policy as such, but working around it. So no matter how many policy changes you make, there are creative folks around to find a way to get done what they want to get done.
The point I want to make if ARIN, going forward, the best thing for post exhaustion is to reduce the barriers for participants to use the process in the open, right? The higher the barriers you put up, the more workarounds people will engage in to make it less transparent and less effective for those who are following the rules.
So I mentioned asset purchase agreements, transfers, forwards and options, all are fundamentally part of what's happening. Some bigger transactions also happen on a barter basis. There may be some portion of the value that's exchanged other than for cash, but those are usually close relationships.
A lot of our transactions are very specific and we don't have a particular form, but more times than not there are some common elements that go forward.
I want to talk a little bit about what ARIN has done, what it can do. I think ARIN has done a very good job in the last 12 to 24 months moving towards liberalizing the market, and it's making it more efficient to people to participate.
It's still inefficient, but they're getting very far. The pre-approval process is incredibly helpful. The ARIN Online transfer process is incredibly helpful. It used to be the email templates, which were not particularly efficient.
The turnaround time for transfer requests at ARIN have been excellent. The staff has been very good at getting that back, getting people informed as to what they need to do and guiding them through the process of what needs to be done to get a transfer approved.
I do say that the ARIN Online process can be improved a bit because a lot of us who are in this space have a lot of experience doing it, and the sellers and the buyers in this space may or may not have experience. David and others here have experience.
But it would be helpful if ARIN Online would allow for limited delegate authority for certain intermediaries to help perfect transfers. Right now you can do it on a block wide basis.
So if I've got a client who has /8, they've got to give me administrative authority for the entire /8 to help achieve a /16 transfer. So to be able to reduce that delegate authority would be very helpful.
I would also say that the other point I want to make is that liberalizing the transfer process itself. I want to go right at this. I know I have a bias, but I do think eliminating needs justification in the post exhaustion world is the appropriate mechanism to use.
It does not meaningfully inhibit large buyers' desire to get what they want. It merely sets up a roadblock or a little bit of a speed bump for certain transactions.
So what really ends up happening is people are using forwards and options to do other things to achieve their outcome. But if you eliminate needs justification, there would be no reason to do so. They can immediately have those transactions reflected in the registry, which is desirable to everyone.
So minimizing the needs justification as a hurdle to getting full transparency on all the transfers in my view is a definitive move in the direction where this community ought to be going post exhaustion.
I also think that there's another bit of transparency that ARIN could help with. Right now you do -- ARIN does identify in the -- online or on your website blocks that have been transferred. But you don't identify the source, who the recipient is, the date it was transferred.
That would be very helpful just understanding and analyzing the market in a better way. That seems like a software fix. It could be done. I'm not sure how, what the next step for doing that is, but I think RIPE and APNIC do a very good job in making that information readily available which facilitates analysis for market participants to see the size of the market and to see what's happening.
Those are the things I think ought to help progress the market to a more liberal, transparent and open process.
And, again, I do think that I really will emphasize this point -- I've been inside this market participating in many angles for a long while, lawyer to sellers, now as an advisor to brokerage work -- that the needs justification and any meaningfully high barrier in the contracts ought to be reduced so that people don't find ways to cheat.
I'll open the microphones for questions.
Couple of things. If you have a question for a particular person, say it when you're asking the question. Otherwise, I'll see who wants to respond and I'll get them to. I'll choose someone.
We're going to go probably to 11:05 with Q&A, and then I'll give everyone a one minute closing statement. I'm sorry, 12:05. I'm living in the future, I guess. So we have approximately 15, 20 minutes for Q&A.
I see Lee. Go ahead, open it up.
Lee Howard: Lee Howard. Thank you for being here. I always love this topic. Very interesting to me. Marc, in particular, you had mentioned pricing transparency, I believe, and I think Elvis said something about it, too.
I know that Jack and Sandra publish on their websites prices of some recent transactions. I don't think that you all do on yours.
Would you? That would help us see what pricing is looking like.
Marc Lindsey: That's a very good point. Again, we come at it from a perspective advising sellers, so most of our sellers and most of our buyers at the moment don't want that disclosed.
A lot of them don't want the full value, the full size of their transaction even disclosed. If I said to you, for example, there's a transfer of a /16 that might be a bigger deal, and you saw a price point for that, you're still not going to have complete information because that's going to be inappropriate price and size match.
But your point is a good one. My clients at the moment and the buyers that work with them don't want that information disclosed.
John Curran: Would anyone like to follow up on Lee's question regarding publishing pricing?
Elvis Valea: I think you were also asking me, right?
Lee Howard: Yeah.
Elvis Valea: We, just as Marc here -- we also have NDAs with most of our customers. And because of those NDAs we cannot publicly disclose the prices for one transaction.
However, what I can do say is that we have had in 2014 transfers for prices anywhere between 7, 7.5 to $16 per IP address.
Now, larger blocks have been transactioned to somewhat smaller prices. Smaller blocks have been transactioned to somewhat higher prices.
Second thing that I want to mention is that we also notice a different trend in 2015. So this was 2014. In 2015 we actually see the sellers are trying to put a minimum cap, which is somewhere around 10 to $12 per IP address.
And that is right now the minimum. It used to be maybe 7, 8, last year. Now it's somewhere around 10 to 12. That is what I can disclose.
John Curran: Any follow up, Lee?
Lee Howard: I do have a follow up. Thank you. My other question is I estimated at some point that there were probably a billion addresses, IPv4 addresses, that were not actually being used by anything. That's where I sort of eyeballed the easy part of the market.
Since I can't see how much address space has been traded but not registered in the Whois database, and I can't see what's locked up in futures and option contracts, can you all give us a sense for how large the remaining market is or at least for any appreciable size of prefix?
If there are 600 million addresses locked up in /24s, that's not necessarily a fantastic market for many of us, but how is the market doing and how much of it is left.
John Curran: Does anyone want to comment on future options, lockups or transfers that haven't for some reason made it into Whois?
Sandra Brown: I have a comment. So I think it's a great question, Lee. And my view on that is your number is probably accurate, but I think the number of free addresses will be a function of price.
So what you're seeing in the market right now is that several /8s in North America have freed up, and Marc as well as anyone knows which /8s are available since he represents a couple of them.
And I think what we're seeing happening is that a couple have come to market with partial /8s and they are saying, okay, we're done for now. We've freed up as much as we're going to.
And it's not until the price increases, to quote Elvis's prices, like you can see larger blocks going right now for around the 5 to $7 point per IP. It's not until you start to see those prices start to exceed $10 that you'll see supply start to increase.
So perhaps the current quantity available is between half a million and 1 million IPs. When price gets above $10 for the larger blocks, I believe it will increase over the 1 billion mark.
Marc Lindsey: Quick point there, to your point, Lee. I'd say that right now, right on what Sandra is saying, we've got a lot of large block holders, and I'll give you a ballpark figure.
We have -- just within our space of Avenue4, we've transacted in a total, it's probably equivalent of a .9 /8. Now, the remainder of what is left from some of those big sellers, they are really waiting for a more efficient market, a defined price, to then go and invest to free those remaining numbers up.
So I think there's a good portion of numbers that could be deployed, but it's sitting on the sidelines because now it's really harder to get to.
And until there's a better way to clear at a certain price defined and prices are a little better, they won't invest an extra bit to free up the remaining half, two thirds, three quarters of what they have in inventory.
Jack Hazan: Real quick. I think post exhaustion you'll see a big difference. It's tough to really have a market where people can get addresses for free, and people have to pay for addresses. So I don't know that I'm smart enough to tell you how many are out there, but I think you'll see things open up post exhaustion.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. Once again, speaking only for myself. I'm a little concerned about the smaller blocks going for larger dollar values. When we were discussing this in the Advisory Council before we had an 8.3, we had an economist advising us from Harvard who was telling us that what would actually result would be this convex pricing model where the fact that larger blocks would fetch higher value per IP would help preserve aggregation.
And what I'm hearing is that the economic incentives are now saying deaggregate your /8 into /24s and you can get more money per address. So that concerns me.
John Curran: Is there a question coming?
Owen DeLong: No. That was a comment. Question. David gave the example of having his address space locked up so that he couldn't transfer it to Chilé under 8.4. But, to the best of my knowledge, LACNIC does not yet have a compatible transfer policy that would allow him to transfer it to Chilé anyway. How was that relevant?
John Curran: Question to David about his Chilé. David?
David Huberman: It was a hypothetical because it is relevant in APNIC and RIPE.
Owen DeLong: Okay.
John Curran: We've got lots of people. Questions. One more quick one.
Owen DeLong: Final question. I'm hearing lots of -- we keep hearing this mantra of having rules causes people to cheat in order to circumvent the rules, we should just get rid of the rules. I will once again reiterate that eliminating the rules does not make society better, just because it makes it more convenient for people to make money.
John Curran: Okay. Front microphone, go ahead.
Milton Mueller: Two questions -- Milton Muller, Syracuse University. I missed the first, and I don't know if anybody addressed the question of leasing. Is this an example of what Marc was talking about, where if you create barriers, people find workarounds? And how much of that is going on? Are you guys part of that market?
The other question is we passed --
John Curran: One question. So leasing.
Marc Lindsey: I'll say there are transactions where people are finding ways to convey beneficial use without going through the full transfer process. At Avenue4, we don't really get involved in leasing as such. We get a lot of propositions for it, a lot of buyers, potential tenants coming to us with that potential proposition and they are finding ways to get it done.
To Owen's point, I'm not saying eliminating the rules. You reduce the barriers that are causing people to otherwise cheat to make it easier for them to comply with the rules that are important to you. That's the point.
John Curran: Anyone else want to respond to leasing?
Elvis Valea: I would like to say a couple of words as well. We do also see a lot of companies coming to us trying to lease addresses. We don't get involved into leasing just because leasing can be done directly.
When you swipe an IP address, when you make an assignment, you're basically leasing that block to your customer for a period of time depending on the contract.
So leasing can be done directly. It doesn't have to be done through a broker. And leasing basically means giving a block to a customer for a period of time.
Sandra Brown: Because this is the tips and tricks sort of conversation, we -- based on four years in this market, when we first got into the market, we did some leasing, and we soon learned that most of the parties looking to lease blocks were looking to email on them.
So we quickly stopped doing that because we learned very quickly that they were going to blacklist and block your IPs.
So if you are a seller, I would recommend very strongly that you not lease your IPs. It's not a good thing to do, and we are no longer in the leasing business because of that.
We would, however, do some of the work that Marc alluded to, which is if you have a block and you want to put an option on your block or you want to allow someone to use your block with a lease back kind of arrangement, paid up front, we do that kind of thing, yes.
John Curran: Thank you, Milton. One question. Congratulations. Back microphone. You can get in line again. I just want to keep it moving quick.
Kevin Blumberg: Kevin Blumberg, The Wire. So we still have smaller blocks in this particular region. And I think you could say in other regions as well with their end of days policies, smaller providers can still get space.
My concern is that there's going to be a minimum floor that is going to be prohibitive to the smaller transfers.
What I mean by the minimum floor is when you take into account your cut, the legal cut, the transfer cut and everything else, the actual cost of the block on a /24 or /23 is very small.
What can we do to improve that? I.e., I expect legally right now the documents are a massive cost. Is there a way of completely getting that down and getting the minimum floor down moving forward?
John Curran: Question for the panel on a lower floor, how do we do it?
Jack Hazan: We've attempted to at least improve that by taking away all the legal costs through the online platform. Frankly, we don't make much -- we probably lose money when we sell a /24 at this point. However, we've taken down a lot of those barriers over there, and at some point the market is going to be the market.
And if it's too expensive, I'm not sure how we could address it. But we're trying to make the transaction process smoother so that people can get through it reasonably.
And we are selling /24s. So right now people are paying more per address for a /24 than for larger blocks and they're closing the transactions and they're going through ARIN.
Elvis Valea: I think I do have a suggestion for that. Let's remove needs based for smaller blocks. Let's see how that works. Let's make the process so simple and automated that it doesn't really involve lots of hoops, lots of barriers, lots of costs.
Kevin Blumberg: Quick question, follow up to Jack. Is your current point and click transactional scenario compatible with the 35 countries that ARIN is a part of? I think it's 35.
John Curran: 28 economies.
Kevin Blumberg: As a Canadian organization, would that point and click legal whatever be compatible for a Canadian company?
Jack Hazan: That's an interesting question. I don't know if we have choice of law provisions in there, for example. So if there is, it's probably one.
But we have sold blocks in Asia off of that site, and it's the same site. So it's compatible -- I imagine that as we grow it and as we have more participants in foreign countries, we'll do more to accommodate them, translation, et cetera, as well.
Kevin Blumberg: Thank you.
John Curran: Rear microphone.
Martin Hannigan: Martin Hannigan from Akamai. Serious market observer, I have just a few points based on the conversation that we've had already. Very quickly with regards to price points, I guess we'll have the IP number ice bucket challenge. I disagree with you.
My data points, my own data points are $1 an address at this point because there are much more sellers than buyers in the market.
Second question is -- and I think that if only one person can answer this, probably would apply to all -- how much exclusivity do you guys have on address blocks? I get the feeling there's pretty much none at this point and that it's a free for all.
And third question, if each person can answer this just with a number, how many RFPs have you each seen?
John Curran: For exclusivity, just to know, are you the sole representative of the party selling?
Martin Hannigan: You have a contractional relationship with the block seller that you and only you are representing the seller.
John Curran: Okay, are you exclusive, and then how many RFPs do you get?
Elvis Valea: I would say we're about 20/80 -- 20 exclusive, 80 not.
Sandra Brown: I'd say we're the opposite of that. We're probably 90/10 -- 90 exclusive, 10 not. RFPs, how many have we seen, probably 10.
John Curran: Jack?
Jack Hazan: I've probably seen the same RFPs as Sandra. So, yeah, and almost --
Sandra Brown: But we won them all.
Elvis Valea: We've all seen them.
Jack Hazan: We're almost always exclusive, also.
John Curran: Marc, do you have a comment?
Marc Lindsey: I would say more times than not we are the exclusive advisor for our particular sellers. Some sellers still freelance. It creates problems all the way across the board, and we're trying to create some order and discipline.
There's not much order and discipline in the market at the moment with respect to the intermediary sets of services and how sellers and buyers go about using us and who in fact an intermediary is representing, are they representing the seller or the buyer.
So there needs to be a little bit more order and discipline there. It is kind of -- all participants can do things that are not necessarily efficient for all involved, but it is best if you're a seller or a buyer to pick your intermediary and not shop it. Pick the right one because you create a false impression in terms of what is actually available. And it doesn't help; it hurts everyone.
And you had a second question. What was your second question about?
John Curran: Number of RFPs do you see.
Marc Lindsey: We've seen I'd say smaller percentage of RFPs. We tend to try to do matching of larger transactions, so we've seen maybe three RFPs at most. We've had a lot of competitive processes that has been short cycled.
But formal RFPs, in terms of a written document that says what do you have, we have not seen very many. But then we tend to operate at much larger transactions, matching larger buyers and sellers.
John Curran: One follow up for the panel. As brokers, do you folks occasionally find yourself on both the buyer and the seller's side?
Marc Lindsey: We don't. We only represent. We disclose and we only represent one side of the transaction, and that's sellers.
Sandra Brown: I would agree, yeah. You can't eat both ends of the hot dog.
Jack Hazan: I would agree. We do represent buyers from time to time. But if we represent the buyer, we represent the buyer.
Elvis Valea: Same.
John Curran: Same? Okay, thank you.
Marc Lindsey: It's a good lesson to learn. I will say this: When you're engaging a broker, an intermediary with either a buyer or seller, make sure that there's full disclosure in how the money is flowing, because sometimes it's not there.
So make sure you have full disclosure on how all the money is -- the price that you are as a buyer paying and the price that the seller is getting, ought to be some clear knowledge on those two sides of the equation.
John Curran: Rear microphone, question?
Lee Howard: David, you get a question. You had said that given the example of transaction where there are two individuals from an organization, both representing that they were the authorized seller of that address block, how did you resolve the dispute?
And then follow up question for the entire panel. There's a lot of address space where the authorized holder is no longer in existence or defunct or unreachable or whatnot, and do you have recommendations for how we can go -- what we, ARIN, can do to make that address space available to the market?
John Curran: David first.
David Huberman: I'm not going to answer your question directly; I'll answer it indirectly. Do nothing until there's resolution. Do not sign a contract, possibly don't even negotiate until it is very clear who has the authority in the organization, as given by the officers of the organization, who has the authority, and then proceed.
Lee Howard: You make it their problem to figure out.
David Huberman: It's definitely their problem. There are so many sellers in the market you don't have to deal with it. Don't take that risk.
John Curran: Now the panel on: Are you dealing with someone who actually is the right party for the address block, how do you know when you're selling?
Elvis Valea: You must have a power of attorney, a proof of that the person you're talking to has the legal authority to actually represent that company.
John Curran: I guess to go to Lee's question, even if you know you're dealing with the person whose name matches, how do you know they're the party that actually is the legal successor of the block being sold?
Lee Howard: And what do we do about the space where we can't tell by that chain?
Sandra Brown: You know who is the best at determining that? ARIN. And ultimately there have been a couple of cases where we've ended up working with ARIN, because if ARIN agrees, then we know we have a transfer that's going to happen and it's going to transfer the rights, title and interest.
But early in the process, when they come to you and say we want to sell -- and we're getting better at this as time goes on, because you learn to recognize the red flags.
There are things like we had -- this is a RIPE example, but we had an example in RIPE region where it was an employee who was on the RIPE database and he was trying to transfer the IPs, and he owned the bank account, and he also was signing the APA.
In this situation, red flags were going up everywhere. So we asked him for an affidavit from the officers of the company. And he couldn't produce it.
So, I mean, there are just certain things you look for where if it doesn't smell right, don't do it.
John Curran: I am closing the microphone queues. So if you have a question get up there quickly.
Marc Lindsey: Before we take in a seller, we have a pretty thorough due diligence process. We use that primarily as a vehicle to say, well, we have to get the marketability of your address space clear so we know how to go off and actually market it.
But really a good function of that is to kind of dig into and find out where there's some chain of title problems.
And we typically will look at emanate documents, we'll look at asset sale documents to try to figure out if there's a clean chain from who is presenting themselves as the representative seller, if it doesn't match the registration record.
And if it doesn't work out for us, if we're not fairly comfortable that we can present a transaction to a buyer and then present a transaction to ARIN that will close, we don't represent them.
We'll tell them -- we may give them some direction: Here's how you need to go get this fixed. And you can know some good people to hire to help get that fixed, but there is a lot of sort of reclaiming through not necessarily above Board means to get value out of IP address space that is laying fallow to defunct companies. It does happen a lot. I get a lot of potential sellers coming to me. We've turned away quite a few.
John Curran: Elvis, did you want to comment?
Elvis Valea: Let Jack comment first.
Jack Hazan: We do the same diligence, but my advice to you, if you're taking a transfer, is you should also do your homework and make sure your team checks it out as well.
And we extensively, before we take anything on, make sure that at least to our satisfaction they have rights to the addresses, but you should do your homework as well.
John Curran: I've closed the queues. Go ahead, Elvis.
Elvis Valea: I see two sides to this answer. The first one is when IP addresses have been allocated by ARIN or the RIR, then the legitimacy of the company claiming to want to transfer the IP addresses is kind of by default given by ARIN or by the RIR. When we're talking about legacy space, then indeed there's another story.
We've also seen, what Sandra said, a couple of employees of large companies in the RIPE region trying to basically transfer the IP addresses. They had all the authority to do so with the RIR. They had the authority from the company, but they did not actually have the...
John Curran: Corporate authority.
Elvis Valea: Corporate authority. So we do see those attempts as well. It's just once you see one of those, you just walk away and just tell that guy to bring the corporate authority and then you can start talking to him.
John Curran: Final few questions. Milton.
Milton Mueller: In the RIPE region you saw no market at all until runout. In the APNIC region you saw the free pool drained and then the market start.
In North America, it's strangely different. We had a fairly robust market developing over the last two, three years, and you still have a free pool. I wonder how you all explain that, and what implications you think it has for ARIN policy makers.
John Curran: Anyone want to comment on the panel?
Elvis Valea: I would think America basically is a country where you have so many types of contracts. Futures I've just heard of the past few days. We haven't actually done or heard of futures contracts in the RIPE region. That may be because in the RIPE region the transfer policy is so simple that you can actually transfer immediately all you need so you don't have to work on a few years' installments.
But I think the transfer policy in ARIN is working just because going to the transfer market is easier than going to ARIN. Going to ARIN you have to go every three months. Going to the transfer market you'll do it once every year or once every two years.
Marc Lindsey: I think it's also partly just price, right? Right now, in the ARIN region, because the free supply is still available, the per IP address price is slow. So a lot of savvy buyers are looking at this as an opportunity to pick up addresses when the market prices are low.
Once there's runout presumptively and then there's sort of joining, linking of multiple markets, there ought to be some upward pressure on prices in the ARIN region.
So I think a lot of the activity right now is partly due to the fact you can get 24 months instead of three, but most of it is driven by the fact there's a perception there's a good deal to be had at the moment.
John Curran: Excellent. Center rear microphone.
Ken West: Ken West, Sprint. There's been a lot of talk about price transparency and not so much talk about time. And I would just like to add that knowing how long these transfers take, and I realize it's highly variable, would also help for internal planning and forecasting.
Is there any comment, like I understand it's highly variable, but --
John Curran: Let me ask a question of the panel and generalize this. ARIN right now, we don't -- we report on transfers -- and, by the way, we do the minimal reporting on transfers.
You actually have to go to the log to find what Marc wants. Who it went to, who it came from. All we do is put an address block up there. We could do more complete, we could do that for you, as others people do.
But my question is what about the data that no one has? How long did it take? What was the price involved? Should we be asking that of transfer parties voluntarily? Should it be required by policy?
Do you want some real transparency here from the RIRs? Comments.
David Huberman: I represent a buyer. I have transactions in both the small end of the market and the large end -- the small end for one offs and their own AS's and the large end for the main network.
Never had a transaction take more than two months, two and a half months. The longest transaction was because the seller was represented by very capable counsel and I brought to the table capable counsel. Which was good, which was good for both parties. That took longer.
I've completed a transaction in five days of a /8. Five days.
To John's question, IP addresses are an asset. I think you've heard that from everyone on this stage from the people actually performing in the market today.
John Curran: ARIN agrees they're an asset.
David Huberman: It is an asset. When I buy service from HP, I'm not telling Dell what I paid to HP because I'm trying to screw Dell out of smaller prices. So, that's not going to work. ARIN can't
John Curran: Is that corporate policy?
David Huberman: ARIN can't ask and buyers and sellers aren't going to tell because in a post exhaustion world, it's dog eat dog. I'm sorry, it's a market and it's subject to the market.
John Curran: Do any of the brokers want to respond?
Jack Hazan: I don't disagree. Although our auction platform gives you at least some sampling you can look at. We can't force companies to disclose what they don't want to disclose with something like this. It's not like, I guess, transactions that are subject to taxes and the like that need that otherwise.
John Curran: Can you comment briefly on the range of time? That's what the question was, what transactions you've had on your platform?
Jack Hazan: Again, have your ducks in a row. We've closed transactions in a week, and we've had a transaction that's taken a year. And maybe it was because it was a court proceeding behind it as well and some other situations.
And then also just because maybe the buyer doesn't have his ducks in a row and didn't get pre-approval and obviously was not ready to go through the approval process in the right way.
John Curran: Sandra, transaction times and more transparency in reporting?
Sandra Brown: So, transaction times, I concur with what we've heard. They can be a week, they can be two months, they can be six months. More transparency, I think the issue is always with how much, as David said, how much the buyer and seller want to disclose.
As a broker, I don't think we particularly have any impediments to wanting to disclose more, but it always comes down to what the client wants, and they never want more disclosure. So what we like to do is to anonymously, if I can use that word, give as much information as we can without violating our NDAs, and that's what we try to do.
John Curran: Marc or Elvis, either of you want to comment?
Marc Lindsey: I absolutely do not want ARIN asking price. To be direct, right, it is to our advantage not to have that price transparency out there. But it is also not necessarily good, efficient behavior for market activity.
I do think at some point in time it will be less of a market where people are gaining price as a vehicle to get advantage and there will be a spot price, but you can go and buy it.
I do think we'll get there at some point in time. If policy liberalizes us to allow it to minimize the transactional frictions and reduce the transactional load, you can kind of get to that more quickly.
But really is not -- it's not to our advantage to have that pricing transparency. Most of our clients don't want it. But I do think it ought to happen eventually just to make this in a more efficient and fluid way.
Elvis Valea: I've actually done a transaction in 24 hours. That was the shortest one. I called the customer, the buyer really needed it immediately. I called them. I discussed with them over the phone and over Skype the transaction details. I explained the process. I explained the whole thing, the contract, and they signed it in 24 hours. We sent it to the RIR. It took another 24 hours for it to be completed.
So it can be very short. On the other hand, we've done transactions that have lasted eight months.
And basically what happens in those cases is that you're talking to a large corporation. You're going to a department from the large corporation and you're discussing the contract, the legal aspects of the contract.
And then you're moving towards accounting, and then you're moving towards purchasing, and then you realize that at some point it goes back to legal, saying, oh, wait a second, we actually don't want you to be the escrow agent. We'd like a bank to be the escrow agent.
So then you start again the whole process of re discussing the whole contract, of redoing, of getting a bank to -- of discussing the escrow agreement with a bank which is not very flexible and, et cetera, et cetera. So then those things can take a long time.
John Curran: In terms of transparency, are you for transparency?
Elvis Valea: As everyone has said, it's very difficult when the buyers or the sellers require an NDA. Once that's signed, you can't actually say this has been sold for that to this party.
However, we could -- and I will do my best so that we can actually run some aggregate statistics on our website saying average price noticed.
John Curran: I think that would be helpful as people indicated.
Final question, David Farmer.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I want to reask a question that Lee asked that didn't get an answer. He asked is there any suggestions on how we deal with the assets out there that have nobody to speak for them.
In other words, there's no valid entity out there any longer. How are we going to deal with that? That's a policy issue that we have to deal with.
There's stuff out there that can't under current practices be transferred.
John Curran: Let me ask because there's actually two categories. There's one where an organization disappeared five years ago but if someone pulls the threads, they'll find the bankruptcy, the remnant sale, the asset purchase agreement to the other company.
So there's a legal thread that someone can actually prove eventually and then there's the one where there is no such trail. Are you asking about the latter?
David Farmer: I think I'm asking about the latter for the most part.
John Curran: For completely potentially abandoned resources.
Panelists, completely abandoned resources. Thoughts?
David Huberman: That's not a question for us as a panel, in my opinion. That's a very important question that I think is becoming more and more germane for our community.
I think for years we have been -- not afraid, but we've been unwilling to go there because the cost to ARIN is tremendous to make due diligence, to make sure these really are dead, these really are zombies, and the results are not worth it.
It's a small amount of space. I think we used to bandy about it was three months' worth of space that we thought was abandoned out there.
Now, is it worth it? I don't know. We need to discuss that as a community.
John Curran: Okay. I will note, by the way, that there are people doing the service of cleaning up those address blocks. As they attempt to assert they're the successor, attempt to transfer them, and then they get disproven and then ARIN looks at them says, well, all the work was done to show you weren't. Thank you. That does show up in the free pool now and then.
David Huberman: It would be nice if there was a legitimate way to do that.
John Curran: So we had a good panel. I'll let each panelist give 30 second closing remarks, and then we'll get you folks off to lunch.
Sandra Brown: Thank you very much for the opportunity to participate this morning, and enjoy your lunch.
David Huberman: It's an immature market. There are way more sellers today than there are buyers. So prices are artificially constrained, which is great for buyers and bad for sellers, but whatever. But things are going to change. We're just sharing with you where it's at today.
Jack Hazan: You guys are here making policy, and hats off to the process. It's been fascinating to watch. I've made a conscious effort not to put my opinion on policy out into the public because it's clearly obviously slanted, but a lot of the considerations that we put in to whether a clear market is a free market is better for everyone, you've got to balance that with the other needs of the community as well.
Make sure you think of everything when you're making all those decisions.
Elvis Valea: So I'm an ex-RIR employee. And the thing that I'm noticing these days is the things that frightens me the most, and that is RIR competition.
I don't think we want to get to a point where RIRs compete with each other. That's one thing.
The second thing is inter RIR transfers will happen. RIPE has a policy proposal -- sorry, a policy that has been approved -- policy proposal that has been approved, which will be implemented within the next three to four months, I think just August they were saying something, and transfers from and to ARIN will happen. I think more from ARIN, but transfers will happen because the policy proposal is compatible.
We've discussed about the prices, and I said I've seen prices going somewhere around 10 to $12. Of course, my experience is in the RIPE region. We don't actually have much experience in the ARIN region.
And what I think will happen is once the ARIN pool will deplete -- because it will deplete before August, I think -- and once the inter RIR transfer policy will become -- will be implemented, so it will be functional, we will see an increase of prices from -- in the ARIN region from the $5 per IP that everyone is seeing to somewhere close to the $10 per IP that we see in RIPE.
We have done a lot of co brokerage deals. We've done with these co brokers here, we're friends. So don't look at us as very competitive. We of course do like to be competitive, but we're all friends here as well.
I think the last thing I should mention, I do believe we should in ARIN try to remove the barriers. Okay. Let's not do it as RIPE did, take everything away. Let's try doing it step by step.
There was a discussion about the size. Well, a /24 will not make any difference. A /20 might. Removing needs based for a /20 might actually make a difference. And going up to a /16 is what I think we should do, actually.
Marc Lindsey: As a trained lawyer, I will never shy from giving my opinion, even if not asked. If you have a question, you want me to give my opinion, I'd be happy to give it to you.
I will start out by saying that I do think eliminating needs justification will solve a lot of particular problems. It will reduce, in my view, what seems to be a motivation by a lot of participants in the market to find ways not to have the registry accurately reflect who was currently using those IP addresses and who controls them.
So I think eliminating that is probably going to be the biggest thing to make this market mature more effectively for those who want to participate properly.
And then focus the policy on authenticating the participants and not second guessing the transaction sizes that they're engaging in.
Internally, companies who are buyers I found the biggest baffle, biggest limiting factor is justifying forward looking projections on their needs and then get funding internally to fund that justification.
That is a definitive limiting factor, capital. Right? Capital and engineering, expertise and forecast. Let those companies make those choices independently and focus on authenticating those participants and in chasing out the edge cases when you need to at an appropriate time.
And with that, I want to say thank you, David and John.
John Curran: Thank you. Thank you all the panelists, and David for his idea of this panel.
Thank you, everyone.
Okay. Quick closing announcements. Not closing announcements. Wow. That was quick. Real quick break announcements.
We have AC lunch tables out there. When you go out, if you find a topic you want to talk about, find the appropriate table.
Remember, we're on the social networking. Take pictures, post them. There's an ARIN hashtag. And please take your valuables with you.
We are going to resume at 1:30. We let them go late, but we're not changing lunch. 1:30, back in here. Thank you, everyone.
Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers
John Curran: Welcome back. I'm John Curran, CEO of ARIN. We're at ARIN 35 in San Francisco.
Get everyone excited because we have one more policy to go through. I want to start right in. We're going to do that, and then we're going to handle a presentation about a new directory protocol.
Sort of we've talked about the fact that Whois is kind of long in the tooth. It's time to look at something else. We'll hear the global reports from the other RIRs and from the IANA, and then we'll have open mic.
And so with that, let me get started. Draft Policy ARIN 2014-14: Needs Attestation for Some IPv4 Transfers. And actually we have just the AC presentation.
So come on up, John.
John Springer: Thank you, everybody. Welcome. We are here today to look at the first reincarnation of 14-4. How did we get here? Along around the first part of this year, I was busy getting ready to go to work starting to think about moving 14 4 to Recommended Draft Policy based on the idea that some of the objections could be addressed biologically pointing out their failings.
We also have a Policy Development Process section stating that any specific concerns expressed by a significant portion of the community must be explicitly noticed and addressed in the assessment of the policy's change.
The reason for this, we don't have to have policy be unanimous. And as long as we can show that the objections to a policy have been addressed, then we can move past them.
However, the earlier wording of the policy was overtaken by events. The way that it was worded was that at that time ARIN had given some indications that -- and members of the community, that transfers were taking too long.
The author of the original wording of the policy then jumped on that and said, well, we can affect how long processes take by eliminating the needs evaluation in a transfer. And so let's do that.
Well, as it turns out, most of the work on transfers is not due to assessing the needs basis. It's almost -- well, a very great proportion of it is taken up doing what was referred to in our panel today as establishing chain of custody and who has the rights to what.
So late in the day the actual policy problem statement was revealed to be inadequate. However, we were reluctant to abandon it because it did have a fair amount of support even with its works. And over time, as people who pay attention to these matters probably notice, things like this keep coming up.
So we didn't want to just abandon it on a technicality again, so we rewrote it. The actual text is in your guides and online. But here are kind of the high points. There are organizations and individuals in the community that feel that the cost of performing a needs assessment and auditing of this information versus the public benefit of restricting allocations to specifically qualified organizations might be out of alignment.
Current needs testing requirements might be more than is necessary and desirable for small transfers, at least because the subject keeps coming up, it's subject for conversation.
This rewrite of this policy seeks to reduce the complexity of transfers by re -- it says "removing," but reducing the utilization needs testing requirement and replacing it with a needs attestation by a corporate officer.
This draft also adds ancillary requirements to recognize and deal with the community's concern that this type of policy could create hoarding and speculation.
And there's a sense that this is a bit of an experiment. So traditional scientific process, you make a hypothesis. Perhaps we can liberalize needs testing for transfer policies and then we do an experiment.
There was concern among some members of the community that that was too much of an open ended thing by its nature. So we've built in a numerical sunset situation into the wording of this particular policy.
We considered it time based sunset, but elected to go with a numerical one. Reorganizes the existing text and then creates a new class of transfers which are permitted via attestation.
So the policy affects two segments of the NRPM 8.3 and 8.4, ARIN transfers and inter RIR transfers. And the wording between them is substantially the same, and it is these four points.
An organization that wishes to transfer a /20, its parents or subsidiaries must not have received an IPv4 address resource via transfer within the last year.
An officer of the organization must attest that the address block is needed for and will be used on an operational network.
It's been pointed out that some of the organizations are big enough that not all actual officers of the company have the authority to make these type of attestations. So that might be an area for future attention.
The maximum transfer size is to be a /20 and that we will stop after 5,000 of them have taken place. So we posted up this new policy to the list. Very little discussion has occurred. There's no particular great amount of support currently seen.
And our attention, Andrew's and mine, being the shepherds on this, is that unless there's some support that shows up on this, we're going to be leaning towards abandoning the Draft Policy. Could belabor the Policy Development Process, but the place that this Draft Policy is in the process is I need three things.
I need to either believe or assert or convince the eight of the Advisory Council that it enables fair and impartial number administration, be technically sound, and have support in the community.
I think I can probably do the first two, and it's up to you whether or not I can do the third.
So we're going to open it up to questions, and these are the specific questions that will be useful to us, other than do you support it, do you oppose it. And we'll take a show of hands at the end.
But do you think the current problem statement is valid in that the community needs to solve it? Does this policy fix the problem as illustrated in the problem statement in a method that you support? And if you don't support this policy but believe the problem statement is valid and should be fixed, give me an example.
Paul Andersen: All right. So this of course being a Draft Policy, look for people to approach the mic to potentially address the questions which John's proposed or give your feedback on if you think this is a problem that the AC should be working on.
I encourage you to move to a mic at a reasonable pace or at least make some movement so that we know. No elbowing, please. Be courteous.
I was going to say: Is anyone typing on remote, Cathy.
John Curran: If anyone would like to speak in favor or opposed, either side, come to the mic.
Paul Andersen: Kevin Blumberg has asked to start us off.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I'm looking for clarification. For 8.4 transfers, this would only apply to inbound recipients, correct? It would not apply to outbound because in 8.4 transfer it's supposed to be the other RIR's policies?
Paul Andersen: John.
John Curran: So I have to look at the exact text. If it's for needs assessment, we do not do needs assessment on an inward transfer.
Paul Andersen: On an outward transfer.
John Curran: On an outward transfer we do not do needs assessment. So it would not be applicable at all.
Kevin Blumberg: Thank you. So just a point, then. You might want to clarify the 8.4 to have that a little less ambiguous. The second question which was also related to all of that is in 8.4 transfers there is text surrounding compatible needs based. Would this policy create an issue with inter RIR transfers if it was passed as written?
John Curran: Not to my knowledge, no.
Paul Andersen: Thank you. I have some in queue. Front microphone, please.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the policy as written. It's not perfect. It doesn't need to be perfect. This is an experiment.
It's an important experiment that we need to move forward on. I'll leave it at that.
Paul Andersen: Thank you. Rear microphone.
Mike Joseph: Mike Joseph, Google. I oppose this policy in all its incarnations.
Paul Andersen: Forms and otherwise.
Mike Joseph: To answer the implicit questions that were raised, I don't believe this enables fair number policy. This enables a carve out for the first 5,000 applicants to receive one of these special so called attested needs, or I'll call them no doc transfers, stated need transfers, if we can learn a lot from the mortgage industry on this one.
And I think if taken to its logical extension where we remove that limit, what we would end up with are tens of thousands, many more than that, organizations, largely end sites, obtaining PI space through this type of policy backdoor that would not otherwise qualify for PI assignment or allocation on their own.
We spent quite a while yesterday discussing the 2015-1 IPv6 PI expansion. And even in v6 we recognize that one of the core principles for ARIN is the policy of sound aggregation, and this type of policy runs firmly against that.
It would allow anyone to just go online and have a "buy it now" button. If you have $2,500 on your credit card, congratulations, you have a /24, no questions asked, go ahead and route to your heart's content.
And that's not consistent with a good portion of ARIN's mission. So I think that this is not a very sound policy.
On the fairness point or on the technical aspects of it, opposed.
Paul Andersen: Question for John Springer, because the 5,000 number was just maybe the -- because I notice it's not in the rationale. So I don't know if it was discussed elsewhere, why that clause was put in. Since it's a little more -- there's a mic right there.
John Springer: The number discussed was originally higher. We were thinking 10,000. But discussed it a bit. Eventually came to 5,000. If anybody wants an idea of what the scale of that is, 5,000 /20s is a little more space than an 8.
If unaggregated, or if they were all at /20s, it would result in about an 8 addition to the routing table.
Mike Joseph: But to be clear, it could be 24s, could be 5,000 /24s.
John Springer: Between that and -- yes, it could all be 100 percent deaggregated, in which case it would be four /8s.
Paul Andersen: Thank you, Mike. David, you're next.
David Huberman: David Huberman, Microsoft. Mike, there are almost 600,000 entries in the DFZ in the v4 table. We can certainly add 10,000 end sites and they could each get a /24 because they need one.
They need addresses rather than being stuck getting them from, say, their ISP. And it has no meaningful effect on aggregation or routing.
We are long past the point where address policy can negatively impact the routing table in v4.
Lee Howard: Challenge accepted.
Paul Andersen: You'll have your time.
David Huberman: Strongly in support of this policy. ARIN policy has for decades now been unfair to smaller networks making capture -- making them captive to large providers or to ISPs in general and having to use PA space instead of PI space.
Needs based assessments are not appropriate for small transfers. We need to level the playing field so that the ISPs are not so much in control and more adopt the RIPE model of initial allocations which is everyone plays on the same playing field, everyone can start with a /24 or a /22 or a /20. I'm even in support of going up to a /16, but I realize that's a nonstarter.
So strongly in support. Let's make the Internet actually work for most of the users, not just the large ISPs.
Paul Andersen: Thank you for that. Rear microphone, please.
Lee Howard: Lee Howard. I oppose this Draft Policy and the horse it rode in on.
I don't understand David's point about -- I don't see it, I guess. I need more words.
And the other, David, you said -- Farmer -- you said that this is really important, but I probably need more words to understand why this is important and necessary.
David Farmer: See panel earlier.
Paul Andersen: Let's not go there.
Paul Andersen: Let's just talk in terms of, please, large ISPs, small ISPs, but let's keep names out of it, please.
Lee Howard: We have a transfer policy, and the rules, from what I understand, apply the same to large and small.
So I guess I want to hear more about what the fairness need is that we're addressing. I haven't seen it yet.
Paul Andersen: But not in support, okay.
Did we have a remote comment? Just to check.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, speaking on my own behalf. I neither support or oppose the policy. I'm pretty much neutral on this one. In early incarnations I strongly opposed it, but there have been enough safeguards added that I can accept the experiment if we decide that the community really wants to do it.
However, I do have to agree with what most of the people opposing this policy have said. I think that the current policy is fair. I think the current policy is sound. I think that the "See panel earlier" comment is jaded.
I think that, with one exception, everybody on that panel was a broker who stands to profit from reduced transaction friction and has a vested interest in increasing the number of transactions whether it actually benefits the community or not.
The one exception being a large end user who stands to benefit from not having to justify their needs as much as they do now.
But the reality is needs basis is a process and a concept that has served us well for many, many years. And getting addresses into the hands of people who actually need them and preventing them from going into the hands of people who want to speculate and otherwise disadvantage the community by obtaining large positions in addresses with no tangible benefit to the community.
So on that basis I encourage people to evaluate the policy very, very carefully.
Paul Andersen: Owen, on the last point, since technically neutral is nonsupport, is there something you think that should be fixed or a rewrite that you can suggest?
Owen DeLong: No, I think this as good as a policy conducting such an experiment can probably get, but, again, I'm not able to stand behind it as is or in any other form because I don't believe it's a necessary or useful experiment to conduct. And I don't believe we should be chipping away at needs basis; I think needs basis serves us well.
Paul Andersen: No to the first question; yes to the second question.
Rear microphone, then we'll go onstage.
Jason Schiller: Jason Schiller, Google. I oppose. This seems to me to be an end run around 4.3. We recently reduced the minimum assignment size to a /24 and made it much, much, much easier for end sites to get IP space.
You need 64 hosts, including your network and broadcast and router. And, I mean, that's a fairly small end site to get their own /24.
And it's as easy as having 64 hosts. If you think that this bar is too high, then let's address it here. Let's change what the requirements are for utilization. Let's take away the 25 percent. Let's take away the 50 percent in one year.
With respect to the problem statement about it being too expensive to do transfers, that transfers are too costly, I think that's what the problem statement said. The easy way to offset that is charge more for transfers.
In fact, if you want to charge more for big transfers, I would even support that, being someone who is more likely to make a big transfer. But this fix doesn't seem to be the right fix.
Paul Andersen: Okay. Thank you. Just before Kevin goes, we're going to close the mics very, very shortly if we don't see someone making movement. Kevin.
Kevin Blumberg: Kevin Blumberg. I generally don't support this proposal, but it brings up a number of key issues. And I think Jason very aptly said if this is trying to fix a problem, let's fix the problem and rather than create a solution to fix a problem.
What was brought up in another policy discussion was that end users used to be able to go to their upstream, say they were multi homing with a host count of one, and be able to get space from their upstream. And that doesn't apply anymore.
If we did it this way, you would basically need a host count of one anyway and you would get your space through the transfer market.
So I think, Jason, there are some differences that we need to address and simplifications.
And maybe the question for the community is: In the other communities it seems -- they seem to have locked on to a /22 as being the first initial, small allocation, and if the community here feels a similar number is appropriate, then is a host count of one for an initial, which is still a need, considered acceptable to this community, or is this community still looking to lock in where you have to have a certain number of IP numbers before you can come to ARIN?
Paul Andersen: Thank you. The microphones are now closing. We'll go to the rear microphone for the last comment.
Mike Joseph: Mike Joseph, Google. Directly to Kevin's point, I think, again, referring back to 2015-1, this community has said even with respect to v6, which is far more abundant, we still think there's a minimum bar to ride for PI space. The community said so in the discussion on that policy.
It was unambiguous. We debated whether 12 or 13 sites is the right number. But there's clearly a number. For v4 it's obvious that there needs to be some number, because in v4 problems are actually in some ways worse.
And more fundamentally, not just looking at deaggregation and table growth, this is a finite resource. And every bit that we let slip out of needs basis is space that can be used less efficiently across the board.
The reason we and all RIRs have a needs basis -- or not all RIRs now with RIPE, but they're fixing their problem. The reason that we have needs basis is because we believe as a community, as a global community, that the finite IPv4 space should be used to some level of efficiency across the board.
There's always going to be exceptions. There's nothing we can do about legacy resource holders that are not efficiently utilizing their blocks, but there is something we can do about blocks that are passing through ARIN today. And what we can do is make sure that everyone who's using that space is using it to some minimum efficiency.
That has a general global interest. There's a community interest in that, a public interest in that beyond simply the organization's local interest. So to simply say just because an organization has 2,500 bucks they should be able to get a /24 and use it however they want or how little they want, that runs completely contrary to years and years of community-based policy for overall efficient utilization of the IP space.
And I continue to be opposed.
Paul Andersen: Fine. I suspected. But thank you for confirming.
John Springer, do you have any final comments?
John Springer: Just one. The number 2,500 bucks has been mentioned a couple of times. That doesn't really have any place in this discussion. The smallest allocation contemplated here is a /20 which has 4,096 addresses at $10 an address. That's $40,000. It doesn't turn into $2,500 even if you deaggregate it.
Paul Andersen: Mike, did you want to --
Mike Joseph: Well, I did want to respond to that one. It's my understanding that it is up to a /20. In fact it says the maximum transfer size is a /20. It doesn't specify that as the minimum transfer size.
So this policy would allow the transfer of a /24, correct? I'll direct that to staff. Or if you want to --
Paul Andersen: Give John a second.
Mike Joseph: If either John wants to comment on that.
Paul Andersen: I'd like to hear John Curran's view.
Andrew Dul: I'm the author of the rewrite. Andrew Dul, author of the rewrite. The intent was this would allow /24s to be transferred under this policy.
Mike Joseph: Okay. That intent and that specific language was what I was referring to in those remarks, John. Thanks.
Paul Andersen: Martin, the microphones are technically closed, but you have a quick rebuttal on this?
Martin Hannigan: Sure. Just to answer your questions. No, I don't believe the statement is valid. I think we don't need to help brokers improve their own processes; they can go off and do it on their own.
I don't think it fixes any problems. So I agree with Mike with respect to his points and the validity of not examining needs and all the problems associated with that.
And with respect to your point, John, about cost, it's negligible. It's actually not even part of the argument. We look at the cost of IP addresses, and you amortize them over some number of years, and then you apply them back into products. Actually they're extremely cheap.
What's probably more important is what the market does with respect to cost, and that's not related to policy. The $2,500 transfer fee is a cash flow problem, not really an ARIN problem, as well, and it too is minor in the grand scheme of things.
But I'm opposed.
Paul Andersen: Thank you, Martin, even though you snuck in there a bit.
Okay. Dan, AC Chair, would you like a poll on this as it's only draft policy. Okay. The AC Chair has requested that we take a poll of the room and the remote asking whether or not the community feels we should continue to work on this proposal.
So I'll first ask the remote to start voting. I'll then confirm the tabulators in position. They appear. Good. Thumbs up.
So, first, all those who are in favor of the Advisory Council continuing to work on this problem pleas raise your hand high. Just as a reminder, if you can hear the sound of my voice, you are eligible to participate in this poll.
One kind of indecisive back there. Okay. Keep them up, please, if you can, until we asked.
Okay. You can lower your hands. All those who are opposed to the Advisory Council continue to work on this, please raise your hand nice and high.
Okay. As we wait for the results, we can thank John Springer for coming up and presenting this.
Any administrative you wanted to go over, John, while we await the envelope? Okay. Talk amongst yourselves.
Coming in perfectly on time. We appreciate -- this, of course, ends the last policy of this meeting. Thank you all for your participation in this process.
And the final result. On the matter of 2014-14: Needs Attestation for Some IPv4 Transfers, total in the room and remote -- which, by the way, someone asked earlier, is the number I always quote -- 105. In favor of continuing to work, three; against, 14.
This information is being provided to the Advisory Council in real time for their consideration.
Thank you, everybody.
John Curran: Thank you.
John Curran: Okay. We're now going to move into some presentations, and the first one is we're going to talk about the future of registry protocols. We'll have Andy Newton come up and talk about RDAP.
Registration Data Access Protocol (RDAP)
Andy Newton: Good afternoon. I'm Andy Newton, chief engineer at ARIN. I'll tell you a little bit about a protocol that's been working its way through the IETF called the Registry Data Access Protocol, which is why it's relevant here, the first word "registry," that's what ARIN is.
A little background. There's this thing called Whois. I don't know how many people know about that. Runs over this port called Port 43, and it's very, very, very, very old.
All right. In fact, how many people know that Whois actually predates the DNS? Wow, I'm surprised. Every time I say that, most people are like: What?
So the Whois actually -- Whois protocol has a lot of problems, the first one being very underspecified. Essentially the standard says send text, control -- or line feed and then something will happen, you'll get some data back. And that's really all it says.
So it's got a lot of problems. It's not very internationalizable. There's no security around it, no authentication.
For context for why it's really the big problem for this group is that it is -- what you can say and what you get back, there's no standards for that whatsoever.
So each registry, each RIR, can do something differently. And, in fact, that's how things have evolved.
So what happened here was about five or six years ago -- actually more than that -- some extremely smart people who are very forward looking and happen to be RIR staff -- just happened to be. It's a coincidence -- started thinking about, hey, there's this whole programming paradigm on the Internet called REST and RESTful Web Services. Quite popular. A lot of the Google APIs use it. Most of the Yahoo! APIs use it. It really is how a lot of the intercommunication goes at the applications level today. Almost everything on your smartphone, most of your apps that are network apps, there's a RESTful API behind there somewhere.
So in 2009 ARIN prototyped a RESTful Whois service and we put a pilot out. And immediately we had a lot of uptake. We noticed even in the pilot environment there were people who were writing flash applications against our RESTful Web Service and other Ajax applications. We thought we had a good thing going there.
In July, the next year, we went full production with that. Coincidentally, but independently, at the same time the RIPE NCC also started working on a RESTful Whois service which they announced in 2010. And I don't know the production date, but shortly thereafter they did go to production.
So, again, ARIN did this in 2009 and the RIPE NCC did it in 2010. I'm not going to say we beat them to it, but we beat them to it.
Anyway, how popular is this? So this is a chart of our queries per second across all our clusters, Whois clusters, and it goes back about four years. Somewhere in 2012 the number of queries over the RESTful system actually increased and surpassed what's going on in Port 43.
So today we have a much higher query -- not much higher. We have a noticeably higher query rate against the RESTful Web services using Whois data versus the traditional Port 43 services.
In fact, the Port 43 queries are going down while the RESTful service, the RESTful queries are going up.
So kind of in the category of no good deed goes unpunished, the RIPE system and the ARIN systems, while we did deploy RESTful Web services, they weren't compatible. Didn't look anything alike.
So they're really just two separate systems, just like we did with Whois over Port 43.
So, anyway, ICANN staff, actually, they were about the same time looking for a way to solve some internationalization issues with Whois and DNS.
And they came to us and said hey can you help us start a process in the IETF to standardize all this. And we thought, well, that's a good idea. We actually had an ACSP open asking the RIRs to try to come up with a common way of serving Whois data.
Very difficult problem. But that was a request of the community. So ICANN staff got involved, helped us get some domain registries and domain registrars into the picture.
And IETF 81, which I believe was in Montreal or something, back in July 2011, we had our first what they call Bar BoF. And then finally, 11 IETFs later, at the speed of IETF paint drying, we got the RFCs published.
So it would have been great if we actually had called this thing RESTful Whois like in the standards; that would be actually a clear name and describe what it does. But we decided to call it the Registration Access Data Protocol. A long fancy name, but it really is a RESTful Web service for Whois data.
All the RIRs now have a pilot of some nature. And we all have the same query interface using this protocol. The other thing is is that I mentioned that ICANN got involved. ICANN, they brought Verisign and Afilias and a couple of the big domain registries along with them when they brought this to the IETF, and all those big domain registries are also piloting an RDAP service as well. It's one protocol to serve all those needs.
So we have five RFCs which got published last month. And actually there's six RFCs, but five of them are about the protocol itself.
And this happened in the IETF WEIRDS working group. IETF has a lot of fun with names. If you hear anyone talking about the WEIRDS or WEIRDS whatever, what they're referencing is the RDAP protocol itself. Straightforward protocol. Uses http. Doesn't create a new URI scheme or anything like that. It's RESTful. Standard format for all the queries, and responses are standardized as JSON as they come back.
And the other thing that IETF did, they standardized a bootstrap for RDAP which also does not exist for Whois.
How does that compare with Whois-RWS, which is the ARIN proprietary RESTful service. Whois-RWS is a bit bigger than RDAP. Based in XML, although there's auto translations that it will do with JSON and HTML and plain text. RDAP is JSON only. Much simpler but JSON only.
As far as complexity goes, Whois-RWS has many more queries than you can do with RDAP, but that's because a lot of those queries are very specific to ARIN and the other RIRs don't have those type of queries in their current Whois systems today.
RDAP is much more of a uniting of all the common parts that all RIRs support.
But from a universality standpoint, like I said, Whois-RWS is specific to ARIN whereas RDAP is something that all the RIRs are going to support.
What does it look like? Here's some examples of a URL for RDAP. And this is querying for an IP address 220.127.116.11.
And you can see what it looks like for each of these three RIRs up here. The first one is how you would ask APNIC for it; the second one is how you would ask RIPE for it; and because at ARIN we like to use the word "RDAP" in our URLs multiple times, you got ours.
The way that would work. You can put it in your browser if you want and you'll get a response. No matter which URL you put in, you'll get the same response. And that's because what's going on here is something the other RIRs also are attempting to do is when you query one RIR, if it's a resource held by another RIR, there's an http level redirect which says go to the appropriate RIR for this information.
If you put in 18.104.22.168 as a RDAP URL and you ask RIPE, RIPE is going to turn around and issue a redirect saying go ask APNIC. They're the ones who are authoritative for that resource.
And I did test this. This does work. RIPE does do that.
The response is going to look like this. It's JSON, not XML. All the techies, all your techie friends will tell you it's better because it uses square brackets, not angle brackets.
Now, I don't know how many people can read that, but that's not human readable either. That's one of the big differences between this and Whois. Whois is a text based -- plain text based output. Doesn't really require much in the way of client support.
But this is an example of a software program called NicInfo, displaying the same thing. And what it's doing, it's taking that JSON data and then reformat it into something that's a lot more readable.
NicInfo is a command line client that we wrote. It's open source. It's sitting out on our projects.arin.net website. You can go download it, play with it all you want.
Like I said, one of the things that the IETF standardized in RDAP is bootstrapping. Bootstrapping is essentially being able to allow a client to figure out where they're supposed to go to ask for the information without having to bounce redirects off the servers all over the place.
The way that works is the IANA will be publishing a set of JSON files which the clients can download on a semi-regular basis and use that to jump start their query processes.
Of course, the way it's going to work in the real world -- so that's the RFC, and then there's the real world. Bootstrapping is actually a fairly technical process and it's not something you want especially a browser -- a client based browser is going to be able to do.
So there are going to be these things called bootstrapping servers out there. The RFCs do allude to this; it's just not clearly stated.
So the way it would work in the real world if someone were to ask for 22.214.171.124, which is an APNIC resource, you would go to a bootstrapping server. The bootstrapping server would say that's 45 /8. Go to ARIN because ARIN has 45 /8. And that's what IANA would publish.
The ARIN server would turn around and say no, no, no, that's ERX space, so I'll reissue an http redirect to APNIC to go to that specific resource. So that's how that's going to work.
The other reason there's going to be these things called bootstrapping servers out there, because, like I said, bootstrapping is a fairly technical process. There are other things you can do with bootstrapping, too, that make the client process or the user experience much better.
Some of these things aren't standardized by the IETF, such as the specification doesn't clearly define how you're supposed to do lookups for reverse DNS delegations.
There is no standardization for entering nameserver queries. There's a standardization for entering name server queries, but that's not part of the bootstrapping process. So if you ask a registry for a nameserver it doesn't know about, according to the RFCs, it can just answer with a 404.
A bootstrapping server can actually be a little more intelligent about that and try to figure it out for you.
The other thing is that the bootstrapping servers can, at least in the RIR space, figure out where the POCs and ORGs are located and hopefully give you a decent redirect for that.
It's not universally true for the domain namespace, but in the RIRs we all take our POCs and we append them with an identifier, marking the registry of record.
One of the other things is that -- since this is a form for policy, I have to mention this -- this wasn't a main driving factor around RDAP, but because RDAP is built on top of http, there are all these access mechanisms that http has. The security document that came out of the IETF talks about this quite a bit.
So there is a -- we can now enable tiered access to Whois information if we want to do that. And it's not just while the simplest form of tiered access could be just passwords that we would give you or whatnot, there's also the concept of federated access, which is having a central location for access for whoever authorizes the information to be handed out.
So that can have implications with policy. Meaning that policy can now be geared towards tiered access if the community wants to do that.
What's the status? IANA is still working on the bootstrapping registry, although the files are actually out there but they're just not populated yet. They're working really hard. It will be done soon.
All five RIRs have an RDAP pilot. I believe -- I don't want to speak for LACNIC, but theirs actually may be in production right now. If you go to LACNIC's Web page, it doesn't say "Search Whois" anymore; it says "Search RDAP."
We have a pilot service, and we're hoping to go to production service in June.
Here's our URLs. So the top two URLs -- I don't know why one is blue and one is black. That's got no bearing on anything. But we have a pilot service. And although the production URLs aren't in service yet, that's what they will be when we are done.
Going back to the software. If you go to projects.arin.net, NicInfo is an RDAP command line client that we wrote. It's completely open source.
On top of that, ICANN has contracted with CNNIC to write open source clients and the software as well.
That's it. Any questions?
John Curran: Microphones open.
Mike Joseph: Mike Joseph, Google. I have several questions. First, do you anticipate -- first off, sounds like RDAP protocol implementation at ARIN is less complete than Whois-RWS. So is that assumption correct, and do you ever anticipate sunsetting Whois-RWS in favor of RDAP?
Andy Newton: RDAP doesn't have the amount of information to get out of Whois-RWS because it tries to be the common platform that all the RIRs support, and we would have spent a lot more time trying to get standardized if we had thrown in everything.
As far as sunsetting services, think that would be up to the community.
Mike Joseph: Do you envision it replacing Whois-RWS for ARIN? By "you," if J.C. wants to answer that.
John Curran: I'll take that. There's a whole bunch of RWS activities that can only be done that way. It's a protocol that enables transactions, whereas RDAP is more oriented as a replacement for Whois than a replacement for the transaction interface to ARIN.
Mike Joseph: I wasn't referring to ARIN offers two APIs, Whois-RWS and it offers the RWS registry. I was referring to the Whois component.
John Curran: I wouldn't envision sunsetting anything unless you folks asked.
Mike Joseph: My second question is there's been reference to RDAP for RWhois, as an alternative to RWhois. The first part of the question is: Do you have any plans to utilize -- to allow entities to utilize RDAP for RWhois?
And, secondly, along those lines, there's actually a pending ACSP, 2013-22, to sunset RWhois, which I would have significant concerns about, in favor of RDAP.
So your presentation concerned RDAP for Whois, but what are your thoughts for RDAP for Whois?
John Curran: My question is: What would you like to see us do there?
Mike Joseph: I would like to see RWhois not go away for quite a while, because I think it would be a fairly complex transition for many entities.
John Curran: Okay. That's good to know.
Mike Joseph: But there's a pending suggestion to eliminate it.
John Curran: Right. And have you commented on the suggestion?
Mike Joseph: It was from 2013.
John Curran: It was from 2013? You can still comment. Feel free.
Mike Joseph: Thanks.
But I'd like to understand, at least, is RDAP intended to be offered as an option for entities?
John Curran: Is RDAP intended to be offered as an option as an alternative to RWhois?
Mike Joseph: That was the question I most recently asked.
John Curran: Do you desire that?
Mike Joseph: I have no particular feeling; I'm simply asking if that's what's intended.
John Curran: We're here to get feedback from the community. We don't know.
Mike Joseph: Finally, where would you like us to comment on this?
John Curran: You can send it to the ARIN Consult Mailing List and comment on the ACSP, if you wish.
Mike Joseph: I think it's only valid when the ACSP is open. Correct?
John Curran: It's a Mailing List. I promise you it will take your mail.
Owen DeLong: Owen DeLong, ARIN AC. Along the lines of what Mike was talking about, I believe that RWhois is codified in some portions of the NRPM. So it probably shouldn't go away.
Would it be possible to add RDAP as an alternative for providers to use without modifying the NRPM accordingly?
John Curran: The NRPM ideally would reference directory protocols so that you're not stuck in a particular implementation of a particular protocol but could just have directory and we'd have a list of approved ones. That would be ideal.
There is a group called ARIN AC that knows how to change the NRPM to do that, and I would find one of them.
Owen DeLong: I don't have a problem finding one of them. I'm looking for clarification on to what extent the need exists for doing so.
John Curran: So we actually sit up here talking about ideas and then ask you for suggestions about what you want. So what's your suggestion?
Owen DeLong: I guess we have policy proposals to write.
David Conrad: David Conrad, ICANN. Could you go back to the graphs of the performance for your rates? There you go.
So I think you said that was queries per second. I suspect that was incorrect.
Andy Newton: You're probably correct about that, yes. It's total queries, yes.
David Conrad: So, presumably, I'm guessing here that you're seeing a large number of queries from a small number of sources. Can you sort of give ballpark figures on the number of sources you're seeing queries from?
Andy Newton: Mark is standing up; I'll let him answer.
Mark Kosters: Y'all are tall or something. Mark Kosters, CTO of ARIN. We have not actually done analysis yet on some of this data. So we'd like to do that at some point in the future.
But one of the things we have seen that Andy sort of alluded to is people are writing applications against these things. And that we have seen lots and lots of examples of. Which is actually awesome. Whereas Whois you can't do that at all, unless you write a scraper.
David Conrad: I guess the real question I'm curious about is sort of the load implications that you've seen. I had heard rumors a while ago that your Whois server was sort of creaking under the load of queries.
I was wondering, with the increase on queries against your RDAP server, are you seeing a reduction in load, or are you seeing things about the same, or an increased load?
Andy Newton: Our implementation for Whois and RDAP and Whois-RWS, it's the same software, it's the same servers, clustered servers, but it's the same software.
The Whois, the way it is implemented is the -- there's an engine which with RDAP and Whois-RWS are directly implemented in, and then there's a proxy that the Whois Port 43 uses.
So the Port 43 process, it's a little slower because there's more to process to get that information, the way it works.
We actually are thinking about improving the performance there, and we have some plans in the works for that.
But that's how it's implemented. One of the things that we do see with Whois in Port 43 is the way -- so there's no bootstrapping in Whois today.
What a lot of the clients will do, they will query ARIN first trying to figure out where a resource is, even though it's clearly something that forever been in the RIPE space or wherever else.
So we get a lot of queries for the other RIRs today. Hopefully with the bootstrapping process that will be offloaded from us.
David Conrad: Shifted to ICANN. Thank you. Appreciate that. Thanks.
John Curran: Thank you.
Naela Sarras: Naela Sarras with ICANN. Could you go back to the slide that talked about IANA's preparation for the RDAP bootstrap? You said something about soon ish on that slide.
Andy Newton: Yeah, soon ish is kind of a -- it's a nebulous term.
Naela Sarras: So just a quick clarification. So at least with regards to the RIRs, we have set up the JSON registries and we started talking yesterday with the RIRs.
We are ready to start taking the production URLs and list them in the relevant registries that are talked about in the RFC.
So at least with regard to the RIRs, we're prepared, and we're starting to talk to the RIRs about what to put in those registries.
Andy Newton: So soon ish is real soon.
Naela Sarras: Now.
Andy Newton: Now.
John Curran: Excellent to hear. Thank you.
Any other questions for Andy?
Okay. Thank you.
John Curran: We're now going to start on the global reports. First up is Axel who will give the report from RIPE.
Global Reports: RIPE NCC
Axel Pawlik: The update from the RIPE NCC. I'm the Managing Director for RIPE NCC in Amsterdam, as you probably know.
There's quite a lot of things going on, lots of excitement internally, externally buzzing around the world and talking to lots of people about the good things that we are doing and we want to keep doing.
I'll go through some of them. Our membership is scarily growing. We have as of probably yesterday or so 11,584. Click. Click. More coming.
You can see the upturn there towards the end. A little bit scary. We have to try to keep our income sort of in check as we're making -- doing a lot of proposals for charging schemes. We want to be conservative and responsible.
We don't want to go too far down. On the other hand, those guys keep coming: So what do we do? Spend money carefully.
We are -- as you know, we have been expanding into the regions. For a couple of years we've been doing regional meetings in the Middle East and the Russian region.
We have heard that this is all very good and people love hearing from us and seeing us occasionally, but they really want to see us more permanently. We said, okay, then, we can do that.
We have opened an office in Dubai with a couple of people there. We have opened an office in Moscow with a lot of the people there speaking local languages, of course, and also giving us insight into what's going on regionally.
So that's very good. And lots of smaller events with our members just to show we care.
Regional members. Yep, that's it. Communities and governments. Yes, we do the big regional meetings, but we've also now started to do a series of events in southeastern Europe.
But beyond that even we do something that maybe ARIN does in the form of ARIN on the Road, I think. That's something we're going to one country, one city, meet a couple of members there, so a roomful, they're all happy to see us, we're happy to see them. Then we go home and, oh, what do we now?
So we're currently thinking about a structured way of follow up, what we have been hearing there.
But there's lots of things, lots of places we've been going last year. Bulgaria, Kazakhstan, Azerbaijan, Iran was very interesting too. This year -- next -- next week we're going to Serbia, Georgia, Armenia and others are also planned.
This is a great thing. It takes a lot of traveling around, but it's worth it.
What we do see is that we get lots of new members and they all get their /22 and occasionally they rather quickly merge and then have a little bit more than one /22. It's all according to the policy. We are aware that we are informing our community about that. So that's how it is.
Transfers are increasing. We had not quite a thousand last year. This year isn't over yet. I think we are sort of just over a third of it. Not even a third of it. 892 already. So it's quite dramatic.
We have been told to loosen up a little bit. Since we're running out anyway, we shouldn't be too bureaucratic anymore. And so that's what we've been doing policy wise.
As you've seen yesterday, quite a lot of our membership has IPv6 address space. Not all of them are using it, but it's there.
We do lots of fair and impartial hands on IPv6 training courses throughout our region. We do lots of road shows as well for -- this year we have ten planned already. Training has been improved. We do webinars. And we have a person in house that coordinates all IPv6 efforts, Nathalie.
So hijacks. IPv4 resources we have heard this morning also do become more valuable. It's not unexpected. People want them, and they want them really, really hard and they want to get them any way they can.
So we've seen fairly sophisticated fakes of passports, identity papers, registrations, company host registration type of thing. Websites. They look like the real thing nearly. So we have to look at this more carefully, and we do. Last year we looked fairly in depth into 233 resources or blocks and whatever requests.
It's a bit of a difficult thing to be very, very, very, very annoyingly diligent about this or just also be efficient. So I've been trying to find the right way there.
We used to do audits. We don't do audits in that form anymore. But what we do now is we basically set up a batch of information on all the holdings of a given member and send it out: This is what we have on you. Is this correct? If this is not correct, please inform us of any changes.
That has been going on now for quite a while. We were a little bit concerned that it might be seen as us priming them or being too intrusive, but, no, they like it very much and they thank us for doing this because it also keeps the registry up to date and they need to -- they can be less proactive than they had to be before.
RPKI. About a fourth of our members have certificates now. You can see -- what is it? rough eight /8s are covered by ROAs. That's quite nice. We continue working on it. Functionality has increased in that now PI space, and legacy space is included there as well. Software is being packaged nicely. You can look at it and it's open source. And as we go on, we improve also as resiliency things are looked at.
Training is exceedingly popular. People want to see us face to face, and we want to see our members face to face, too. But we have a really large service region. We have so many members. It's difficult.
So we thought, instead of just sending them leaflets, we do something more interactive, what we call RIPE NCC Academy. Basically it's an online course on the database so far.
Again, very, very popular. People really like it. They get a certificate in the end. And of course what we want to do is to increase the number of courses and the breadth of material there.
Member consultation. Yes. We do regular surveys. Big membership surveys. The last one we did in 2013; the next one we'll be doing next year.
In between we do see the need to check in order to take this as an opportunity to go back to our members and: Did you see any progress? Did we do what we promised that we wanted to do?
And we've done one of those set of smaller meetings face to face from member consultations, previously known as focus groups, throughout our service region, with external consultants, and they wrote the findings up where we have identified 48 of them. We are working on them.
We published the report. The Board has looked at it and commented on it. So basically this is on the way to the next big survey already.
Oh, my God. Yes. I looked at our website. It's all strange. It's new. We launched last Monday. All these complaints: We can't find anything. We have to use Google to find things. That's what Google is for.
On the other hand, it's a little bit embarrassing. So we looked at all sorts of structure, who is looking at them. We did some tests with people who were interested in helping us. We launched last Mon -- that's yesterday, I think.
There were some small blackouts as well. But we are rolling out different parts of the website over the course of this week.
Have a look. It looks different. Einar talked about this earlier. The legacy resource holders now, we have finally a policy on that. That's a great change.
Stewardship, we had a whole session on that yesterday. It is exciting. We go forward, we -- you know, you too.
Outreach. We continue, of course, like I said this morning in the NRO talk already, we continue with the Internet Governance Forum. That is important to all of us. But also what we do within the region is regular government roundtables, roundtables with governments and regulators. Quite a number of them we used to have in Brussels because there are lots of governmental people there for the U, at least.
It's sometimes difficult to find the right date for them. So we'll have a short, smaller meeting over lunch with some of them at the next RIPE meeting as well.
We do meetings with law enforcement. A couple of weeks ago we were in London again.
Finally it's growing out a little bit from the UK and beyond the Americans, also traditionally come into other regions as well. We had a fairly big group there from Southeast Asia.
We try to be there with all the RIRs as much as we can. It's a valuable thing to do. It manages expectations from the police forces around the world. We explain how we deal with requests and the like.
Yep, there will be a RIPE meeting in Amsterdam. You heard about the city. It's very interesting. It's May. The sun will be blasting from the skies. There might be some rain.
You're very welcome. There will be socials and parties and dinners, as you know. So if you have any questions, how to get there and other things, I'm here. Andrea is here as well. Andrew is here as well. Just talk to us.
John Curran: Any questions for Axel?
John Curran: Next up we'll have the report from LACNIC. Gianina.
Global Reports: LACNIC
Gianina Pensky: Good afternoon. My name is Gianina. I'm from LACNIC, and I'm going to do the update report.
Well, LACNIC is one of the world's five RIRs. We have coverage area of 34 territories. We have two NIRs -- NIR Brazil and Mexico. Both NIRs are members of LACNIC. We have over 4,300 members. We have 41 full-time staff over nine countries. And since February of 2015 we have new CEO, who is Oscar Robles.
Here we can see our membership growth we have since our beginning that was in 2002, and we have now over 4,475 members. Most of them are ISPs of category small/micro.
About the IPv4 exhaustion, we have two /11 IPv4 blocks reserved. One is for soft landing and the other one is for new members only. We are now in phase two. That is the one for soft landing.
We have now for both we are assigning -- for ISP in general, we assign the maximum allocation is a /22 and in general for end users we assign /24.
Also the resources allocated by IANA to LACNIC will only be allocated under the guidance assigned to new members. That's phase three that you'll see in the next slide.
These are the different phases that we are facing in the IPv4 exhaustion. Now we are in phase two which organizations may request additional resources every six months. And this process will be implemented until the /11 reserved for gradual exhaustion is finally exhausted.
You can see more detailed information in this link, which explains every phase and how does it work. You have the information about the IPv4 free addresses we have now. You can see also it in our website that it updates every day.
This is the current state of the /11 block in phase two, how it is divided. We have still 47 percent available. And it was assigned 50 percent to Internet providers and 3 percent to end users.
Here we made a modeling exhaustion based on the data we have, and we can estimate that the estimated date of the IPv4 exhaustion will be in January 20mi.
These are the IPv4 and IPv6 allocations in the last 12 months. We can see here that we have similar quantity of IPv4 and IPv6 allocations. This is because in our region when you ask for IPv4, you must also ask for IPv6. This is the explanation because why we have similar quantity.
Here you can see some information about the IPv6 information in the last years, in the last few years, and the percentage of our members who have IPv4 and IPv6 assigned.
This is the IPv4 rate in the last month, too. We can see the huge decrease in June 2014. This is because here is where we enter this phase.
About our policy update, we have now -- we have recently implemented the proposal about modification to the text describing ASN distribution requirements.
And we have two policies in -- actually we have three policy proposals in discussion. We have just received one during these few days about -- the one is update to the Policy Development Process and the other one is -- well, you can see there. It's a little bit large. And the other one we have just entered discussion, the new proposal about inter RIR transfer.
We have done some workshops in the last month. One is IPv4 workshop in Trinidad and Tobago, and the other one is a computer security workshop in Costa Rica. And the other one is our first IPv6 basic workshop on our online campus. Those are the links.
You are all welcome to our next event. That will be in Lima, Peru.
So thank you, and if you have any questions.
John Curran: Any questions? No. Thank you very much.
Very good. Moving right along, we have the presentation from APNIC by Paul Wilson.
Global Reports: APNIC
Paul Wilson: Good morning, everyone. I'm unusually jet lagged this week. If this seems like a remote presentation, that's why.
Okay. Some updates from APNIC. Our vision is a global, open, stable and secure Internet that serves the entire Asia Pacific community. You may have heard that before we developed it over the last couple of years.
We're reporting these days according to three different activity groups -- firstly, serving our membership; secondly, supporting Internet development in the Asia Pacific region; and, thirdly, collaborating more widely in the work that we need to do.
A few charts.
IPv6 is looking fairly same-ish from month to month these days. We're trying to spice it up a bit by giving more information about allocations versus assignments, the size of our allocations and the method or the request type.
We've got an easy one click so called request process for initial minimum IPv6 delegation. So you see some extra interesting data there.
Maybe more interesting is IPv4. We're in our last /8 policy at the moment. Of course, that's the rationed up to a /22 from the last /8 that was reserved. Quite a reservation. It's designed to last for quite a few years.
It's being augmented by the return space received from IANA. And under a policy approved this year, last year, we are now able to make a second rationed allocation to members who have already received their last /8 allocation from that return pool while it lasts.
Interestingly, when we had the first of the allocations the subsequent allocations from the IANA last year, we had a pretty alarming spike in consumption, up to 800 of those delegations in a single month.
Don't know why the last /8 allocations also increased at the same time. But somehow we did some publicity that hit the spot and people got to hear about it. We went pretty crazy for a few months there, and things have settled back down to about 300 allocations total per month, as you see there.
IPv4 transfers, nothing like the level of activity that Axel mentioned at RIPE NCC. We're only doing 10 or 15 total transfers per month. And as you see there, about a third of those roughly would be inter RIR transfers so far. All of them coming from ARIN. We've had one transfer in total go the other way to ARIN, I think.
John Curran: No, in progress.
Paul Wilson: In progress. Leslie is shaking her head. I thought we had one. Then, if not, all of that has come from the direction of this region to Asia Pacific.
We've got a listing service which allows people who have received a pre-approval to be listed on our website. So half, roughly half, of the pre-approvals are listed. And in terms of receiving a transfer -- sorry, the list of pre-approvals that we've got is approximately one third used. That is sort of actioned by way of an actual transfer.
ASN assignments are never very active in our region. So again spicing it up with a bit more information about what's going on. We are allocating mostly 4-byte ASNs and we're also quite happily receiving very few sort of rejections of returns. We do allow someone who has received a 4-byte and finds they cannot use it to send it back. But it only happens in a few cases.
Our membership is growing exponentially. And it's growing faster now because of the smaller enterprises and small networks that can't receive an upstream allocation anymore so they come straight to us for the small allocations.
Faster growth is happening within our NIRs, though. So in the last year we had a pretty big spike of members within NIRs. We count -- unlike LACNIC, we count these separately. So you have to add these two charts together to see our total of about eight and a half thousand organizations or ISPs that are served in the region.
Okay. A few service developments. We've finally undertaken a distribution of Whois around four separate sites, which has improved response time and allowed us to offload attack traffic, which is quite well illustrated here in that we had an attack recently that, as you see there, left the main servers, the original primary servers, almost untouched.
Another nice one there. We were spiking up to 5 or 6,000 queries a second which were all being sunk at our US servers instead of coming all the way to APNIC.
We're redesigning and reimplementing gradually, according to design, our internal systems based on architecture which is message based. I can't tell you too much about this. You'll have to consult with our engineers, but it's based on something called Apache ActiveMQ for interprocess communications. That's a whole paradigm of design that allows better auditing and replay and backup and sort of faster development cycles across those systems.
We finally finished virtualizing 175 plus machines, all being managed under Puppet configuration management. We're now in the engineering area doing a regular audit and exercise of our disaster recovery plans.
Accounting and transparency is something that's -- sorry, accountability and transparency is something that's quite important these days. I think all of the RIRs have been sort of encouraged to continue to develop our systems in the light of all of the discussions about Internet governance and accountability of other organizations such as ICANN.
So you've probably heard about the RIR accountability matrix. APNIC has updated a lot of accountability information on our website so you can see how the organization works in detail.
That's also reflected in a new approach to budgeting, which is now activity based, and so those three areas of activities as I mentioned before -- serving members, supporting the region, and globally collaborating -- are being displayed or being used as a framework for budgeting, and within each of those a number of different activity areas.
So that's in response to membership requests, and it replaces sort of a more chart of accounts based budgeting that we used to do.
Okay. Moving on to supporting the region. Does there happen to be some water at the table? Thanks.
Somehow I didn't drink enough last night.
Supporting the Asia Pacific region. Few slides here. Policy development is under that set of activities. You've heard about a policy implementation. It's probably the main one from last year was this one that allows us to distribute the return space from the IANA as sort of additional subsequent allocations to members who need a subsequent last /8 allocation.
We implemented a new tool for consensus measuring in our meetings. This is a realtime thing. It actually looks a lot better if it's animated because it moves as the discussion goes on.
Participants in the room or remotely can sort of -- can register, they can change their minds how they feel about the proposal under consideration. And that's being used not as a voting mechanism or as final decision making mechanism but just as an aid to the Chairs in determining how they see the sense of the room.
Like RIPE NCC, a lot of training happening at APNIC. Nearly two and a half thousand trainees trained last year, 76 courses, 29 locations, and then another 500 in online e learning. 63 videos in our archives. I don't know who is watching them, but there's 178,000 views last year, they tell me. So someone's taking it all in.
Events last year. Our main two events are like the other RIRs, sort of the main conference events that happen twice a year. But also like ARIN and RIPE NCC, at least, we're conducting these regional meetings as well, and there were five of those last year.
They move all around the region in an effort, as Axel said, to be able to reach our members in community more effectively.
We do a lot of work with NOGs, and there are quite a few new national network operator groups being formed in the region. We're sort of helping, providing contributions where we can, where it's needed. And we send hostmasters, member services staff to meet with members, as well as often doing training.
And across different sorts of events, whether it's training or outreach or informational, we're still doing, of course, a lot of IPv6 related work.
Something also that's been requested more and more by members is information and outreach in support in infrastructure security matters.
So we've got a dedicated security outreach guy who has come from the CSIRT community, Adli, who gets around doing workshops with law enforcement, just like some of the other RIRs are doing. Also training and representation. He sits on the first steering -- first board steering committee as well.
We haven't had a lot of movement on RPKI in the region. So we've got a new campaign, Ready to ROA, and that's encouraging people to register there, to certify their resources and register their ROAs. And that's going pretty well thanks to the snappy graphics, I think.
Okay. Finally, collaborating. There's a lot of things we do under this banner, but one of the reasons for our activity based budgeting was to show that it's not -- that these activities, which include Internet governance related activities, aren't a huge proportion of our budget or expenses. But they're still very important.
We consider international IPv6 advocacy liaison with intergovernmental organizations liaison with other RIRs and others in the community, IETF and ICANN and so on, as well as the Internet governance activities to fall under this Global cooperation framework.
And when you put all of those things together, the point of this map is to show how busy we've been in the last year in terms of the engagements of APNIC across a bunch of different activities.
Okay. Finally, nearly, a new development last year was a blog that was launched late in the year, actually in August. It's had several hundred posts to it so far. Mostly from staff bloggers. But also we're allowing and inviting and encouraging community guest bloggers to contribute. And we're getting many thousands of views of that blog.
It's a really good way to sort of bring together all of the announcement channels that we have had through different and sometimes confusing sort of lists and so forth and put them all in one place.
It's part of improving communications generally. So we're doing much more systematic social media these days and really getting ourselves out there and seeing some good results, I think.
And finally our next meeting, APNIC 40, is in Jakarta in Indonesia, the 3rd through the 10th of September. I'd hope to see some of you there. Everyone's invited, of course.
And that's all, unless there are any questions.
John Curran: Any questions for Paul? Thank you, Paul.
John Curran: Okay. So next up we have the AFRINIC presentation. Madhvi? Yes.
Global Reports: AFRINIC
Madhvi Gokool: Good afternoon, ladies and gentlemen. I'm Madhvi Gokool, Registration Services manager at AFRINIC, and I'm here to give you the AFRINIC update.
So as from next week, Monday, we have a new CEO, Alan Barrett.
I've been here since Sunday, and I've heard quite a lot about his involvement at all levels, especially in the CRISP team. We're celebrating our 10 years of existence this year, and as of the end of this quarter, the first quarter of the year, we have 36 full-time staff. It varies between 36 to 40. I don't think it has exceeded 40 yet.
Since we were set up, we're now serving more than a thousand members. We grew at a rate of 130 per year.
We have issued roughly 70 million of IPv4 addresses since 2005. For the first quarter, the numbers were 3 million. We expected to grow. We had quite a huge amount -- yes, it's a big amount, a big increase in the number of IP addresses we issued last year, and we see -- we hope that the trend will increase, in fact, because there was some requests that have been pushed to this year because they were not compliant at that time.
As of now we have 2.74 /8s available of v4 in our port. We have issued roughly 1100 ASN numbers. Regarding IPv6, 430. That's 36 percent of our membership base have an IPv6 prefix.
And as part of the project that was being worked on, 51 countries out of our service region have at least one IPv6 prefix.
We're working with the other five to see if we can get them on board, just at least we know. Some of them have one operator. So to get them at least to start using the v6.
Training stats for last year. For INRM resource management and IPv6, 353 engineers were trained and 11 training workshops that happened in nine different countries on the continent.
And for 2015, we have finalized the plan and we will be in 14 countries to host training workshops, all thanks to some local host who have volunteered to host us.
We had a restructuring exercise last year, which led to two new departments being created, the Research & New Technology and the Capacity Building & Community Development. Existing staff were reshuffled so that they can focus now more on activities of these two departments.
And in the member services unit, we had the creation of the customer services unit to liaise more with members and prospective members. And they have some projects that they will be focusing on for the next years to come.
The work is carrying on regarding RPKI. We have the DNS Anycast service for infrastructure, and that has been extended to ccTLDs in our service region.
The work on DNSSEC is carrying on as well and we provide the service to our members, and we also have the Root Server Copy initiative.
We participate in activities regarding Internet governance. There's ICANN meetings. ITU and IGF.
We also cooperate with African union. There's the AXIS project, in which the African Union is working with exchange points in our region. At AFRINIC Internet exchange points, if they comply with the existing policy requirements, they can get a /24 of v4, /48 of v6 and AS number and we don't charge them anything for that.
We also engage with governments in regard to IPv6 deployment. The Capacity Building department is starting the work to engage governments in our service region to be -- to increase usage of IP resources and to also get them to participate with us.
And in our training program we have also included programs for training policy makers and managers.
Last year we deployed new Whois server. It's based on the RIPE Java code. The MyAFRINIC member portal that we offer to members, it was fully integrated with our billing platform. That has helped a lot in billing our members accurately and also telling them the invoice I was just checking, the invoice also shows the resources that they hold. So that decreases the back and forth between the members and asks why are you charging us for so much, what did we do, and stuff like that.
And we also worked on a new member enrollment portal to decrease the amount of time that hostmasters spend asking for information from the applicants so that we can see the justified needs before approving the request.
So we are trying to automate as much as possible the information, the most basic information that is required from the applicants so that we can quickly and easily approve the request.
We also launched the AFRINIC routing registry last year. It's open to AFRINIC members.
There is quite a bit of hand holding happening to assist them to move the route objects from the RIPE routing registry, which we were asking them to use previously to move the objects to our routing registry.
They faced some issues. I think some operators, they still want to query the RIPE routing registry. They don't query the AFRINIC routing registry at the moment.
There's another project that is happening, and the customer service unit is busy working on that. It's the member contact update. We want to improve on the accuracy of the contact information, be it for the contact persons, the point of contacts for the organizations, as well as the details of the organizations. There could have been change of names, change of addresses, change of email domains.
So we're trying to address that in the project. It has started about three years ago, and I think we have made a lot of progress.
We have three policies under discussion and one that was recently ratified and we implemented it. Anycast Resource Assignment was recently ratified. So it's being implemented at the moment at AFRINIC.
We have upcoming elections for two seats for our board members. There's election for PDP co Chair, and that is happening in our June meeting, in June this year. And there will also be an NRO NC/ICANN AC representative election in November of this year.
This map, everything in green is where we have been since 2005. And that is also thanks to a lot of sponsors. They sponsor our v4 INRM training or IPv6 training, and that enabled us to be there, as well as we covered a lot of countries, thanks to sponsors as well as funding from AFRINIC.
Our next meeting is in Tunis. It will happen next month. We invite you there. We also celebrating our 10 years of existence there. So some of you who already know AFRINIC since 2005, if you have any photos, you can share with us.
John Curran: Any questions? Okay. Thank you.
John Curran: Okay, we're now roughly on schedule. We're going to take a short break and come back at 3:30. We'll resume the global reports with the IANA report.
So refreshments are outside. I'll see you in 23 minutes back here at 3:30 promptly. Thank you.
Yes, you can pick up your jackets. We have ARIN jackets, I believe. ARIN jackets out there at the registration desk.
You have a coupon or something, go get your jacket.
John Curran: It's a wonderful break, but we still have a schedule to keep. We're going to have the global reports continue at this time. And the next report up is the IANA report, which will be Naela.
Global Reports: IANA
Naela Sarras: Thank you, John. My name is Naela Sarras. I am the IANA services manager at ICANN. And normally you see Leo or Elise up here giving the update. I'm actually taking over a little bit of the responsibilities from Leo with regards to working with the RIRs.
I've been with ICANN since 2005 but mainly focused on domain names, and then for a while I did IDNs, and now I'm getting introduced to this wonderful community.
So in terms of the IANA update, today I'm going to talk about just briefly the last IPv4 allocation we did, quick RDAP implementation update of what we're doing, a little bit on the audits that we do annually at ICANN, and then performance reports.
So for IPv4 allocation, in keeping with the agreed global policy, the allocation, this is the allocation of the recovered space back to the RIRs.
This happens on March 1st and September 1st. The last one we did was March 2nd because it was the first business day after March 1st.
The formula or the little software tool that we use to determine how much space to allocate is on GitHub, and I have the link if anyone wants to download it. We frequently -- right before an allocation we get emails from people on the RIR saying when is the allocation happening? Can I know ahead of time what's happening? So we sometimes either just run it and send them info or we say, hey, go download it and run it for yourself.
We put a link here to the last allocation. As I said, on March 1st. And this is what everybody got, a /13, about a half million numbers. And this is a little bit of snapshot from the actual registry, the IPv4 registry. So that was on the last allocation.
Now on RDAP. I'm really thankful for the presentation Andy gave, because it gave a very good background of where we're at and what you guys are doing.
So our portion of this is the IANA consideration section in 7484, which was published in March of 2015.
This one calls for the IANA to create the JSON registries that we'll populate with the URLs you'll provide us. The
JSON registries are published.
I put this chart in yesterday just to show where this is going to show up. So this is the IANA IPv4 address space, straight right out of the website. I don't know how well you can see it, but put a circle around the RDAP column. Essentially there will be a URL you'll give us that will show up in the RDAP column.
Again, for RIRs, this is already set up. This applies to these three registries listed here -- IPv4, IPv6, and AS numbers.
And we started talking to you all about what the process is going to be for when you have your production URL ready, how you'll submit it to us and then what will happen once we go ahead and populate the registries with those URLs in terms of maintenance, if you need to change the URL.
So that's what we're talking about. My colleague Selina and I expect to write up what we learned this week, and we'll send it back to you and we'll go from there.
We also wanted to talk about something we do annually at ICANN, the Service Organization Control audits, the SOC audits. These are things we undergo annually.
We have two audits that we do. The SOC 3 audits happens on the DNSSEC root KSK systems that we do. So this is work for assigning the root zone. We recently completed that audit and maintained the certification for the fifth year in a row.
If you're familiar with these audits, before I think we used to call them the Systres [phonetic] audits, so that's the same thing.
We also do what's called a SOC 2 audit. That one is on our systems, the IANA systems that we use to process the work that comes to us from our stakeholders. So that's for our ticketing system, for example. We use RT.
We use another tool that we rely on very heavily called the root zone management system for all of our work with the TLDs.
And so those two audits are very important. They help us keep monitoring our systems and keep an eye on the controls and watch out for any issues.
Another topic we wanted to discuss here is the performance reports. So I think this is something that we've said before and we've brought examples here to these presentations.
IANA publishes every month its performance reports. Some of these are per the SLA that we have with the IETF, some are the root zone management reports. All of them are linked from this Web page that we have up here.
What's important about what these performance reports are it's our monitoring of ourselves. And the KPIs, key performance indicators, that we're reporting against here were developed through public consultations with the community.
So the famous public comment periods that we all love. So lots of public consultations to come up with what key performance indicators we want to measure ourselves against.
We give some examples. This is an allocation of Number Resources for February. So this number is dated -- this slide is from the February data. And unfortunately, because of the volume, is not there. This is -- everything here is showing as compliant 100 percent. So it's not a great slide. I apologize about that.
I do have the data for March 2015, but unfortunately I couldn't -- the timing was just not right for me to include that data. But that data will include, for example, the March allocation of the IPv4 data. And, again, when we publish it, I expect it all to meet the KPIs.
Another example we included is our work on the protocol parameters. We played a little bit with the X axis here. This is from our -- this is our numbers for our work with the IETF, protocol parameters. The IETF expect us to be at 90 percent of our performance, against our performance targets.
And so 90 percent falls somewhere along the bottom of this chart. We actually have a little bit of a higher target for ourselves internally. So you can see from this chart that we typically fall well above 90 percent and well above the 95 percent which we have for ourselves internally, and we're in the 97 to 99, 100 percent usually.
And finally another example we have on our performance reports is the root zone management report. This one is -- this one is a very, very high level snapshot that just tells you what type of requests are coming to the IANA for root zone management and how long it takes us to process each time.
There's a lot more root zone data that's published on the performance reports page that I encourage you to go and look at. But essentially I like it because it's a nice breakdown of how long you can expect when you have a request with us for a certain change, how long it would take.
Please be aware that the data for delegation and redelegations includes both ccTLDs and gTLDs, and of course we're doing lots of gTLD delegations right now, and those are coming in very quickly in terms of processing.
A lot of volume coming in and a lot of processing happening very quickly. If there's a ccTLD redelegation or a ccTLD delegation for that matter, request, you can expect the numbers to be skewed a little bit, because it takes longer to do a ccTLD redelegation or delegation understandably because there's a lot more processes to fulfill to make that kind of a change.
And I think that's all we wanted to talk about here in this update, and happy to take any questions you have for us.
Martin Hannigan: Marty Hannigan, Akamai Technologies. I wanted to compliment you on your Twitter feed. I'm an avid follower of the IANA updates, and I would encourage you to do more of that.
Naela Sarras: Thank you.
John Curran: Excellent. Any other questions? Thank you very much.
Naela Sarras: Thank you, John.
John Curran: So I guess the good news is we have a lot of time for our open microphone. This is the section where we take any topics that have come up. The microphones are open. Please approach the mics for any other topics or questions you might have.
Lee Howard: David Huberman called me out earlier today and said I was unaware or didn't understand the plight of the small ISP in dealing with ARIN.
And I confess that I may well be ignorant. It's been something like 20 years since I've worked for a small ISP. I would like to ask or invite ARIN to convene a panel of small ISPs at the next ARIN meeting so we can hear sort of an experience report from them.
John Curran: Excellent. Point taken. And so noted. A panel of small ISPs to talk about how we facilitate and/or abuse them. One of the small ISPs is coming -- no
David Huberman: David Huberman, Microsoft. Completely unrelated. Let's see. How much of the ARIN Board's here?
John Curran: We have -- we don't have Vint, but we have Bill, myself, Paul, Tim, Mr. Sandiford in back, and Mr. Aaron Hughes.
David Huberman: Great. So everybody but Vint. Cool.
John Curran: Yeah.
David Huberman: Yeah, he can't hear me anyway. Yeah, so the relying party agreement of RPKI, when are you guys going to fix this? It has directly affected the rollout of RPKI across the world.
John Curran: So if you look in the -- first, I don't know if people know, but our meeting minutes have become more complete, as of this year. The meeting minutes for the ARIN Board include the briefing materials.
If you go to the January meeting minutes, you will see the briefing materials I supplied to the Board on our potential RPKI agreement changes and on RSA changes.
Our present RSA does not directly reference Resource Certification services in the agreement.
I could point to it and say it says other services, and RSA and RPKI is another service, but given that we might want to rely very much on the RSA, if we do anything with RPKI's agreement, we need to make sure we have something that's very applicable.
The total package is recommending a new RSA where we're doing it anyway, a new RSA that's a little clearer.
And so this would be a -- we're very close on RSA and LRSA. We're within only the fee schedule. We would do a new RSA, which is actually an RSA and LRSA. Language would be the same. The only reference would be the fee table.
It would include a direct reference for resource certification in the list of services, in the second paragraph.
With that in place, it's conceivable that we could make a decision that we do -- we rely upon that indemnification; that everyone signs up to indemnify ARIN for when they get resources, we could rely on that indemnification and not also require every relying party to indemnify us.
This is a risk decision. So the Board talked about it. Myself, Steve Ryan, staff. We're doing a little bit of homework and cleanup on some issues.
We're coming back to the Board. It's actually on next month's agenda, and we're going to try again. But it's actively being worked. And you can read the briefing material.
David Huberman: Thank you very much.
John Curran: Any follow ups on that before we move to the next topic?
Okay. Back microphone.
Lee Howard: I think the Board should no longer have scheduled activities during lunchtime so that the Board could instead have lunch with the rest of the membership during meetings.
John Curran: I will make sure that we bring that up as a topic. I'm all for that.
At the next lunch we have -- the next lunch we have without anyone else at it we'll bring it up.
As it turns out, that's actually a great idea. And the only sensitivity is that the Board members have a huge workload right now. Board members have monthly calls for ARIN and now are at the meetings, and we probably end up having to add another day for our Board meetings if we didn't slip them into lunch and breakfast.
So I think it would be a great idea. I'm sensitive to the Board commitment. So the Board needs to talk about it. But you guys can tell me what you want to do.
Kevin Blumberg: Two things. One first is a question. Kevin Blumberg, The Wire ARIN AC, speaking on my behalf.
The question is in the past when ARIN has received back space, we've given it back to IANA to then distribute out to the other RIRs. Not all of it, but there's been some generosity within the ARIN community in that regard.
With ARIN now reaching end of days with IPv4 in terms of its free pool, will any returns be utilized first from unmet requests, or will ARIN be returning back to IANA to then have trickle effect down back in for requests?
John Curran: I actually know exactly what you're asking. It's a great question. I'm trying to remember if either our return plan or if the global return policy times out. I don't know offhand. I'd have to look. I don't expect we're sending more stuff back to the IANA, but I'll double check.
I believe one of them has an expiration in now that the IANA is taking that pool and issuing it out per the remaining IPv4 global policy. I don't think it's taking more in. I don't know if it was designed to do both at the same time. But I will double check.
I believe now that's no longer the case and all the collections that have gone to the IANA are there.
Kevin Blumberg: I'm sure that information will be useful to organizations who are looking to be altruistic within the region but not necessarily altruistic globally. Just as a suggestion.
John Curran: We will get that and get you an answer by tomorrow. I will double check the process.
David Conrad: Actually, I just wanted to reinforce what Lee had said, the next ARIN meeting have a panel with smaller ISPs, but I'd also like to request that the panel include folks who have maybe nontraditional requests, for example, CDN providers, anycast providers.
John Curran: Okay. Excellent.
And we'll get you the information you want.
Kevin Blumberg: In regards to Lee Howard's small ISP, I happen to be a small ISP. One thing to think about is that many of the issues that at least I am contemplating as a small ISP actually aren't for my own company but for all of the smaller end-customers who no longer can come to the small ISPs for their assignments and allocations.
So it's actually sort of a trickle down effect, and that group of people, those who don't even know there is an issue at this point.
John Curran: Excellent. Back microphone.
Mike Joseph: Mike Joseph, Google. I wanted to come up and discuss the out of region concept. So today we saw the policy -- while it got about two thirds of the vote, there were a number of folks who stood up in opposition who raised certain concerns. This is a policy that's been on the docket in some form or another for quite some time.
And seems to have gone back and forth not just in form but also in support.
At the previous PPM it was well supported, went to Recommended Draft Policy, and at this one we saw some more concerns brought up.
I'd like to -- I still think it's a sound policy, but if there are people who have concerns, I'd like to suggest that we use open mic, as we often do, to air general policy philosophy and thoughts.
So I'd like to understand if anyone here feels that out of region use is a good thing, if there's ideas that people have for what would be acceptable to them in terms of either this policy changing or some other policy.
But I'd really like to understand, because it seems like there's a lot of folks who support the concept, if not this particular incarnation, although the votes notwithstanding in favor of it, but I'd like to suggest to my colleagues that we certainly would be interested in hearing and hopefully the AC present would be interested in understanding what the community consensus is on this out of region policy.
Because I'd note we can't continue without something. Leaving this open to interpretation by staff has had unfortunate effects for both staff and community. So I think we need to do something. And I'd like to understand what everyone else thinks we should do.
John Curran: Noting we have other people in line, we'll take some time for this first.
On the topic of out of region use, if you would like to come up and speak on that and explain what you think we should do to solve this problem, which is not the policy we just discussed, because that's obviously -- you're asking for alternatives --
Mike Joseph: The policy gathered quite a bit of support, but there seems to be some concern. I would like to understand if other people have thoughts what they are.
John Curran: If other people have problems with this solution, come up to the mics.
Mike Joseph: Or if anyone thinks we shouldn't solve this. Because it seems like generally people feel we should do something. If they don't, I'd like to understand that.
John Curran: We had the discussion. I don't want to regroup the discussion. I just want to know does anyone want to speak that we don't have a problem to solve at all, does anyone want to speak that they have an alternative solution.
We don't have a solution that -- we had a discussion, but we've never had a discussion where people have jumped up and all agreed, yes, we need to move forward.
So if anyone has alternatives or thinks it's not a problem and wants to speak to that, now would be a time.
I note that we also know each other. If people have any other ideas, it would be find Joseph.
Marty, did you want to come speak to this?
Martin Hannigan: Marty Hannigan, Akamai Technologies. I honestly don't know what the problem is, to be honest. I've been using my resources all over the world for six odd years since I've been at Akamai.
I've been clear when I requested addresses from ARIN that where exactly I would use them. Initially when I got them. And, as you would imagine, I or some of us, use our address pools in a singular fashion where we just rotate through them.
If I have a requirement in France or in California, whatever number comes up next, with the exception of APNIC numbers, which we can talk about that at the bar, but I just use it. They're accepted. They're never rejected.
I can take any prefix in the world and assign it to another provider and give them an LOA, and a network operator takes them and routes them.
I can enter my ARIN prefixes into the RIPE DB to allow for European operators to build filters.
And the simple thing that I need to do, which I agreed to do at ARIN's request many years ago, was to simply tack up the anchor in the United States. Which I abide by. Which is pointless. But I do it because that's what I was asked to do. So I comply.
This proposal started out as a request from law enforcement, if everybody remembers, to help them to be able to better accomplish their goals with respect to due process.
They came to us and they said we can't find these people to serve them subpoenas, help us. And if you take a -- I ought to do this as an experiment. If you take version one and you take what we have today and you run it through DIF, there's almost nothing that is common.
And I think that that's a problem that the AC should consider discussing at their meetings and how to better serve the original intent of the needs that the different aspects of our community have.
And, by the way, I'm not saying that their proposal was valid or that it should have been passed in the manner that they asked for. But they did ask for it. And they actually stood up at the last meeting and said we really want you to do this or else.
And so let's get back on topic with respect to actual use. I don't see the problem.
And then the other kind of thought I had while the discussion went on was with respect to the comment related to government politics.
You can go to the RIPE region and become an LIR and get a /22. And as long as you have an element in the region, you can use those numbers anywhere in the world. And I don't think that the United States government is asking the RIPE NCC what they're doing.
I would suspect that no government would ask us either. I have a little bit of basis for that.
I'm not Steve Ryan. I didn't do the research he did. But when companies provide services in countries, typically a legal review happens, and we consider those issues what the impacts, the impacts to government and their considerations. And, in fact, going through one in the Caribbean, these happen all over the world and these are very common.
So I'm not quite clear why we need this. I guess I don't care. Thank you.
John Curran: Marty, one other thing. I don't know if it originated with law enforcement. That might have been one of the reasons. But they were definitely one of the early supporters of it.
I will say there was a Policy Experience Report where ARIN staff noted we are getting requests specifically with, quote, infrastructure in the US and customer entirely out of region.
By the way, we've been getting those since this policy has been in place for two years, and we've been satisfying them. So while they're inconvenient to validate, they haven't destroyed the organization.
Martin Hannigan: Sure. And I understand what their ultimate objective is. I think that there are some aspects of many governments that would like to see a China-like Internet where everything is completely controlled and trackable. I think that's an unrealistic goal, but I do support the goal of reliable due process to the extent it's possible.
I'll also note that I believe that the initial request was to ARIN as a corporation to do a better job -- and I'm paraphrasing -- to do a better job with respect to accuracy related to their billing data.
Basically how do I reach the people that are paying for these numbers. I don't think we need a policy for that, John. I think that -- and I will not be surprised tomorrow to learn that we have a few additional -- a few million additional dollars in the bank.
And I as a member of the Internet community -- and not speaking for Akamai with respect to cost, but I as a member of the Internet community would be willing to sacrifice a fee reduction to pay for the cost to make sure that the billing data is accurate and to satisfy a very minor need that the law enforcement people are asking us for.
So I think there's two issues here. They're very separate here because of the morphing of the proposal.
But those are my thoughts.
John Curran: There has been significant morphing.
Okay. David, did you want to reply to that?
David Conrad: Yeah, I think Milton --
John Curran: Do you want Milton or you to go first?
David Conrad: Go ahead, Milton.
Milton Mueller: Marty's talk was a perfect example of why we really need to deal with this. He gets up and he says: I can do everything this policy is trying to let me do. And the staff is telling us that they don't want you doing that. And lots of other people are telling us they don't want you doing that. And there are people in the room telling me they can't do that and they're trying to do that.
So what is it exactly that we want to accomplish here? I'm amazed at the degree to which maybe of the five people who got up and spoke against this policy, maybe four of them fundamentally agreed with the principle that the address space is a global resource; that RIRs do not exist to territorialize address allocation but in fact exist to facilitate distribution of addresses.
I think everybody agrees that companies that are fundamentally cited in a particular region should be able to get all of their global address needs from that region.
I don't understand why we can't work this out. I think if I'm going to make a concrete suggestion, as you asked and as Mike Joseph asked, for how we can move this forward, I think one obvious thing is to get the IPv4 scarcity issue out of the way by providing some very clear implementation date that gets us beyond the point at which people would be trying to abuse this policy to get IPv4 resources. I think that would be something we could do.
I also like the suggestion that Kevin made, which is that fundamentally we're talking about a global policy issue. And I would like to see a very general statement emerging as a global policy saying that RIRs are not there to fragment the address space but are in fact there to facilitate the distribution of addresses.
I would be willing to try a hand at drafting that policy, but that doesn't solve the immediate problem because of the length of time it would take to do a global policy.
I think something has to be done here and very quickly in addition to pushing for some kind of global statement of policy.
John Curran: If I ask -- Milton, if I can ask a question about the immediate policy -- the immediate problem. So you suggested an implementation date past the point where ARIN is doing allocations, when we're at runout effectively. And ARIN runout is an interesting thing because it's done in little slashes across -- it's really the first time we hit the waiting list and we can't satisfy someone. There may be a few other people who come in and get one or two, but we'll always have one odd shaped left for a while.
But at the point in time when we're no longer generally issuing space, I guess my question would be: If this policy is about making allocations and we're at the point where we're no longer doing it, the only effect of this policy is its indirect reference during transfers.
And I guess I would ask, as someone who has been looking at ARIN for years going forward, we're going to have an awful lot of transfers that go back and look at initial allocation and assignment policy when we're not making any allocations and assignments anymore.
Might it just be better to take the essence of that policy and put it in the transfer language than assignment language?
Milton Mueller: Good suggestion.
John Curran: It's really the indirect reference we're looking for. But however you want to do it.
David Conrad: David Conrad, ICANN, but speaking only for myself as always.
In a previous life -- to answer this specific question, in a previous life when I was attempting to obtain address space from ARIN, additional address space from ARIN, I had my request pushed back because it didn't meet the used space requirement because a portion of the address space that was allocated by ARIN was used outside of region.
This resulted in us having to redeploy some architecture, some infrastructure, move things around, to allow us to request additional address space from ARIN.
Whether or not that's an issue, that's for the community to decide.
The main driver that I saw for this policy was the fact that ARIN staff was faced with an unclear implementation situation. And the request was made in some far off, fine exotic place, that it would be really nice to clarify what the policy was with regards to out of region use.
We still, as far as I'm aware, have not come up with a resolution that addresses the staff requirement. Even though there have been patches and workarounds to address that, it's still not particularly clear.
Yet, in another different previous life, I did have some involvement with law enforcement interests on this particular policy. And the key I was able to drive interest that they had was they needed attribution, attributability, being able to try to use the available resources to locate the bad guys that are using the network resources.
The concern with the out of region stuff was it makes that particular task that much harder. And to simplify that, having a particular policy that would allow for attribution, you know, regardless of where the address space was in use, would probably meet their requirement.
And that goes to the interest in a global policy. And I find myself terrifyingly in agreement with Milton. So I'm going to sit down now.
John Curran: Okay. We have Sandra at the back first.
Sandra Murphy: This is not on that topic.
John Curran: Are you on the topic? Let's continue with David first. Thank you, Sandra.
David Farmer: David Farmer, University of Minnesota, ARIN AC. We spend a lot of money marketing the fact that the universe isn't going to end when we're out of v4. Can we in the room realize this? And, yes, there's issues going on with v4, but we shouldn't make horrible policy regarding v6 while we're fixing those problems.
John Curran: Back microphone.
Sandra Murphy: A refreshing change of topic. Sandy Murphy, Parsons. And, no, I don't speak for Parsons. Heavens.
I told David I was going to be talking about him. The question arose to my mind when David was speaking during the CRISP panel, I thought he was asking a question I was wondering about, and the answer didn't match. I mentioned this to a couple of colleagues, and they said bring it to the open mic. I think they were setting me up.
John Curran: We'll know in a minute.
Sandra Brown: It's about SLAs. We're going through a whole lot of work to create principles that will guide the eventual determination of an SLA with IANA. The presentation just now talked about IANA's SLA with the IETF.
Wes George at the NANOG meaning last October, talked about the absence of having a strong SLA with ARIN. And some of the RIR consultation messages said something about RADB and their SLA and being able -- so I'm considering. We're setting up these principles for an SLA for IANA, reciprocal, what's the SLAs that the RIRs over the world set for their members? Is there one?
If not, why are we asking for an SLA from IANA? If there is, is the SLA that we're asking from IANA going to be stronger? If so, why? Is it going to be weaker? If so, why? Et cetera.
John Curran: It's actually a very good question. In fact, it's more interesting than you might imagine. A lot of people like IANA. A lot of people -- IANA would have a lot of friends if it was in the room and it was a single person.
Naela Sarras: We are in the room. There's three of us here.
John Curran: Everyone would like to be able to know that they can tell Elise what to do. Now --
Naela Sarras: They've tried. They've tried.
John Curran: Now, as it turns out, that's actually pretty -- I guess it's -- the attention on IANA reflects the idea of people attempting to look at control issues.
So you have an SLA with IANA so that if IANA doesn't follow the directions that you expect, you can do something about it.
Then there's the other part of an SLA, which is: We sent you a request. Did you process it within a reasonable amount of time?
Interestingly, both of these concepts are commingled in the SLA discussion. Particularly when you go to the names community, their attraction to IANA is almost magnetic. It's amazing how close they'd like to be to knowing that their requests are processed in a timely manner in the way they wish.
The reality is that it's not about the service levels. The ICANN IANA team has done a great job serving the community. At least for the RIRs. We've said this. Shows up in the CRISP team that way.
So the attention to what you hear of an SLA for IANA is a proxy in many cases for what do we do if it doesn't follow our instructions, and that's not really a service level issue, it's a lot of people thinking about worst case control issues.
Now, regarding the RIRs, we also have the same -- we represent you. So we have both accountability and SLA issues. For accountability, the RIRs have built an accountability matrix that shows how we are all elected, how we do our boards, how we do our bylaws. That's on the NRO website.
The CRISP team proposal calls for an independent review of that, and it suggests that the NRO Number Council, which is friendly referred to as the ASO AC, be the one to do that review.
The RIRs right now are talking about that concept, because while the community suggested the NRO NC, we're not sure that's the best. The NRO NC, which acts as the ASO AC in ICANN, has two very clear missions: build global policy and appoint ICANN Board members.
We're not sure reviewing the RIRs is right. It might be better for an organization, like the CRISP team, or an independent auditor or someone to look at our accountability.
So we do believe the call to review the RIR accountability is a good one, and we're talking about it. I don't have an ARIN position on it, but I know we've talked about it several times this week. So you'll hear that shortly.
I do think the RIR accountability should be reviewed and reported back to the community to show that we're as strong as if you're worried about IANA accountability, you should worry about RIR accountability.
Regarding service level agreement, that's up to each of the RIRs because they're the ones who provide the services to their community and their members are the ones that pay the bill.
So if you had a group of people who could get together in each region and decide what services should be offered and what is included in those services and what's the timeliness and what's the priority of adding new services, kind of like a services working group, that would let you also work on what's the SLA level, how many nines are important.
Tomorrow we'll have a fee and services update. Part of that is discussion of a suggestion that went on on the Mailing List for an ARIN region services working group, which would be in the perfect position to work on SLA and propose that to the Board, et cetera, et cetera.
So you asked about SLA for IANA, and the accountability issues that are being proxied we are looking at and we have put accountability information online. For the services, each RIR has to decide how to set its service level. And in this region, I think if we can get enough people interested in a services working group, they're the best ones to propose what the SLA should be.
Sandra Murphy: I think the one answer is that an SLA does not currently exist for all RIRs.
John Curran: Like, for example, if you go to our annual report, which was just published online, you'll see we have a service level commitment. Mark works very hard to make sure we hit our service levels of availability. And it's published. But it was set by the management team, approved by the Board, and we report on it.
We could think about having more community ownership of that.
Sandra Murphy: Thank you.
John Curran: Thank you.
Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC, speaking on my own regarding some emails I sent back and forth with ARIN staff a couple weeks ago.
I'm going to pull the microphone out of here and turn around and look at the room and say: Who here knows what DNS OARC is? Can I see a show of hands? It's better than I thought it was.
I noticed recently that we're the only RIR that is not a member of DNS OARC. You may guess from their name they do some research and maybe software tools and development regarding the DNS. But, hey, wait, that's no big deal, right, because we don't do anything regarding DNS OA -- yeah, we do like half of it.
So I sent email to ARIN staff and said: I want to call this to your attention. This is an easy oversight. Because, frankly, I'm surprised so many people in the room know who they are. Because before I worked for a TLD operator, I didn't.
But I think it would be good if we were members of DNS OARC. And John told me, well, you know I'd be glad to take that to the Board as a suggestion, but I'd like to see some interest from the community. And, well, you know, I could send it in via ACSP or bring it up at open mic.
So if there are other people here who think that that might be a good thing to do, I'd appreciate hearing you from at the microphone or J.C. later or whatever.
John Curran: Let me suggest. So the Board members -- raise your hand, Board members. These are the Board members. If you like DNS OARC, you look at one, figure out the shortest vector to the shortest Board member, because we're going to break very shortly, okay? And all you need to do is get in front of these people.
Because ultimately the Board owns the fiduciary duty. That's at two levels. First, the money. The money is the money, depending on what level of support it is. The second is the mission. The IRS has these really interesting rules. If we send money to another organization, we have to be certain it is money that's supporting something compatible with our mission and in that line.
And it's actually -- it's probably one of the most important Board duties, is to make sure that money doesn't just slip out to support something that may not be in the mission.
So find a Board member, explain why it's important and why ARIN should be involved.
We get a lot of requests for support for organizations. I can't even -- two or three a month is what we get. And I filter some and some go to the Board.
But it really takes you folks finding Board members if you want us to financially support an organization, because the Board member you find has to sell the rest of the Board to make it happen. All for it. We have the funds. It's just is it in our mission and is it -- the Board has to weigh are they spending your money wisely.
I will tell you, they weigh that pretty heavily. We don't capriciously sign up, particularly for ongoing things, because once you join an organization, it turns out it's 10 times stickier than leaving an organization a lot of times. They like you to be there.
So find a Board member. Let them know you think it's important.
David Huberman: And don't forget, if you're going to encourage running to your local Board member, that John is also a Board member. So if you have ideas...
John Curran: That's also true. I also know where the exits are.
David Huberman: R.S., quick question. When we go to the DNS OARC Web page, there's a list on the right of the sponsors, those providing beneficial dollars. And it's a really big list of some really big companies, as well as the RIRs. Is there a funding issue there?
Rob Seastrom: None that I'm aware of.
David Huberman: Why are we giving them money? Why the ask?
Rob Seastrom: So I don't know if there is or isn't a funding issue. However, the money is not the only thing they get from their members. There's sometimes anonymized data. There's other things that come into OARC to support the research mission.
David Huberman: I guess I misunderstood the conversation. I thought we were talking about sponsorship.
Rob Seastrom: It's not just...
John Curran: David, did you want to respond?
David Conrad: I'm not associated with DNS OARC other than I believe ICANN is a member at some level. But in general DNS OARC is a neutral, non-biased party that addresses operational issues associated with a DNS and looks at various research topics associated with that operational aspects of the DNS.
And if you are involved, as pretty much every ISP probably needs to be, with operational DNS related matters, OARC is actually a very good venue in which to work with other folks who are looking at similar topics and find solutions to common problems, get early understanding of what some of those common problems might be or the ones that are about to bite you on the butt.
So I would encourage organizations, including ARIN, to look at seriously becoming a member of DNS OARC.
And, no, they did not pay me for this commercial.
John Curran: Thank you very much.
Okay. Microphones remain open. Any other topics?
Mike Joseph: Mike Joseph, Google. Actually, I just wanted to come up and thank everybody. We transitioned out of my previous topic, so I wanted to thank everyone for their contribution and discussion about that today.
And I'll just close on that topic with the concept that we, quite frankly -- and I can't emphasize this enough. We -- as ARIN members, we seek relief from unclear policy here. This is a real problem. Despite the fact that, like David, we generally get our resource requests approved today, we don't actually understand why.
And so we thank you for that, but this is a problem for our business. We have massive business interests in getting and maintaining our IP holdings. That's not going to stop with exhaustion. And we need clarification. And I suggest that probably others in the room do too.
John Curran: Remember, staff asks for it. We're the ones that put the Policy Experience Report out.
Mike Joseph: Well, the fact that you also want clarification is nice, but my bigger concern is that I need it.
John Curran: Right. I understand.
I support your position is what I'm saying.
Go ahead, Marty.
Martin Hannigan: I want to address Milton's comment with respect to he doesn't understand what the big deal is. I think Mike just explained what the big deal is on clear policy. This particular proposal has been in the queue for almost two years now, and I think there were five revisions or something to that effect, and then legal provides their opinion just recently.
When I said that I don't care, I don't care in one way, but with respect to the actual proposal, I do care. I do think it's unclear. And the reason why I'm not willing to just go along is because I -- again, I think Mike explained it; that there is quite a bit of unclear policy.
And Milton's comment with respect to his understanding that people have had different experiences than me with their out of region use is to my point that this is potentially not the proper language.
But to also his -- to the work that he's done on this, I think that -- and my role as the representative of Akamai, we're happy to work with him to come up with language that's suitable and hopefully crystal clear so that we don't have to worry that the use that we have now will be somehow impacted in the future, whether you're the CEO or someone else is or the staff changes or something.
John Curran: Seems worthwhile.
John Springer: John Springer, Inland Telephone, ARIN AC, speaking only for myself. I hope it's not a surprise to everyone in the room that from time to time we go around and around and around with policies, sometimes for years.
I recall an instance in 2009 where we did something like this with transfer policy. Eventually the Board identified threats to the organization, or what they believed were threats to the organization, and act to ameliorate -- acted to ameliorate those threats.
To the extent that counsel has identified any out of region use threats to the organization, if the community is unable to come to some sort of agreement here, at what point is the Board going to act to protect the organization?
John Curran: Actually, as someone aware of how the PDP functions there, if processing these requests that we're currently receiving for resources from parties whose demand is predominantly out of region and maybe based on infrastructure in the region, we've been processing these for the last two years, even after we said we're getting a lot of them; we're not sure they match what any of us anticipate.
So in and of it -- while it is unclear and while it is difficult to verify and while there may be fraud involved, does not endanger the organization. It's suboptimal in so many ways. But it does not endanger the organization.
So I don't see anything rising to the point of us suspending policy or initiating an emergency policy process. If that's the case, it's my job to bring it forth, and I haven't seen a need for that yet.
Maybe we need to change the PDP to reflect the new going forward model. Maybe we need to -- all policy proposals that add n lines need to remove at least n lines from the PDP. Maybe 2n, now that I think about it. Working towards simplification. I don't know.
But it is true. We have a lot of language in the PDP, and once we get to depletion, a lot of that language is only indirectly referenced.
I would hate to be someone coming, looking at NRPM two years from now, three years from now, and asking why they're being referred to assignment or allocation text.
Yes, NRPM, not PDP. Thank you.
Any other questions? I'm going to close the mics. I'm going to close the mics in 15 seconds. Last chance.
Ten, five, three, two, one.
Mics are closed. Thank you for the end of this open microphone session.
John Curran: I'd like to thank our sponsors today as we come to a close. Webpass. Our webcast sponsor, Google.
If you want more information about them, just go to Google.
And our refreshment break sponsors -- Fastmetrics, ServerHub, and IPv4 Market Group.
There's a meeting survey. You will find it if you have the application. You can get it or you can access it via the link. Watch for an email. We'll send it to you. And we'll work on how to improve these meetings.
We have reminders. Tomorrow we're going to start at 8:00 a.m. It's the Members Meeting. Everyone. It's a Members Meeting, but it's open to everyone. We call it Members Meeting because we handle the business of the organization.
Breakfast at 8:00. Meeting at 9:00 in here. Materials are online. You're on your own tonight. Thank you. I look forward to seeing everyone tomorrow.