Table of Contents
- Public Policy Meeting, Day 2 - Opening Announcements
- Number Resource Organization Activities Report
- Whois Accuracy and Public Safety
- Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM
- Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers
- Software Development Update
- ARIN Services Working Group Update
- Open Microphone
- Public Policy Meeting, Day 2 - Closing Announcements and Adjournment
Public Policy Meeting, Day 2 - Opening Announcements
John Curran: Okay. Good morning. If everyone will come in and be settled, we'll get started. I'm John Curran, President and CEO of ARIN. I'd like to welcome you back to ARIN 38.
We're going to finish our Public Policy Meeting this morning and then have an ARIN Members Meeting this afternoon.
I want to first start out with a welcome to our sponsors. Thank you for them, network sponsor AT&T and webcast sponsor, Google.
Okay. We have voting open right now. Our elections opened yesterday. If you're an eligible Voting Contact for an organization, you can vote via ARIN Online. Log in, click on the Vote Now link. If you have questions the election help desk is in the foyer. You can send an email to firstname.lastname@example.org. Please vote. Okay, emergency procedures. If there's an emergency, yeah, leave, and find exits and go out the door.
Rules and reminders. When we're discussing the policies we want to make sure everyone can be speak and be heard. Please be respectful of the courtesies in your program. If you've spoken on something, on a particular policy, wait until other people have had a chance to speak before jumping back up on the microphone. Please state your name and affiliation each time so people know who we're dealing with. Thank you.
Agenda. So today we have a fairly full day in terms of what we're doing. We have the NRO Activities Report this morning. We have a discussion we're going to have a little panel up here of Whois accuracy and public safety.
We'll have folks from the DEA, the FBI and the RCMP come up and talk about how they use Whois and help inform the community. Because we know how we use it for service providers, but sometimes we don't realize the other people depending on our activities.
We'll have a Software Development update. We have a microphone session. We'll have a Services Working Group update. We'll have a Registration Services and Engineering department reports, Advisory Council report, Financial report, Board of Trustees, and open microphone.
So that's the things we're doing today that aren't policy. We also have two policies we're going to be talking about. One is Recommended Draft Policy, which means it could be advanced to last call after this meeting. It's the Draft Policy 2016‑6: Eliminating the HD‑Ratio From NRPM. And then we have a Draft Policy that the AC wants input on regarding alternative simplified criteria for justifying IPv4 transfers. Both of those will be this morning right after the Public Safety panel.
So, at the head table I have Vint Cerf, our Vice Chair, and I have our Jabber scribe, Chris. Amazing. Someday a neurologist is going to tell me what's wrong with me. I can't recognize faces.
I'm going to start right in. First up is going to be the NRO EC Activities Report. I'll have Oscar come up and give that. Oscar is the Chair of the NRO.
Number Resource Organization Activities Report
Oscar Robles: Good morning, everybody. Thank you for being here so early after the social event yesterday. So I guess this is the slide changer. Okay. Good.
This is what I'm going to talk about this morning. It's about the NRO. First let me say what is the NRO. NRO is the organization that was created by the five RIRs 13 years ago now.
It is a live organization. It is not incorporated, but still it promotes the coordination among the RIRs, promote the multi‑stakeholder model, but also to promote joint activities between the RIRs to be the focal point when we talk about IANA services or IANA operations and all these discussions with the IANA transition.
As I was saying, it supports the RIR coordination. But also it contributes to the discussions related to Internet governance.
The NRO currently – it has a rotational executive council which is comprised of the five CEOs of the RIRs, and this year I am the Chairman of the executive council.
John Curran is the Secretary. Paul Wilson is the Treasurer. And Alan Barrett and Axel Pawlik are members of this executive committee.
We have a Secretariat. It is hosted by ARIN. And we do have an Executive Secretary which is German Valdez. And he's based in Brisbane, with agreement with the APNIC.
We have several teams, working groups and coordination groups, to do joint activities. Some of our activities are just coordination. Some of them are information sharing coordination groups. But others are related to actual work, mainly in the last months related with the Internet transition.
Those have to do with the communication areas of the RIRs, the engineering areas, the registration services areas.
We have also the Public Affairs Coordination Group, which is mainly for sharing information on the legal team.
The finances of the NRO are very simple. Most of our expenses are related to the payment that, to the contribution we do to ICANN, which is near the 823,000 US dollars. And starting this year, this fiscal year, that amount would include the services that we're paying for the IANA operation.
So it will be the same amount, and the IANA services will be included in that amount. And of course the IGF contribution and staff cost of our executive secretary. That's mainly our budget expenses.
And those expenses are shared proportionately based on the registration services revenue of each RIR. So it changes annually, the amount of money every RIR pays.
And last year we established this joint RIR stability fund.
The main intention of this fund was to try to have a commitment to support an RIR that may be in need of some financial help. And we were working to define the rules to use this fund and what would be the criteria, the conditions that should be followed for the use of this fund, to be used by the recipient of these funds but also by the five RIRs, whether it is going to be the CEOs or CFOs that should review the conditions for that, for the use of that fund.
You can see more information on this link here. One of the main activities that we conduct is a publication of quarterly reports on several topics.
Those related with our activities like the Internet Numbers Status Report, which is mainly statistics of IPv4, IPv6 allocation, ASNs. And we have also a quarterly dated – a policy report, which is a comparative analysis of the five different regional policies, which may help organizations trying to propose global policies or individual policies in every region.
Also we have published this relevant analysis which is the governance matrix which comprises a very complete set of information and bylaws in PDPs, audit information, financial information about the five RIRs which is very complete, and I encourage you to take a look into these documents.
This year also we finalized the RIR accountability – the joint RIR Independent Accountability Review which is an attempt to review our areas of opportunity on the accountability issues and how the RIRs are solving those areas. It was a study that lasted for 12 months. It started last year. And every RIR started this process by its own and defined what things should be corrected or should be fixed to deal with those weaknesses on transparency or some areas of capture, for example.
And our transition, well, we have talked a lot about transition, and this is not the last time I'm going to talk about transition. So these are some of the things related with the transition, some information about the whole process, in case you are missing something. But let me talk about what's been happening in the last month.
As you know, we defined the Service Level Agreement with ICANN for the IANA operations, and that Service Level Agreement is fully based and in compliance with the CRISP proposal. The CRISP proposal is a consolidated proposal among the five RIRs for these new services.
And we signed the final version in Helsinki last June. It is published already. It is operative now, starting the first of October with the conclusion of the contract between ICANN and the NTIA. So that's the trigger for the execution of this contract.
It's starting the first of October. This is the contractual document that regulates the operation of the IANA services to the Internet number community.
There's something else in the IANA transition that is running after the transition, which is the CCWG or the ICANN Accountability Work Stream 2. And that's the activities and the actions that has to be done after the transition.
We are working on that. And the appointed RIR staff and the Numbers Community members from every RIR are in this list – Izumi Okutani from APNIC, Athina Fragkouli from RIPE NCC, Fiona Asonga from AFRINIC, Jorge Villa from LACNIC and Michael Abejuela from ARIN as well.
As you know, a key element from our proposal for this new relationship with the IANA operator is the Review Committee, who should ensure that IANA numbering service operator maintains the service level defined in the SLA.
So this review committee, it's mainly from the community but it also has staff members and this is a composition of the 15 members – two from the community and one from staff representative. You can see more information in the links provided at the end of this slide.
Another piece of information related with the IANA transition are the intellectual property rights which is mainly domain names and trademarks related to IANA.
And the ICG proposal, which is the full community proposal for the IANA transition, establishes that the IPR, the intellectual property rights, should be transferred to a trustee, an entity that shouldn't be ICANN of course for these purposes.
And it was agreed that this trust should be the IETF trust and they are going to hold the IANA intellectual property rights. And there is this coordination group, the Community Coordination Group, which is composed by the three operational communities, the number communities, one of those three communities.
And the three representatives of the numbers community into the Community and Coordination Group for the intellectual property rights are myself as a chair of this, as the Co‑chair of this Community Coordination Group, John and Paul, because we are the NRO office holders this year. And that will be different next year as we have these rotational positions at the NRO Executive Council.
Last but not least, RIR Legal Team. We would like to thank the RIR Legal Team for the really hard work during all these months and almost 30 months that lasted the discussions on IANA transitions, the IANA Stewardship Transition reviewing documents, and working tirelessly for the completion of these document reviews and on time to go back to ICANN and other communities with our position.
So the members of that legal team are Ashok from AFRINIC, Craig Ng from APNIC, Michael Abejuela from ARIN, Eduardo Jimenez from LACNIC and Athina Fragkouli from RIPE NCC. Please help me to thank this group. Thank you for your work.
Finally, our participation in the IGF, this is our participation at the last year IGF. We're going to have the same participation this year in the IGF in Guadalajara. This is not only financial support, but also we try to address a different public with those topics that we feel that we need to make outreach, like IPv6 deployment, security stability and this kind of – things that probably are not of the knowledge of some of the attendance in these kind of events.
So we're going to be there and we're going to have a booth. And those that maybe participating in the IGF in Guadalajara, we'll see you around this meeting as well. That's my report.
John Curran: Any questions for Oscar on the NRO report?
John Curran: Next up we have something a little different, as I said. We're going to have a panel of some folks from law enforcement. I see them coming up. And this is Thomas Walden of the DEA, Bobby Flaim of the FBI and Jason Plomp of the Royal Canadian Mounted Police, the RCMP. And they're going to give you an update on Whois accuracy.
Whois Accuracy and Public Safety
Bobby Flaim: Good morning. And thank you to ARIN and the ARIN community for allowing us the ability to speak to you this morning. It's greatly appreciated, and we're hoping that we're going to be very beneficial in describing what our issue is. Because this is an issue that we feel is very symbiotic, and we want it to be an issue that is going to be of mutual interest to not only the public safety agencies, not just law enforcement agencies, public safety agencies, but also the ARIN community as well.
We know the ARIN community and network operators use the Whois. And there's a lot of people in the community, not just in ARIN but outside of ARIN, who view the Whois strictly as a network operator tool.
That was the original purpose. But back when it was created, the original purpose was the Internet was basically just for network operators. The public didn't use it. Consumers didn't use it. And most of all criminals didn't use it. And as the world has morphed, so have the uses of the Whois.
So we're hoping to describe to you today a little bit about how we as public safety agencies use it.
When I say public safety agencies, I'm not just referring to criminal investigators, such as the FBI, the DEA and RCMP, but also consumer protection agencies such as the Federal Trade Commission or also civil law enforcement agencies as well. Because it is an important tool in how we do attribution, and not only attribution for criminals but attribution to find victims and help victims as well.
So the point of this presentation, we're going to share it. You'll see a little moving of tables and chairs as we all come to the microphone. But basically the point of the presentation is to describe how we as public safety agencies use the Whois.
We also want to present to you what the current challenges are for public safety agencies and using the Whois – mostly attribution, being able to locate criminals with due process, legal process, because that is the most important part of this presentation.
We are looking to get to the closest downstream provider to the end‑user through legal process. I think that is something that is going to be stressed and you're going to hear a lot of that today.
The second thing – or the third thing you're going to hear is specific case examples. We have multiple case examples from the DEA and RCMP on how we use the Whois and why it is important to us and why the speed and accuracy of it is very important.
As you may or may not know, digital evidence is very fleeting, and there's no data retention laws. So there's no requisite or requirement to maintain that information.
So being able to get to that information as quickly as possible is very, very important.
And, lastly, and I guess the most important reason we're here and presenting to you, is so that we can work with the ARIN community to develop mutually beneficial policy on Whois so we can get to the granularity, specifically the reallocations to the downstream providers that will provide us with that accuracy.
We know that there's a lot of Whois policies that have been put forth before that are currently in place, but unfortunately it's still not, I think, achieving the desired results.
And what we're hoping is that through a new international globally coordinated policy that would get to that accuracy would be helpful to not only the public safety agencies, but also to the ARIN community as well.
So I just wanted to introduce the concepts to you, but I'm going to hand the microphone over to Tom Walden from the Drug Enforcement Administration. Thank you.
Thomas Walden: Good morning. As Bobby said, my name is Thomas Walden, supervisor and special agent for the Drug Enforcement Administration. And we're going to start off here with the use of Whois. Beyond the traditional RIR communities present here, Whois has numerous other public uses.
We realize the original creation of the Whois may not have been for these purposes. But much like the Internet itself, the evolution of Whois makes it a critical and viable resource beyond its original use.
The Whois directory, as you can see, ensures IP addresses are registered. We also have the security and reliability of the network, which is predicated upon the accuracy of the points of contact.
We also have these entities, as you see here, who – various entities who appreciate this information when they come in contact with issues regarding the misuse and abuse.
We as public safety groups, including law enforcement, rely heavily on Whois at the beginning of our investigations. And I want to stress that. It's just a beginning point for us.
And more importantly, we rely on it when we try to serve a legal process to – just to ensure that we're providing to the correct service provider.
Without data retention laws, speed is important because data may not be held and may become stale.
We look at the public safety uses of Whois. As I said earlier, it's one of the many tools that we utilize. Just a comment: It's the lowest common denominator, so it's the starting point for all of us. We also use the routing tables, commercially available tools, and then tools that we develop in and amongst ourselves.
When you look at Whois and you look at these types of investigations, we have senior level or, should I say, more experienced investigators along with our intel analysts that may use these more advanced tools, but our common everyday investigators tend to begin and end with Whois because it is the most commonly used resource that they have.
When you look at the issues at hand here, we have several. We want to start off with the sub‑allocations of these IP addresses and the impact that that has upon the timely responses for our judicial – our subpoenas and our judicial requirements.
We also – RIRs tend to have different policies and requirements for what information they retain regarding these sub-allocations. And that comes into effect because you end up wasting time when we serve these judicial requests to the wrong, or to an entity that was the original allocation as opposed to the sub-allocated entity. And we end up kind of chasing our own tail because we serve it to the one that comes up, but that may not be the end allocated area where we need to serve it to.
We have – the problem's expanding with that because of the IPv6, with more and more ISPs, we may never come back to the RIR from the initial – let me get myself together here.
The IPv6 is the first step, because the ISPs may never come back to the RIR for more space and they may not register the sub‑allocation. Following that up, we have the IETF MODERN, which is actually the shift to VoIP. And then we also have the Internet of Things with the increased number of IP addresses that are being given out. Assuming more devices being given IP addresses, that's something we're going to have to encounter.
We're seeking to work with ARIN and the other RIRs within the community to come to the best solution to this problem.
Now, we as public safety agencies, we need to stress that we don't want allocation information for the end‑user. And that's what we stated earlier. What we're looking for is only the downstream ISP closest to the customer, so we can serve the legal process to them.
And I can't stress that enough – that we only want that information. We don't want the actual allocated information for the end user.
When it comes to the additional challenges we have, we don't want to waste the network and ISP's time and resources by serving legal processes on the wrong providers. It takes time and effort from the operators. It takes time and effort away from our legal process and our legal request. And they shouldn't have to burden – shouldn't be burdened with either of those things.
The excess use of our limited resources also takes away from our investigations, which we could be working on by having to chase down these sub-allocated, trying to track down to the sub-allocated point.
And we have a couple of case examples here. The first one that I wanted to go over is one that Bobby had. It's for an FBI case. And in this instance, as you can see, a group was using inaccurate Whois information to conduct a spam campaign with millions of dollars in financial losses.
They would use inaccurate Whois data and outdated info to work with bad IP brokers and reroute IP addresses of defunct companies. Once sites were directed to them, they would create false layers of authorization from those defunct companies. Transferring the IP addresses to themselves, they would then use them for spam campaigns.
This was, I guess, started in July of 2013 and as you can see there it's kind of broken down.
With DEA, a lot of our investigations are active and ongoing. So what I did was I looked at some statistics. And when we looked at it we saw the time doesn't always amount to money. And I'm talking about time of the exigency of an investigation. Sometimes it equates to lives.
We looked at the past few months, some areas where there were numerous drug overdoses, and when we looked at these statistics, the numbers of people that had had these issues, we find that these public safety organizations – and that would be a lot of the investigators – they have to work as quickly as possible to establish a pattern of life for that individual to see who they were in contact with, so we can use that to track back to their source of supply.
And by doing that, we're trying to find the sources before they sell to someone else, and we're trying – so there won't be additional victims added to this person who brought this to the forefront or to our attention to begin with.
I'm going to hand it off now to Jason, who is going to give an overview of an RCMP investigation.
Jason Plomp: Thank you, Tom. As Bobby and Tom mentioned, I'm Jason Plomp with the Royal Canadian Mounted Police, the technological crime program in Ottawa.
I'll try to keep away from some of the Canadian stereotypes that have been brought up. I think somebody mentioned the use of the word "eh," so I'll try to stay away from that. Although I did go to a hockey game last night, so maybe some of the stereotypes are true.
Last week I was riding to work on my moose talking to my pet wolf.
And we were discussing the Spencer Decision. And the Spencer Decision from the – I think it was 11 Canadians that were in the room, that was the number yesterday, they'll probably understand what the Spencer Decision is.
In June 2016, the Supreme Court of Canada came down with a decision in the Spencer case. We call it Regina versus Spencer. It was a child pornography case where the law enforcement used an act that they probably shouldn't have. And they got the end‑user information. It went to court. The conviction stood up but the Supreme Court of Canada came back and said: You cannot get end‑user data without a judicial authorization, without a warrant.
So I think it's been stressed by Bobby and it's been stressed by Tom, that we're not looking for end‑user data, because as Canadian law enforcement, we can't get it anyway without a warrant.
So we're looking for the ISP closest to the subject that we're looking for. And the Spencer Decision, it's written out in stone for us from the Supreme Court of Canada that we can't get that information. And personally I don't want my information on an open Whois anyway.
So that's from a law enforcement person. And we don't want to – we're not looking to circumvent that process in any sort of way. We'll do the work. We'll write the production order to get that information as a result of the Spencer Decision. But we need to know what the law enforcement jurisdiction is to write that and who to send it to.
So the National Child Exploit – the National Child Exploitation Center, which sits in Ottawa, to date in 2016 has – this is to the end of September – has almost 20,000 referrals for Canadian IP addresses that are either – the vast majority of are either downloading or uploading child pornography. That's a huge problem.
So as the Child Exploitation Coordination Center gets these referrals, the first thing that they do is try to locate where that IP is so they can identify who the law enforcement jurisdiction is. Whether that be – it could be from St. John's, Newfoundland, the Newfoundland constabulary, or it could be in Victoria, the Victoria police, from the Atlantic Ocean to the Pacific Ocean, and all points in between.
So we need to know where that is so we can point the law enforcement jurisdiction in the right direction and say, this is a problem in your area, you have to deal with it.
And as a result of that, they will lay paper. They will come up with a production order to the ISP and say, look, these are the reasons set out, signed by a judge, and this is what we need. And that's the information that we need as the basis for subscriber information.
So that Whois check is the first step in any investigation usually that we do, so it's very important to us.
Whois is also used to search for victims. So in a recent case, we have 33,000 Canadian IP addresses affected by ransomware. That case is not going to go to RCMP, and we're not going to search for 33,000.
We'll send that off to our CIRC, which is called CCIRC, the Canadian Cyber Incident Response Centre, and they'll do that mitigation strategy between themselves and the banks, depending upon the case.
So the victim, finding victims is also as important as finding suspects in a lot of cases.
So to bring this down to kind of a level that we can all understand and perhaps all appreciate, in March of 2016, Canadian law enforcement had an investigation into a man extorting young female for nude and sexualized videos.
It took four production orders and three months to obtain the suspect's information, because the Whois database was not accurate.
The suballocations of those IP blocks was not in Whois. So we would go, for instance, to a large ISP for perhaps Rogers, Telus, Bell, go to them and they'd say, nope, that's not us. It was reallocated somewhere else. And then it was reallocated somewhere else.
So it took three months for law enforcement and four production orders to get what probably should have been one production order if the Whois database was up to date.
So the arrests came in June 2016. So that's three months where this person was – the young female was victimized for three months. And this person was free to victimize others.
So those are the types of events that we're trying to get rid of. We want to be able to find the jurisdiction, find the ISP and deal with these issues and deal with these investigations quickly and efficiently.
And we as law enforcement public safety, we have a duty to protect the citizens. But we really focus on the most vulnerable of our society. And that's children and that's the elderly.
So our policy proposal and the policy principles that we want to get into and hopefully we'll have something together by the spring of 2017, the policy principles require registration of all IP sub-allocations to downstream ISPs, so entire chain of sub-allocations are accurately reflected in the Whois.
And I think we've identified and told you how important this is, so that we're not wasting time and victims aren't being revictimized due to these time delays in our investigations.
So as I mentioned, as a result of Spencer, and the US has similar case law, we will not disclose end‑user information, but instead focus on downstream ISP providing connectivity to the end user.
Like I said, we're not looking for that basic subscriber information. We're looking for the ISP closest to the end user.
So this benefits the entire community. We're not the only ones that use the Whois database. It provides both public and private sector communities with effective incident response.
And ways to ensure adherence to policy requirements, we're looking at finding ways to come up with some sort of incentives. The carrot or the stick analogy.
We want to use the carrot as opposed to a stick and try to come up with some sort of incentives that help us keep the Whois database accurate.
So the way forward, it's a globally coordinated effort with the RIRs and Public Safety Organizations. So LACNIC and APNIC have both been done. The Costa Rican police and the DEA did a presentation in September of 2016. APNIC was done by the Sri Lankan police in October 2016. ARIN, we're here today with you. RIPE NCC, I think we have Greg Mounier on the line, who works at Europol. He's going to be doing his presentation next week in Spain with the Guardia Civil. It'll be done next week. They're going to be doing a similar presentation to RIPE NCC.
And AFRINIC will be done hopefully in December of 2016 with the Mauritius police and the African Union.
So this is not just us coming to ARIN. We're doing it across the five RIRs and trying to get that message out there.
So the goal is to introduce a unified policy proposal in the spring of 2017. The draft with the help of five RIR communities and submit at RIR meetings in spring of 2017.
We don't want to do this alone. We're looking for input from across the community and all the stakeholders within the community and to collaborate with ARIN and the other RIR communities for industry‑led solution. Bobby, I think you're up.
Thank you very much.
Bobby Flaim: Yes, we were just going to – I was going to conclude. Just to say that we want to, like Jason was saying, we want to work with the RIR community, especially you right here in the ARIN community, to develop a policy that would address some of the concerns that you heard today.
I think, from Tom and Jason, you heard good examples of how we use it, why we use it, and the current state of play and where we're trying to go. So we hope that presentation was very helpful, and we really hope that you can assist us in trying to move forward towards the spring of 2017.
So thank you on behalf of all of us, and absolutely, questions, and I see people are lining up.
So we have Alain.
Alain Durand: Alain Durand from ICANN. Speaking on my own behalf as usual. I have a question for you and maybe a suggestion.
The question is you've been talking about accuracy related to sub-delegation.
All across the RIRs there have been discussions when they are related to transfers, or more specifically to things that are not transferred because they are through private contracts or authorization.
My question to you is how much of a problem does this create for you?
John Curran: To try to paraphrase, if one party decides that they're not going to transfer the address block in the registry, but instead they're going to lease them the address space, so it still shows up in party A's name, but party B is actually routing it, is that problematic? That's not a transfer. It's not in Whois, but it's operational use of the address space. Wouldn't that also be a problem?
Bobby Flaim: All right. Sorry. Apologies. Any time it's an operational case and we're looking for that instant information regarding who to serve that legal process to and we can't get to it for whatever the reason is, then, yes, it's a problem.
Alain Durand: Thank you for clarification. And recommendation that I wanted to offer. For a long time I've participated also in IETF communities. And when you go to the IETF, there's a process to documents and you need to have some considerations, some security consideration, IANA consideration.
So the idea is why not have Whois accuracy consideration every time one of the RIRs look at policy?
John Curran: Make sure I understand. Right now we do a staff review, a staff and legal review which talks about whether we can implement the policy. You're asking for a security consideration as a result of the policy.
Alain Durand: Correct.
John Curran: That's certainly something the AC can decide to assess for each policy. Find AC members and talk to them. It's totally up to them what they decide to put in policy.
Alain: My suggestion is to make it as part of a process.
John Curran: Right, if they wish that, we're happy to make the change.
Cathy Aronson: Cathy Aronson. I've been working with Bobby and Iranga on this, and I just wanted to say we've had so many Whois accuracy policies that had nothing to do with Whois accuracy, and I'm so excited that you guys are actually presenting what you need this for, how do we solve the problem, and sort of getting the community involved, and anything I can do to help, super happy to help.
But it's great to have the problem defined in all the regions so that we don't have policies that don't actually solve your issues. So it's super cool.
John Curran: Far right microphone.
Peter Thimmesch: Peter Thimmesch with Addrex. I kind of wanted to give a historical review because one of the things I think we're missing here is there's really two Whoises with ARIN alone, and the RIRs are completely different. But ARIN inherited the Internet database in 1997.
In our review of the ARIN registrations from 1997 onward, we find it to be extremely accurate, very well managed, the points of contact are almost always in this room. You're going to have a high rate of accuracy in that version of the public Whois.
The 34,000 allocations that were given out between 1983 and 1997 are extremely low in accuracy. Most of them are never in this room. Their blocks are almost always in someone else's hands. They've been assumed by many things.
So part of the discussion may be trying to determine it's not this room.
This room does a great job – there's no one here I know that doesn't do a great job of managing their information. It's the people not in this room, that don't have an understanding of it, who received those number blocks so many years ago. And it also assumes to be there's almost two separate Whoises. I've talked to John about this a lot, there are completely separate rules for how they're managed.
So one of the things in this room is to try to find a way to assume and bring the inherited record in so that it will be – so it will be updated. And that's kind of what we want to make sure that we keep that in mind.
It's not the ones that ARIN has managed, it's the ones that came before it.
John Curran: Up front.
David Farmer: David Farmer, University of Minnesota, ARIN AC. For the panel, I've got a couple of questions. It's kind of like, what are your priorities and things for you to think about.
You talk about ISPs. There are lots of other kinds of network operators, like universities and all sorts of other things. So as you're thinking about how you want to deal with this, make sure you include those kind of other operators and what you want from them.
And then what the right – so you don't want residential customer information, but do you want enterprise network operation centers? Or do you only want the ISPs to service them. And then what kind of ones?
John Curran: May I answer that? Is the general term service provider more appropriate?
David Farmer: Possibly, or network operator.
John Curran: Right. We use those terms fairly interchangeably in this room. Which do you want them to use?
David Farmer: Well, I don't know which we want them to use. And I don't think I care. What I think is more important is whatever they use that they have a pretty reasonable definition of what they think they mean by it, and not leave it open to too much interpretation.
And then I thought I heard you wanting to know what jurisdiction IP addresses are used in. Is that correct?
John Curran: I didn't hear that.
Jason Plomp: We want to know what the jurisdiction is of the ISP. So for instance if the ISP is located in Toronto, that's what we would like to know. Not necessarily where the end‑user is. It's just where we can serve that due process, that production order to, and what law enforcement agency needs to do that.
So we don't need to know right off the bat where the basic subscriber is or where the –
David Farmer: You just want an accurate address for the provider in order to provide service to them.
Jason Plomp: Yes.
David Farmer: Okay. Thank you.
That will give you back to every time there's a change on everything. So just a suggestion there. I did appreciate the moose and wolf. In Toronto, I'm more of a raccoon‑and‑garbage guy myself.
But ISP, what David said a minute ago, is absolutely going to be the wrong word, especially in Canada.
TSP is about as close as we can get, the CRTC's definition of it. But even then that is wrong and stale dated.
There are many types of companies that offer services that don't define themselves as an Internet service provider. And if they don't define themselves, therefore they don't care.
So as we move in to the later years, I think the term ISP is becoming a generic term that doesn't necessarily mean what we think it means, and be very careful of that term. We need to – if you do want to do what you want to talk about, you want to expand on that definition.
John Curran: Do you have language you'd recommend for them?
Kevin Blumberg: No, like I said, in Canada, at least, the CRTC's definition – because it's very encompassing definition, far more than what the people in this room would consider an ISP. That's really the only suggestion there.
And the other thing is you mentioned CCIRC. They have an incredible ability to find us, far better than anybody I've seen. We get lots of notifications from them. And they've done a very good job.
Jason Plomp: Just to respond to that, I can absolutely appreciate that. CCIRC does that. But they're more on the mitigation side. And they fall under public safety; however, they're not an investigative body.
In order for us to use their vast resources – I mean there are other agencies in Canada that have eyes and ears other places as well, but from an investigational standpoint, the RCMP has to do those things. If we reach out to CCIRC, usually it's on mitigation side because the criminal investigation has fallen through.
Kevin Blumberg: What I'm saying is by CCIRC notifying us, they have the IP to ISP mapping which might be outside of just public records, but at least the mapping of the ISP to that IP.
John Curran: Jabber.
Chris Tacit: Thank you. I've got a couple of comments from Jason Schiller, Google, ASO AC. First is, "Question for John, resources under RSA are accurate because they need accurate billing contact. This acts as a yearly keep‑alive. What are your thoughts on a non‑monetary keep‑alive for resources not under RSA?"
And then I'll have another once you answer that.
John Curran: A non‑monetary keep‑alive. I'm not sure what that phrase refers to. So the challenge, of course, is a resource not under RSA. If we send them a reminder, to ask them do we POC validation, for example, and they don't respond, it's a keep‑alive, but it doesn't necessarily have any effect.
So I think we need a more concrete suggestion in order to evaluate that.
So, front mic. I'm going to close the queues. We have a policy track coming this morning and we're going to run right through it at this rate. Queues are closing.
Chris Tacit: I have one more Jabber comment also from Jason. "Also note that end users may have a direct assignment. So there might not be an upstream providing a delegation of the address."
John Curran: Right. Acknowledged. Okay, center.
Andrew Dul: Andrew Dul, CrowdStrike. I think the keys to success here are probably not using the terms "end user" and "ISP" at all. But instead probably finding language and terms that define exactly who needs to provide records and who does not need to provide records. So I think you were very clear in your commentary that we don't want residential end‑user records, but do you want corporate records for large or even small corporate reassignments?
Those could be valuable. Maybe you want them, maybe you don't. I don't know. But I think we should try to stay away from those terms that are probably undefined and used very differently in different regions.
I mean, the term LIR is used in the RIPE region to mean ISP. So we need to define what we want. I think probably in new terms, new language to get what we want.
John Curran: Okay, far –
Gary Campbell: Gary Campbell, government of Jamaica. Two quick questions. One, you intend to have this policy ready by spring 2017. Would that be the final policy or would it just be a draft? Secondly, for the five RIRs, is it that each would be developed in a specific policy or would you have one comprehensive policy?
And a spin‑off from that, is there a role for governments and academia in any of this?
John Curran: Why don't I jump in there? By definition each RIR establishes its own policy for how it operates its registry. We do have policies that are roughly coordinated, though, in the regions.
But each region develops its own. So it would be, even if a framework was introduced in all five RIRs, each RIR would take that to its own conclusion.
Regarding the role of government and academia, we welcome them in this policy process. If you want to participate in the policy development at ARIN, it's open to everyone, and we welcome governments to participate here.
ARIN has a Government Working Group, of course. It will be informed about this activity and may participate on the floor in its discussion.
Rear mic. That's you, Aaron.
Aaron Hughes: Aaron Hughes, ARIN Board. First of all, thank you very much for participating as a stakeholder for this community. Really appreciate you coming up and bringing this problem before us. It's going to be a great discussion.
My understanding based on your challenges and goals is we're really talking about the future, primarily related to v6 and subsequent allocations and motivation to keep data up to date.
I saw a question in there that said incentives. And I don't think you're going to have any challenges in the policy community on getting something passed. And at the end of the day whether that says may or must is probably not the relevant topic. More importantly, in my opinion, is how we're actually going to get people to execute.
My suggestion is that we spend some time doing some outreach with other monetary stakeholders that have the same challenges.
As a simple example, banks and credit card companies use IP information for geo information to help identify that you're not committing fraud and you're using that transaction in a specific location.
It might be useful to reach out to those communities to bring them in here, operational communities and RIR communities, to help incentivize operators to keep things up to date, not just to create policy.
So I don't have a large list off the top of my head, but I think a good place would be to start with looking at geolocation companies, find all the people that pay geolocation companies, find some real monetary incentive to back up a driver for the ISPs to keep that information up to date.
Bobby Flaim: I wanted to thank you for that because that is already a big issue. There are already existing Whois policies, and the problem has been the incentivization and enforcement part. So that's going to be a key component of how we not only have a policy but also make sure that it's effective.
So thank you for that, and that's a great suggestion.
John Curran: Far left mic, go ahead.
Joe Provo: Joe Provo, Google, AC candidate. A lot of discussion on access providers, LIR, ISP, however you want to call it. Can you touch on briefly, because we don't have a huge amount of time, the role, the jurisdiction of tunnels, brokered VPN providers and that might play in what you're concerned about?
Bobby Flaim: When you say tunnels, what specifically are you referring to, like Teredo tunnels?
Joe Provo: I didn't want to open up too much of a can of worms, but whether it's v6 tunnel brokers that happen to be in the US regardless where their end users are, whether it's folks who are – some of the folks who temp‑ – ephemeral use of addresses for potentially illegal things sometimes are done through leased GRE or IPsec VPN, so on and so forth.
Bobby Flaim: I think that's a huge challenge. And I think what we're trying to address here is really the most simple form of the inaccuracy because we realize there's a lot of proxy servers, there's a lot going on on the dark web. And that's such a huge and complex problem that we are just trying to go step‑by‑step. And this is the easiest step and that's a very loose term, obviously.
But it's the most direct and easiest step that we could work with the ARIN community on. What you're talking about is a little bit more sophisticated methods in going into other avenues, which are very necessary as well and we do acknowledge them, but that would require a lot more strategy, a lot more tactics with people even outside of this community.
So we acknowledge it. But I think for right now we're just trying to take baby steps, if you will, and this is one big baby step in that direction.
John Curran: Thank you. And final speaker at the mic is Counsel.
Steve Ryan: This is Steve Ryan. I'm not speaking for ARIN right now, but I thought we ought to thank the law enforcement agencies for taking this approach to us, which is a policy‑based approach through self‑governance, as opposed to another governmental approach, which is that they pass a law and tell you to do it and that there will be a fine if you don't do it.
So I think the opportunity for us is to work with a legitimate problem whenever we find it, whether that problem is raised by civil society people, who I think have actually an even greater stake in this, if you're a content owner, that that data be there because they don't have the resources of law enforcement to persist in finding the right person.
And so as we go forward, this is an opportunity, I think, for the community through self‑governance.
There is another opportunity which is we could get a law jammed down our throats. So we just, I think, have to think about that as we reflect on what the appropriate policy response is.
John Curran: Thank you. I'd like to thank all of our panelists.
Recommended Draft Policy ARIN‑2016‑6: Eliminate HD‑Ratio From NRPM
John Curran: We're now going to move into our morning policy block. The first one up is going to be 2016‑6, which is eliminating the HD‑Ratio from NRPM. I'll do the staff introduction, then we'll have David Farmer give the AC presentation.
So this policy started in July 2016 as ARIN Proposal 231.
The AC shepherds are Dave Farmer and Cathy Aronson. It has not been presented at a PPM or PPC. It was recommended by the AC for adoption in September.
And the text is in your Discussion Guide and online.
This policy removes all the remaining HD‑Ratio language from NRPM. It is intended for registration staff not to use the HD‑Ratio method for verifying IPv6 utilization or determining IPv6 block approvals.
It aligns with the current staff practice. We use Section 6 policies to determine IP initial qualification. But a default community network IPv6 requester clarification is end user with an option to subscribe to a registration services plan. The policy can be implemented as written.
We don't have a material legal issue with the policy. Implementation is minimal. It involves cycling the NRPM and updating our guidelines and procedures.
And now presentation by the AC. David Farmer.
David Farmer: So we'll get rolling here. So the problem statement. HD‑Ratios, still in the NRPM, and it really is anachronism. And it's creating some confusion.
It gives people the impression that they should be measuring themselves in 56s, /56s, and, well, policy has always allowed a /48 – getting a little of feedback there – policies have always allowed a /48 for any and all end sites without need for further justification.
You can use more restrictive choices like /56s, but you're not required to.
This proposal doesn't change any of that. It just hopes to get rid of some of this confusion by eliminating old text. The small problem is there's a piece of policy that actually still uses it, technically.
And that is community networks, Section 6.5.9. Solve that, we rewrite it and don't use HD‑Ratio and use the current end‑user policy as the guide for how to do that.
And this isn't going to – shouldn't cause a problem for anybody. If anything, the current end‑user policies are more liberal. This is the text for the community networks. It's in your guide here.
I just got it here in these slides so that we can refer to it if we need to during discussion. I'll just give you a little bit of time to look at it here. If you need to read the details, please look in your guide.
The guts beyond that writing is deleting a few of the no‑longer‑needed sections. There are two definitions. The definition of utilization regarding v6, and then the HD‑Ratio itself, and then a section about the HD‑Ratio that includes a very large table.
Repeating staff and legal assessments, basically there's no material issues. ARIN staff, it aligns with what ARIN staff is doing today. They don't currently use HD‑Ratio.
And it can be implemented quite easily. This summarizes some additional comments from staff, kind of what John was talking about, that an end‑user, that the default definition for community networks is end user. All end users can get a Registration Services Plan if they wish. And then frequently most community networks can probably apply as an ISP if they wish. The whole point of the community networks policy is to make it so they don't have to do that if they don't want to, but they can.
And so eliminating HD‑Ratio has been – seemed non-controversial. There's been no objections or concerns raised, and overall there seems to be community support.
The three policies that I've got listed down here at the bottom of the slide, rework of IPv6 allocations and/or assignments and a better IPv6 allocations for ISPs, are the work that has basically orphaned HD‑Ratio. So we no longer, with those policies we no longer depend on HD‑Ratio.
So this really started six years ago. We're finishing it up. The primary goal of this is to eliminate HD‑Ratio. Rewriting community networks is necessary to do that, but if we don't like that, we can delete it, too. However, there seems to be support for the rewrite.
So, time for discussion. Do you support eliminating HD‑Ratio? Do you support the rewritten text for community networks? And if anyone has any objections or concerns, get to a microphone. Thank you.
Paul Andersen: Good morning, everyone. You know the drill. Walk up to a microphone if you wish to comment. We have a Recommended Draft Policy. And we will shake it up – oh, we lost a microphone. Start over there on the far right microphone.
Bill Sandiford: Bill Sandiford, ARIN Board. I'm just speaking as myself but, partially as the Treasurer as well, too. With regards to HD‑Ratios and all that stuff I have no concerns.
But I have a little bit of a concern with the specific mentioning of fee structure in the NRPM, which I don't necessarily think we should be talking about fees in the NRPM.
I think as a member of the Board, happy to consider any feedback from the community. But would like to see this done in a way that doesn't specifically drive things towards fees in the NRPM.
Paul Andersen: Want to address that?
David Farmer: I think those comments in the policy refer to the original intent of the community networks policy, and unfortunately fees were intertwined with all of that. And I think that's a historical artifact. And I don't think I can just make it go away. But I don't think that's the primary point of this, though.
Bill Sandiford: Noting that I don't think it's the primary point, but I don't think treatment of these fees should be in the NRPM. We have fee schedules and other stuff like that that deal with that, and I think I'd like to see if we can get a way to get this done without specifically mentioning that.
Paul Andersen: I think the concern here, maybe it's the past Treasurer in me, you have text that suggests what the fee would be and it says here, shall be treated as end‑user assignment and both or unless the Board adopts a more favorable fee structure.
So it feels very much like a suggestion in NRPM. But, John?
John Curran: I guess the guidance to the AC is that to the extent that there is implied guidance for fees in the NRPM, the possibility exists that the Board would not ratify the policy even if sent. That's not assured either way. It could proceed anyway.
But to the extent that you want to have the highest chance of success, it would be best to put the fees in either the policy problem statement or the additional comments and not in the text that ends up verbatim in NRPM.
Paul Andersen: All addressed it appears. Front microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, and author of the proposal. It does not attempt to set fees or constrain fees in any way. It simply says that the fee structure that shall apply to these particular allocations shall be X, and throughout the NRPM we do that by virtue of declaring things either end‑user or ISP policy. And we have end user and ISP fee structures and have had for a long time.
And should the Board choose to eliminate the end user fee structure, they're certainly within their ability to do that without being constrained by this policy.
So I don't see that this is an inappropriate use of policy to constrain or set fees because it doesn't constrain or set fees in any real way. It just says as long as this fee structure exists, these particular allocations fit into this portion of it, and other allocations fit into other portions. And we define those in other places in the NRPM as well.
John Curran: To the extent that it says these shall be treated as end user, I agree with you.
To the extent it says these shall be treated as end user unless and until the Board adopts a particular fee schedule is not what – the same meaning. So if you want to identify that these are end user shall be treated as end user, that's fine.
But there is an actual language that says until such time as the Board adopts a more favorable fee schedule. And that means –
Owen DeLong: That's copied verbatim from the existing policy.
John Curran: Right. But the point is if we're going to change policy and it contains languages that reference fees, then the Board may consider that it's not something it wants to continue doing just because in the past it was done.
Paul Andersen: Did you have another comment, Owen?
Owen DeLong: I fully support the policy as written. If you need to strike that sentence to make the Board happy, I can live with it. But I personally think it's disingenuous.
Paul Andersen: Okay, front microphone.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. I have brought up that I was unhappy previously with the whole fee discussion inside the NRPM, which was ignored.
I actually have a bigger concern with this, which is to eliminate HD‑Ratio, we are changing the community networks fundamentally, not just dealing with HD‑Ratio. I support getting rid of HD‑Ratio.
I believe in Jamaica it came back, community networks have never been used. We are changing text for something that nobody, more than likely, will ever use, especially now with the changes in the fee schedule that allow smaller networks, that allow smaller blocks.
It is almost guaranteed the evisceration of this policy from ever being used. I have a policy proposal coming up that basically gives a much greater expansion of community networks.
I would be just as happy to dump that and dump community networks completely rather than have any of the confusion surrounding it.
So if this removal of the budgeting item is nontrivial or noneditorial, I would suggest to the AC that maybe the best option is to just dump community networks from this policy moving forward.
Paul Andersen: The editorial change would obviously be up to the AC itself.
Kevin Blumberg: If it was purely editorial, I'd be happy moving this forward and dealing with the bigger issue of community networks at a later date. If this is nontrivial, then I would revisit as part of this policy just getting rid of community networks.
David Farmer: In response to that, as I mentioned in the slides, we have another option. In fact, this option was discussed in the original policy. So here is an alternate policy statement basically deleting community networks and the other sections. And this slide was included so we could take this to last call if we so decided.
Paul Andersen: Wow. Stop the brakes here for a second. So we're discussing 2016‑6. We cannot bring an alternative policy statement – I haven't checked here, was this something that was circulated?
David Farmer: Yes.
Paul Andersen: Okay. So I would just ask that we just reverse. I'm happy if there's not support for this today and you wanted to discuss that and we can discuss that in open mic if necessary and all that. We can't discuss it in this policy block.
David Farmer: It's in the comment section for this policy originally from the proposer.
Paul Andersen: I understand. But the policy text, I'll let you two choose.
John Curran: To the extent you're going to ask for feedback from the community on this policy proposal, then you need to make that a very clean single question on this policy proposal. We don't entertain multiple policy proposals and/or/ifs because then people don't know when they show support, is it with this statement or the alternative statement, or both.
So very clear with the AC. If you have an alternative, break it off, make it a separate proposal and then you'll see how each one gets viewed independently.
Paul Andersen: I would suggest let's continue with the original text for that. First of all, we haven't yet determined if there's not support, though. Let's finish off with this one. We'll have the poll. If after the poll, if it is negative and you want them during the open policy – I'm sorry, open mic section – we can certainly address the alternate policy. That's no problem.
Kevin Blumberg: To the recommended policy before us, I support the concept. I would support the text as written if the removal was editorial and you could move forward. Otherwise I believe that something else is what is needed and then go from there.
Paul Andersen: Okay. We have a remote participation.
Chris Tacit: Thank you, Mr. Chair. I have a lengthier statement here from Jason Schiller, Google, ASO AC.
"I'm all for removing the HD‑Ratio language and making things more understandable, but removing Section 6.7 and 2.8, remove language that discusses utilization, is based on the number of /56s or /48s assigned to each downstream customer end site.
I think that the following text needs to be retained somewhere: '6.7. This utilization refers to the allocation of /56s to end sites and not the utilization of those /56s within those end sites.
It is an address allocation utilization ratio and not an address assignment utilization ratio.' End of quote. And 2.8, quote –"
Paul Andersen: Chris, sorry to interrupt, would you mind refreshing. I think a bunch of people were turning as you said that. Did you say retain Section 18.104.22.168?
Chris Tacit: Yes, somewhere. And then he –
Paul Andersen: Am I missing that there's a 22.214.171.124?
John Curran: No, 6.7 and 2.8.
Paul Andersen: Ah, and 2.8. Thank you.
Owen DeLong: Both of which actually are not operative anywhere else in the NRPM.
Paul Andersen: I apologize. 6.7 and 2.8.
Chris Tacit: So continuing, "And 2.8: 'Quote and IPv6 utilization is only measured in terms of the bits to the left of the /56 boundary.
In other words, utilization refers to the assignment of /56s to end sites and not the number of addresses assigned within individual /56s at those end sites,' end of quote.
We should certainly clarify that you can choose to assign /48 or /56 to customer end sites, but if you use /48 you get to call the /48 100 percent in use. And if you use /56 you only get to call the /56 bracket, not the /48 100 percent in use.
I'm comfortable allowing community networks to qualify under end‑user policy."
Paul Andersen: Thank you, Chris.
Did you want to make any comments on that?
David Farmer: If Owen – defer to Owen on that.
Paul Andersen: Owen first. Go ahead. Do you want to address Jason's comment?
Owen DeLong: I both wanted to – I actually want to address two things. I'll address Jason's thing first.
The definition in the remaining v6 policies after we eliminate or modify the community networks policy of provider allocation units actually covers everything that he says should be retained and it uses a completely different set of criteria for defining that.
So the sections that he's saying we should somehow retain actually become complete no‑ops and are not referenced by any existing policy.
So I don't think there's actually any need to retain them. I looked at that pretty carefully before proposing deleting them.
This really is an effort to clean up a number of dangling things that we should have cleaned up when we wrote the other policies. I'm as much at fault on that as anybody else. So I'll take the hits there.
I also stand corrected. The fee structure language is not copied from the existing policy. And I erred in putting that in.
Paul Andersen: Okay.
Owen DeLong: It is what it is. Hopefully we can make the change later, but we'll see what we end up with.
Paul Andersen: I encourage, Jason, if you have concerns regarding that to maybe talk with the shepherds and the author offline, because obviously you want to get that addressed. But sounds like there's some – did you have a comment?
John Curran: Owen, just for my reference, where do you believe that the allocation size and counting it as utilized is in the Section 6 policy?
Owen DeLong: If you look under the definition of Provider Allocation Unit in the – I'm not sure if it's in Section 6 or Section 2.
John Curran: Okay, got it, provider allocations. Yeah, you may be right on that. It may be sufficient – it's not the same language, but it may be sufficient to cover.
Owen DeLong: No, it's actually completely different language, and since the provider allocation unit is the definition used in all of the existing new policy that we passed six years ago, the old language in 2.8 and 6.7 is not actually utilized by any of the existing policy other than the community networks by virtue of the HD‑Ratio.
John Curran: So Provider Assignment Unit – sorry. I just want to double‑check. So Provider Assignment Unit 2.1.5, would, as long as it's read, for purposes of determining utilization, you get the same effect.
Owen DeLong: Well, and specifically in Section 6, it says that the way that utilization is determined is provider – based on Provider Allocation Unit, so yes.
John Curran: I concur that we can probably live without the 56 language in the HD‑Ratio section given that it's in Provider Allocation Unit.
Paul Andersen: Before the next speaker we are getting to around that time that I need to ask if you are going to speak on this policy that you either start typing so that Chris can forward your comments into the room or that you start making motion up to the mic, otherwise the mics will be closed at the end of this next comment.
Scott Leibrand: Scott Leibrand, ARIN AC, DLVR. There are two definitions in Section 2. In 2.8 we have the definition of the word utilization. In 2.16 we have the definition of the word utilized. It's very strange to define the verb and the noun of the same word differently. But we've done so.
So this proposal seeks to remove one of the two redundant and no longer used definitions, leaving only a single definition of the noun form of – the verb form of utilized, which is the one that is currently referenced.
So I think that's an improvement. I also wanted to comment on the fee schedule item.
As I read it, the problematic part of that sentence is the last part that we've already talked about that says that – I can't read it now, but the part about the fees and the Board adopting a more lenient thing in – I think the last half of that sentence, after the comma, could be removed as editorial change.
So that would be my position as an AC member. So I think the community should consider that I and probably a lot of other AC members have taken their feedback, that that's probably something we ought to do and something we'll try to do as editorial. And evaluate this proposal on its overall merits with the assumption that we'll probably end up fixing that and give us your feedback on the overall proposal, not on anything that can be fixed as an editorial thing.
Paul Andersen: Thank you. The only thing I'd like to add is keeping fees out of the NRPM is important because the Board could still change fees if it feels or requires we review the fees all the time to make sure that they have the best fit in recovering fees as equitably as possible.
But I hate us to run into the situation where the NRPM said one thing and fee schedule said other and then I just feel for the poor staff that have to explain we know the policy text says this, but it's trumped by that. Sorry, no pun intended.
The microphones are now closed unless you had any ending comment. Remote participation that squeezed in.
Chris Tacit: Yup, final comments from Jason Schiller, Google. He said he was concerned about end users but I think it's also covered in Section 126.96.36.199, so he withdraws his concern.
Paul Andersen: Thank you. Let's thank David Farmer for the presentation.
We're pretty much right on time for a break but first we must do a little bit of business. I know it was a lovely social yesterday. But need you to do a stretch break. I see the counter is in position.
The question is going to be the usual. On Recommended Draft Policy 2016‑6, those that are in favor of the AC advancing this policy, please raise your hand nice and high. You may lower your hands. Those that are opposed to advancing this policy, please raise your hand nice and high.
Okay. Those that did not raise their hand can now not lower it. We'll wait just a second for the online tabulation and the tally.
I just assumed the time was going to – sorry. I lied. No break for you guys. But at the break, that would be a great time to find David or Owen, and if you had suggestions on text and such, to have comments. And, of course, we do have the open mic after the break.
John Curran: We'll have a break but it's just after one more policy proposal.
Paul Andersen: And the envelope, please. On the matter of 2016‑6, Eliminate HD‑Ratio from NRPM, in the room and remote, 129. In favor, 18; against, nil.
Thank you very much. We'll pass that on and John will introduce the next proposal.
John Curran: So in this case there's no staff introduction because this is still a work in progress. But I'd like to have David Huberman come up and talk about a Draft Policy that the AC is working on. And this is Draft Policy 2016‑3, alternative simplified criteria for justifying small IPv4 transfers.
Draft Policy ARIN‑2016‑3: Alternative simplified criteria for justifying small IPv4 transfers
David Huberman: Good morning. 2016‑3 is a very straightforward policy proposal. It says keep all the existing Section 4 text. Allow 8.3 and 8.4 transfer requesters to avail themselves of that text. Or, you can double your IPv4 holdings up to a /16, as long as you're using 80 percent of all the v4 address space you have in aggregate.
I looked at the numbers of all of the published transfers on the ARIN website for 8.4 and 8.3. 97 percent of all the transfers that have been completed and published are a /16 or less.
Therefore, if you wish to make a request of an 8.3 and 8.4, you could use this to double your holding.
So there are three prongs in the Policy Development Process. Is a policy technically sound? Is it fair? Does it have community consensus? This does exclude a portion of the community from using this policy and there have been concerns raised in the past about whether or not that's fair.
And most importantly, do you prefer this policy over the three discussions we had yesterday?
Paul Andersen: Again, just a reminder, this is a Draft Policy. So it's not as far in the process as the other ones. So this will, if advanced at some point, will come back to discussion. But we are happy to have a discussion on the questions that David has asked.
So please approach a microphone. They really need you to approach on a policy like this because they're looking for good input. Front microphone.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. David, what about new entrants in regards to this policy, because you said this really is not necessarily fair and impartial to the big guys?
But at the same time this policy is also just as – doesn't help a new entrant because they have no holdings to double.
David Huberman: We have a policy proposal that's reached a consensus here that looks like it's moving nicely in the PDP that allows new entrants to the sea of spades.
Kevin Blumberg: Much smaller, much, much smaller blocks, though.
David Huberman: That's an orthogonal issue.
Kevin Blumberg: Right, as far as this policy is concerned, I really will not be able to come up with a determination until all of the other recommended policies the AC disposes of in the next, hopefully 60 days. My gut feeling is that this effectively removes needs for, as you said, 97 percent, and in fact that number will be much higher because in fact why not just use /16 and keep going back for the /16s every month, rather than having to do full justifications of larger blocks? If you're using them you can just literally bring into your pool every time you need it a /16.
David Huberman: You can only double. You can only double your holding. As soon as you have /16 total aggregate holdings, this policy doesn't apply.
Kevin Blumberg: Thank you.
Paul Andersen: Rear microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I support the policy as written. I think this is a much better alternative than the others. The others seek to open the floodgates without any sort of control or restriction.
I think transfers larger than a /16 are by and large done by fairly big organizations that have people on staff that deal with ARIN and other RIRs on a regular basis and they're pretty familiar with the policy and know how to navigate it. So I don't think this imposes a significant burden.
I do think that opening the floodgates without restriction is a very, very risky move to take at this point, and that this is a very reasonable step that covers 97 percent of what has been happening and simplifies for the vast majority of organizations and transfers being conducted. So I think it's a very good current step and a much better alternative. Thank you.
Paul Andersen: Thank you. Front microphone.
Alain Durand: Alain Durand, ICANN, speaking on my own behalf again. You mentioned the statistics that 97 percent of a transfer went to blocks to a /16 or longer. Does this include companies that receive multiple /16s?
David Huberman: So ARIN publishes each block that has been moved. And we can see that the vast majority of IP addresses transferred in 8.3 and 8.4 are small block of /16 or smaller.
Alain Durand: I agree. I've seen those statistics, but those statistics do not show the recipient of the addresses. So it's impossible to see just by looking at these particular statistics, if for example, ten blocks, ten /16s went to the same place.
So my question is have you integrated that aspect into your statistic? Or are you only looking at a page that says it's a /16 and maybe there was a company that is going to put a stupid number – 50, 100 /16s.
David Huberman: No, I only looked at the more simplistic view, mostly colored by my own experiences that show the vast majority of transfers are what we would call small in its time.
So I wasn't questioning the underlying data and some of that nuance because I already believed the context of the statistic be true.
Alain Durand: I have seen anecdotal evidence that large numbers of /16s have been transferred, meaning the old class Bs, some legacy space, and sometimes they end up in the same account.
Paul Andersen: Thank you. If you're going to comment, I'd ask you to approach the mic, because I do see a bunch of people and we have remote comments, so I want to make sure we time manage it accordingly.
Go to the tube first, Chris.
Chris Tacit: So Jason Schiller, Google, ASO AC, says, "The policy was intended to allow an organization holding more than a /16 to get a 16, use their space to 80 percent, and get another /16. He would like people to talk in support of the /16 cap. Is that the right size? If not, what size do you recommend?
I don't want to have a discussion of what the right cap is in the spring."
Paul Andersen: Thank you, Jason. Front microphone.
Milton Mueller: Milton Mueller, Georgia Tech. I think I'm in favor of this. But I'm questioning, based on reading the text, whether it really is limited to small guys and not big guys.
My understanding, just reading the text, not the intent, is that you can say, okay, I'm Google, I've got tons of address resources, I've got 80 percent utilization. And now I qualify for doubling up to a /16. So why could they not get a /16, simply as that? That's the limit of what they would get based on 80 percent utilization.
If that's not what you intended, you might want to adjust your wording. But as it looks to me now, the wording does not prevent a larger operator from showing 80 percent utilization and getting a /16.
Dan Alexander: That's noted. Take it under consideration.
Paul Andersen: What was your intent putting aside the policy?
David Huberman: My understanding as Shepherd, understanding as Shepherd, was as I described. This cap at a /16 and it was – Scott, do you have –
Scott Leibrand: Scott Leibrand, co‑author of the policy. There's a note at the bottom of the policy, says notes on interaction with existing IPv4 policy, organizations requiring a transfer larger than /16 may either transfer a /16 at a time and recertify 80 percent utilization before receiving each new /16, or continue to qualify under NRPM 4.2 or 4.3 which allows an organization to qualify for a 24‑month supply of IPv4 space via transfer.
The thinking here is if you're right on the cusp, and all you really need is 16 at a time, you might avail yourself of this policy. If you're a large organization, you're more likely to be able to get the space that's the proper size that you actually need by using the 24‑month supply.
But it is an "or," so it's up to the organization to decide which of these two is more appropriate to get the space that they need.
Paul Andersen: Thank you for clarifying the intent. We'll take the text back. Any suggestions for Milton or others to clarify are welcomed obviously.
Milton Mueller: My impression from what Scott just said is it really doesn't exclude bigger players. It limits the size of what can be transferred.
Paul Andersen: That's what we understood. My rear microphone disappeared. Okay. Front microphone.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I support this policy – I support this policy over 2016‑5 for a number of technical reasons.
One, it includes the "or" clause so that while part of the goal here is to – part of the goal of some is to eliminate the Section 4 criteria, but there are a number of special cases that have been built into the Section 4 criteria over the last decade or so that we may not actually want to eliminate.
And this retains those for those hopefully relatively rare cases when we need them. But they could still be needed.
Paul Andersen: Rear microphone next, but at the end of this comment we will be closing the microphones. So if you wish to comment, please start typing or approach a microphone. Rear microphone, please.
Gary Giesen: Gary Giesen, AC candidate, CentriLogic. I think I support this proposal in principle. I just wonder if – let me just clarify the intent was anyone who is at the /16 threshold can still apply for up to a /16 using the – just the 80 percent utilization criteria of their existing blocks? I'm not sure if that would necessarily totally achieve the intent of this policy.
I think perhaps anyone that's at that threshold should have to demonstrate 24‑month supply even for blocks, additional blocks more than a /16. But in general, I think I support this policy.
Paul Andersen: Thank you. The microphones are now closed. I'd ask the remaining participants to limit their comment to one minute or less. Front microphone.
Andrew Dul: Andrew Dul, CrowdStrike. I support the ‑5 that we discussed yesterday over this policy. There are some good ideas here. But I'd support the more broad approach that applies to all organizations, not just small‑ to mid‑sized organizations.
Paul Andersen: Thank you. Next comment.
Patrick Gilmore: Patrick Gilmore, Markley Group, Board candidate. Can you go to the next slide? I notice nobody answered the question, is this fair and impartial. Real quickly, fair is such a weird thing. It's clearly not fair under some because you have two different things.
But I think it's fine. Throughout our entire society, we frequently do things differently for different classes of people.
I think it's perfectly fine. And I would call it fair in my mind. I understand that there are other people that wouldn't.
So as a community member I'm going to answer this question and say this is fine. To answer Jason's question, from the Jabber server, I think that /16 is a good size. That is clearly a judgment call. And I certainly wouldn't argue if we did /17 or /15 or something like that.
I don't think – I think we could all agree that /8 is not the right place to put it and I think we can all agree that /32 is not the right place. I think /16 is probably good, but, again, judgment call, and I don't have all the data that ARIN has. So maybe looking at where these things fit and where the 95th percentile or something of transfers would be a good place to put it, I'm not sure.
Hope I didn't go over a minute. Sorry.
Paul Andersen: You were good. Thank you very much. And our other speaker seems to have disappeared. David, did you want to add anything? Sorry, anything on the remote? Thank David for the presentation.
Paul Andersen: So as my pollers get armed and into position, this is a Draft Policy, not a Recommended Draft Policy. So the question is – yes, it's slightly different. So the question is, I'll just state it first: Do you believe that this problem is something the AC should continue to work on?
Don't get too fussed by the text. That's something you can send changes in on the Mailing List and such, but giving an idea if this is a problem that should be still going on. We'll ask for those in favor and those against once I see my pollers in position.
All right. Those in favor of the question, please raise your hand nice and high. This is the last time at this meeting you're going to have to do this. So try and get a good turnout here. You can hear my voice, you can put your hand up at the appropriate time.
Thank you, you may lower. And those that are opposed to the question, please raise your hand nice and high. Thank you, you may lower your hands. So while we're waiting for that, do you want to go over the break since I know we're a little bit behind?
John Curran: Sure. Get the break slides up. There are no slides. So when we're done with this, you folks get to have a break. We're starting the break a little late. Supposed to start at 10:30 but instead we're starting at approximately 10:45.
You were to be back in here after break at 11. And so the question is to the degree of sadism, let's be back at 11:15. If folks can be back at 11:15.
Paul Andersen: To send us to break, on the question 2016‑3, 122 in the room. In favor, 27; against, one. Thank you, everybody. We'll provide that.
John Curran: You're on break, I'll see you at 11:15 back in here.
(Break at 10:49 AM)
John Curran: Okay. We'll get started again. We're done with our policy block. And now we're going to get a Software Development Update from Nate Davis.
Software Development Update
Nate Davis: Good morning still. I'm here, I'm Nate Davis, Chief Operating Officer for ARIN. I'm going to give the Software Development Update.
I guess one question comes up is why Nate Davis giving this, not Mark Kosters or perhaps Andy Newton?
It turns out that one of the roles I play is actually I'm a product owner for our Agile development process. And most of the external customer‑facing applications, I'm actually responsible for prioritizing and setting delivery dates on those.
So, hence, I'm here to sort of present what those updates look like and to receive direct feedback from any of you that have feedback to provide me regarding the process.
All right. So the topics I'm going to cover today are projects completed since the last ARIN meeting. Some of the things that it looks like we're going to be working on in the next six months or so. Actually got added to this presentation, when compared to the prior ones I've given at ARIN meetings. I'm actually going to give an update on the ARIN Suggestion and Consultation Process and some of the activities there.
I'll talk about what are the things that really influence the things that we work on from a software development perspective, and then lastly just review with all of you what the strategic guidance is regarding our software or development activities that we've been provided by the Board.
So what we've worked on recently since the last ARIN meeting is improving some voter contact management. This is the ability not only for ARIN staff but also the community to better manage their voting contact information so that we can reach you through mailings, so that you're able to vote. And as a reminder please vote now in the open election.
We've also deployed SWIP‑EZ. SWIP‑EZ, if you recall or if you don't know, is actually a solution for being able to capture reassignment information. And it's for organizations that maybe, perhaps are not large enough to have an IT department to do scripting to do that through our APIs, but still have a fair number of SWIPs, and therefore don't necessarily have an easy way or they're not necessarily – there's not necessarily an easy way to capture that information outside of scripting or programming.
So SWIP‑EZ was implemented to allow organizations that have a fair number of SWIPs to enter into the system to do that but not necessarily programmatically.
Since the depletion of IPv4, we've actually increased our transfer work, as everybody realizes.
We spent the last six months completing automation of our 8.4 transfers. Many of you may have already seen that automation, if you've gone into ARIN Online and submitted transfer requests for 8.4s.
The functionality allows us to better manage transfers subject to 8.4 policy throughout the organization in a much better manner.
And then lastly we moved to a new office facility about two or three miles away from our prior location.
So some of the forthcoming initiatives that we'll be working on. Again, we'll continue working on our voting contact management, enabling the staff as well as you to manage voter information.
We'll also do some work on Web accessibility. We have some improvements that can be made both on our website, static site, and within ARIN Online. And we'll start to work those within ARIN Online.
Our goal is WCAG level A or level AA compliance on many of those pages. So I just wanted to mention that as sort of our goal. But we'll be doing that work.
Next we'll also be looking at opening up the result sets from queries, from RDAP. Right now, if you submit a query, you're limited to 255 responses. Through our OAuth server that we'll be implementing you'll actually be able to receive an unlimited number of responses back to that.
One of the things that John and I have been pressing hard on Engineering to do in the last few years and consistent with Board guidance is for the Organization, for the Engineering Organization to deliver customer‑suggested improvements and things that also come in through ACSPs or various other avenues.
And the Engineering Team has been doing a great job on delivering on that in the past few years.
But that's come at the expense that we have now some infrastructure that we need to upgrade. So we're going to be stepping back a little bit on some of our customer‑facing improvements – not necessarily in total, but just a little bit – and actually implementing some infrastructure improvements.
As an example, our development servers are actually no longer supported because we're working on older versions of software there.
With regards to the ACSPs. Since within the past two years we've completed 19 ACSPs. And, of course, ACSPs, the ARIN Consultation Suggestion Process, is where you, the community, actually submits to ARIN non‑policy improvements to anything related to ARIN or its processes.
And those can be small in scope, sometimes a day or two to implement, to large in scope, which is – there still exists on the list of open things that we're still considering to implement.
So we have completed 19 of those within the past two calendar years. Presently we have 26 open. And of those 22 require engineering work.
And just as I said earlier, some of them are small in scope. Some of them are much larger. A couple of them often are very heavy as far as the lift and require a lot of work.
We have three that are tied to the Internet Routing Registry project that I wanted to mention. And then to give you an idea of some of those that provide heavy lift in addition to the IRR work is also access restrictions for APIs.
So there's a suggestion out there to actually provide better access control restrictions through APIs as one of the services we offer through REST.
So what are the things that influence our projects? This is a laundry list, if you will, of some of the things that influence how we determine project priorities. We sort of mix it together in priority soup and then kind of pick it out as we can based on a number of influences.
And the least of those is not the strategic guidance from the Board as well.
So we continue – the Board has indicated to us, ARIN staff, to continue to review and enhance ARIN Online, including making significant user interface improvements per feedback.
Automated ARIN Online functions that support the Policy Development Process, so from time to time we have policies that actually require some type of automation. Many of you have seen those in staff assessments. We'll indicate in a staff assessment whether or not automation or engineering is required.
And then lastly we continue to focus on community‑suggested, customer‑facing, high‑impact items that really benefit the community. And that's it. Any questions?
John Curran: Any questions for Nate on the Software Update?
Kevin Blumberg: Kevin Blumberg. Nate, I'm really happy to be able to get up here and say thank you for all the work you're doing. It's quite a difference when five years ago there was frustration. There's no frustration today.
I only have one question. In regards to the number of outages that are service impacting, specifically in regards to the RESTful API, does ARIN have a run‑back to be able to keep those types of services up in sort of a 5 9's scenario? Because designing a system to do live API calls is very easy. Doing something that then does a store and forward because of continual outages is significantly – part of the development process for the other side.
Nate Davis: That's an excellent question. I see Mark Kosters creeping behind you in a very Donald Trump/Hillary Clinton kind of way.
Mark, do you want to take that one?
Mark Kosters: I'm Mark Kosters, and let me have just a few words about my very, very good friend here from The Wire.
Mark Kosters: So, seriously, ARIN has this one issue and a lot of times when we do software updates we have to do some database work. And that is, right now when we do the database work we need to bring down all the applications.
That's something that we are trying to move beyond. We're not there yet, where we can continue to do sort of incremental sort of update across the fleet, but we're not there yet.
So this is something that we're looking forward to doing. But it's going to take some time.
Nate Davis: Thank you, Mark.
Any other questions? Wonderful. Thank you, everybody.
John Curran: Thank you, Nate.
John Curran: Oh, wow, we're catching up. Can't have that happen. So queue up ARIN Services Working Group update. I'll do those slides now. This is preemptive, trying to give you a better time after lunch.
ARIN Services Working Group Update
John Curran: Very briefly, as Nate noted, one of the things that feeds the queue for development is the suggestion process. One of the things that feeds the suggestion process actually is now the ARIN Services Working Group. And the reason for this is because some of the things that we want to embark on are not a single suggestion or a single good idea that someone says in the hall or submits, but it's sort of directionally more important to get right.
And I want to make sure – the suggestion process is basically something that ends with me. I evaluate those, work with staff and then we take that and we add that into our work queue. Using ARIN Consult we tell you what we intend to do.
But it occurred to me that some of the things that have been suggested are more labor‑intensive. And I want to make sure that I vet them sort of off a sounding board before we go out to ARIN Consult.
So we formed the ARIN Services Working Group this year. It assists the President in considering changes to ARIN services, a standing committee to facilitate discussion within the community and developing recommendations.
So right now we have Aaron Hughes, who chairs it. Paul Andersen, Martin Hannigan, David Huberman, Sean Kennedy, Dmitry, and Matt are all members of the working group. We just started getting going.
Three things, I just want to give you an update on what I have them working on. The three things we're working on is CKN‑23, contact unknown. We gave a presentation in the past about this.
But as people may know, if you have a very old registration at ARIN and you haven't touched it in a long time and it's legacy error, it's quite possible now when you look at the database the Admin and Tech Contact say "no contact known." And the person who was associated with it is listed as the Abuse Contact.
We did that to avoid hijacking and I had Leslie Nobile do a great study on our accuracy and whether or not that was the right approach, whether we wanted to in fact put those contacts back on as Admin and Tech.
And I'm working through the Services Working Group now to come up with a recommendation which will then go out to ARIN Consult for consideration.
The other thing is the ARIN Services Document. We had a couple times last year someone said we should have a statement of the services ARIN provides. We're working on that right now.
And the third one is an Internet Routing Registry roadmap. Many times we have people say, "ARIN should do something with its IRR." And "do something," depending on who I talk to and what day, is completely revamp it and do something completely original, or completely replicate what another IRR has done, or don't do anything – push it off a cliff and let's not spend money on IRR. I can guess what I want to do, but I don't really want to do that.
So I have the Services Working Group talking to a lot of people, trying to come up with a plan that makes sense before I tell Mark to go off and code things.
Each one of these, when we have a recommendation, that will happen probably early next year for most of these, we'll throw it out on ARIN consult so people can talk about it.
But I wanted to let you know it's not just something I came up with. I'm using these folks as a sounding board to develop something rational before it gets in front of you.
You should be – if you're interested in what's going to be going on, you should be on the ARIN Consult Mailing List, because that's how we run the consultation processes.
So feel free to jump on the mailing list server and do it. Questions?
John Curran: Okay. Having finished that, I will now go into open mic. So this is again the same as we did yesterday. Open for any topics that may be up, policy issues that didn't get discussed. Any questions about ARIN.
We will have one more of these briefly at the end of the day, but we do one now because we have a little time before lunch. I see someone approaching the mic. Lovely. Yes.
Suzanne Woolf: I'm Suzanne Woolf. I actually have an observation I wasn't sure where to put but wanted to say to the room.
We get a little discouraged sometimes about the deployment of v6 and the advancement of the Internet generally. But folks who follow infrastructure might have noticed yesterday that all of the root name servers now have IPv6 addresses in production.
John Curran: Very nice.
Suzanne Woolf: And there's two things that are cool about that.
One is you won't see a press release. It's just the infrastructure people doing what needs to be done.
But also when we get a little discouraged about the rate of deployment, people only add those kinds of services and make those commitments when the quality is there to provide transit and redundancy and all the things you need.
So it's a good sign for the deployment of v6.
John Curran: Very good. Thank you. Okay. Rear microphone.
Gary Giesen: Gary Giesen, CentriLogic, AC candidate. I'm wondering the community's thoughts on ARIN putting some development resources towards developing an IPAM product, IP address management.
I don't think the open source community has – most of the tools out there aren't great and they're very hard to set up and use. And I think this is particularly impacting smaller users who can't necessarily afford the commercial tools.
I think it will help with things like Whois accuracy. It will help – it's probably not the only thing holding v6 deployment back, but it will help there. So I'm just curious if the community would support such an initiative.
John Curran: People want to comment on that, approach the mics.
I'll say historically we have had an approach of trying to make sure that the RESTful interfaces that are necessary for such a tool or any other commercial IPAM, we want to make sure we have all the interfaces.
You'll see every now and then we roll out new functionality, but we don't yet have the RESTful interface.
So we're trying to catch up with that. But the question of going beyond making just the RESTful interfaces available and actually doing some sort of open source or ARIN‑branded IPAM would really need guidance from the community.
Owen DeLong: Owen DeLong, ARIN AC. I don't think ARIN should develop an IPAM or any other open source software that's sort of more generic than ARIN's direct mission.
I think that there are organizations such as the Internet Software Consortium that are much better places to do things like that.
John Curran: Okay. Any other comments on this? I see Kevin.
Kevin Blumberg: Kevin Blumberg. I'll actually agree with Owen on this. But more importantly, a nuance to it, I believe that ARIN having a good set of bootstrap examples for their implementation, very simple bootstrap examples so that other organizations can look at them, would definitely help significantly and be almost part of the documentation.
I do note on the website, the last time I looked, about four months ago, there was only one company that was listed as having full support for the RESTful API in their IPAM software.
I don't know if that's changed. If it hasn't changed, that's not great on that industry, unfortunately.
John Curran: Okay, got it. Noting that having some simple examples would help. As also noted here. I'll try to work on that one. Center front on the same topic.
David Farmer: David Farmer, University of Minnesota, ARIN AC. While I completely agree that I don't want to see ARIN take on the whole thing of developing an IPAM, maybe you could find some way to fund some of the other projects or to get them moving along, particularly with an eye on having a reference implementation, an open source reference implementation of something that's using the RESTful APIs there and provides the catch.
John Curran: If you know of someone doing an open source IPAM who might be in a position to do that, send them to me.
David Farmer: I will look around. See what I can come up with.
John Curran: I can water the ground and sprinkle fertilizer, but without a seed, nothing will happen. Actually something will, but it will be all sorts of other growth.
Same topic, back microphone.
Gary Giesen: Gary Giesen, CentriLogic, ARIC AC candidate. Actually, I completely agree with Dave. ARIN doesn't necessarily have to own it long term. But if they could provide seed funding or bootstrap something, that would be very useful.
John Curran: Center rear mic, same topic.
John O'Brien: John O'Brien, University of Pennsylvania. Just adding some color to this conversation. In our environment, we certainly have unmet IPAM software needs, but they're focused mainly on our internal infrastructure, not in our interface upwards to ARIN.
So what I would hope for is that any development efforts in this area would be mindful of augmenting sort of enterprise‑level IPAMs rather than being ARIN‑specific.
John Curran: Got it. Helpful. Okay. Any other comments on that or any other topics? Open mic. I'm going to close them shortly. If you want to come up and talk about anything else. No? We'll have one more at the end of the day.
I'm closing the mics. Three, two, one. Open microphones are closed. We'll now move into the end of the Public Policy Meeting.
Public Policy Meeting, Day 2 ‑ Closing Announcements and Adjournment
John Curran: We're going to lunch now. Lunch table topics. We have some out there. If you want to talk about these drafts, there's tables for those.
A table on how Inter‑RIR transfers are working in general. Security. Take your valuables with you as before. Come back, we're going to have a Members Meeting this afternoon. We have reports from all of the departments, and then an open mic and then we're done for the day.
So everyone head forth to lunch. We're going to resume in here after lunch with the Members Meeting called to order promptly at – I guess I can give you – yeah, I'll be a little generous, at 1:05. We'll start at 1:05. Okay. Thank you.
Paul Andersen: Not 1:00, 1:05.
John Curran: Yep.
(Adjournment at 11:45 AM)