ARIN 47 Public Policy Meeting, Day 1 Transcript - Monday, 12 April 2021
Public Policy Meeting, Day 1 - Opening Announcements and Format Overview
John Curran: Good morning. If everyone will get ready, we’ll get started in just a moment.
I’m John Curran, President and CEO of ARIN. I’d like to welcome you all to ARIN 47, our virtualized mode.
Okay. As people realize, we’re not having a face-to-face meeting. So, this is the next best thing. We’ve had a number of very successful virtual meetings, and I expect ARIN 47 will be the same way.
I have some brief introductory remarks. And then I’d like to introduce our keynote speaker. Next slide.
Our Board of Trustees is in attendance: Paul Andersen, our Chair; Nancy Carter; myself; Peter Harrison; Catherine Middleton; Tina Morris; and Bill Sandiford, our Vice Chair.
Our Advisory Council that shepherds the policies through the Policy Development Process is present, will help us handle the discussions of policy the next three days.
Next, our NRO Number Council. The NRO Number Council, also known as the ARIN – it’s – sorry, the ASO AC, the Address Supporting Organization Address Council.
And each of the RIRs elect three members to the NRO Number Council, and our three members are Kevin Blumberg, Martin Hannigan, and Louie Lee. They work on global policies. They also handle the interface with ICANN in terms of our responsibilities for doing things with our agreement with ICANN, such as helping elect the ICANN Board of Directors.
Next. You have the platform in front of you. This is our Zoom meeting platform that we’ve used very successfully. I want to say a few quick remarks on how to use it. Many of you are familiar with it because we all seem to have Zoom meetings in the modern age, but it’s a little different when we use it in conference mode.
So, first, there’s a chat. For those of you who want to chat with one another, this is the best we can do for hallway conversations during the meeting. And if you click “Chat,” you can bring up a window and chat with the panelists or the attendees. So, that’s a useful feature.
Next – make sure it’s all panelists, of course, if you want to talk about panelists.
Next, keep your remarks on topic, professional. You’re still subject to ARIN’s Standards of Behavior when you’re in the chat window.
Next. There’s a Q&A. When we get to the Q&A portion of the presentations, you can use the Q&A section.
Next. You click there. You enter your questions. It will be picked up. If you want to speak live, you can raise your hand, and you will be recognized.
We maintain queues as we always do. You’ll have a chance to directly pose your question. Not all the sessions have direct interactive options, but if we do, you’ll click “Raise Hand” to get in queue.
Okay. Go ahead. Next slide. I want to remind everyone that the Board of Trustees Chair, Paul Andersen, will moderate the discussion of the draft policies, making sure everyone can be heard. If you have any comments, any questions, please feel free to ask them.
If you do speak, please state your name and affiliation. That includes if you ask a question. We want to make sure we understand who it is that’s asking questions. And affiliations – we know you’re not necessarily speaking on behalf of an organization, but it helps for identification. So, please, name and affiliation when you submit questions via the Q&A.
The Standards of Behavior are in the Discussion Guide and online. I will note that this is a professional meeting, and we have things to get done. Everyone’s entitled to a receptive environment, and the Standards of Behavior help enforce that.
If there’s issues, feel free to reach out to myself or Paul Andersen. We’re happy to address any concerns with anyone violating the Standards of Behavior.
Next slide. Attendees, we have 114 registered attendees from the United States. We have 14 from Canada, 27 from outside the ARIN region, 7 in the Caribbean region.
Next. We are recording and live streaming this. There are people watching it live. And it will be online afterwards. So, keep your remarks appropriate. The slides will be made available. Transcripts of the session will be made available.
As usual, because we’re making transcripts, I ask that people speak clearly, enunciate your words. Put some pauses in. Something I’m not known for, but I’m trying.
And the materials, the presentations are online right now at ARIN.net/ARIN47_materials. The transcripts and the recordings will follow later.
Next. Newcomers. We had a newcomer attendee session the other day, and they met with representatives of the Board, the AC, and the ARIN staff. They learned about ARIN. And we’re drawing a gift card for those who attended.
And the winner is –
Remote Host: The winner is Danielle Carroll.
John Curran: We’re going to email you that gift card.
Remote Host: Congratulations, Danielle.
John Curran: Next. I’d like to now thank our Bronze Sponsor, Team Cymru. They’ll be providing our keynote speaker. Team Cymru is a wonderful organization.
Next. Our agenda. As I said, we’re going to have a presentation. Our keynote speech is going to be up next. That’s David Monnier from Team Cymru, “A Day in Internet Miscreancy: Why Security Policy and Practice Matter.”
Later on, after that, we’ll have a break. Actually, before the break, we’ll have a Premier Support Update. We’ll have a presentation on IRR, RPKI, and password security. We’ll do a Registration Services update. We’ll have a Policy Implementation and Experience Report. We’ll talk about how the policies have fared, how staff pull out select things and handle that. Then we’ll have the Advisory Council report on their activities and their open policy docket.
There’s going to be a break, and in the break we’re going to have Erin doing another stretching session. Those have been well received. And we have trivia coming up in one of the breaks.
So, with that, I’d like to move ahead.
Next. The other thing we have in the afternoon is a number of policies. We have Adopted Policy 2020-2. This has been adopted; we’re reporting back to the community on it.
Draft Policy ARIN-2020-6: Allowance for IP Allocation Swap Transactions. Recommended Draft Policy, ARIN-2020-7: gTLD Micro-allocation Clarification.
As I note, Recommended Draft Policies are policies that might actually be adopted after this meeting. So you need to pay particular attention if you need to put comments in or give insight to the people working on them.
We also have Recommended Draft Policy ARIN-2020-8: Clarify and Update 126.96.36.199 Annual Renewal Fee.
And then, as usual, at the end of the day, we do an Open Microphone available for any questions from people from the community on any matter, including a clarification of things that have come before.
So, next, I’m now going to introduce our keynote speaker, Dave Monnier, Team Cymru, a Keynote Speech - “A Day in Internet Miscreancy: Why Security Policy and Practice Matter.” Over to Dave.
Keynote Speech - A Day in Internet Miscreancy: Why Security Policy and Practice Matter
Dave Monnier: Good morning, everyone. I’m Dave Monnier, Team Cymru Fellow at Team Cymru. It’s an honor to be able to present to you today as a keynote for ARIN.
ARIN is an important organization to the safety, structure, and future of the Internet. And today what I want to show you is some of the things that happen on the Internet on a given day – I just selected a random one – and hopefully it will highlight why security policy and practice matters.
So, first, who is Team Cymru? Well, we’re a company that’s set out with the mission to save and improve human lives. Our founders were looking at what ways we could contribute, benefit to society as a whole and looked at the Internet as a powerful tool – in fact, as powerful as a printing press or our ability to control fire, things like that.
But we looked at the Internet as a thing of its own and something that should be looked after for the sake of the Internet itself, so as opposed to perhaps the specific network owners or the specific users or things like that.
But kind of looking out for it in its entirety for the purpose of ensuring that it’s available for man.
We did this, what we started by doing was to understand how miscreants would misuse and abuse the Internet. We tried to understand how they would be monetizing it, how they would be turning it into a weapon, how they could be turning it into ways to steal information and so on.
And we started that by initially looking almost solely at botnets. This is going back 10-plus years ago. That was kind of the biggest scourge, if you will, on the Internet and still is a major part.
But what we did was by collecting malware. These days we collect something like 400,000 pieces of malware in the course of a day.
But we look at that malware. We detonate it. And we look to see what does it talk to out on the Internet and who’s controlling it and things like that. And then we take that information and work with the ISPs and IXPs, NSPs, trans providers and so on.
We work with those folks who make the Internet happen to understand what traffic they should be blocking and to understand how they can maximize the monetization of their network links.
And in return for that, we’re allowed to take a look at kind of what miscreancy looks like in the world as a whole. With that information we then feed it into more than 130 CCERT teams around the world to help people do something about it, if you will, so, to go out and remediate those threats.
Now, in addition to that, we’re also a function company that provides threat intelligence as a commercial product into many of the security products that you know of in the marketplace that you’ve seen.
A lot of our intelligence is in those tools. So perhaps your firewall will be updated by rules tonight – with rules tonight by the vendor that you get it from.
But there’s a good chance that our insight is what is going into that update as we’ve tracked bad things happening, we update that information and share that with our vendor partners. And then those partners then deliver that into products.
So in addition to that, we also provide intelligence services, largely attributive, investigative intelligence services for companies around the world.
With that kind of view, we end up seeing just about 40 percent chance or so of us seeing the activity of a specific actor online.
So, now, we’re not alone in having this fondness for the Internet. As many of you here today know, the Internet is an incredibly powerful, powerful tool, and it may be why some of you have even chosen this career path.
But when you look at the Internet as a whole and you look at its impact in society, there are people who recognize it as an amazing tool that routes information from one person to another, or from one organization to another.
Perhaps one of those people is a doctor who’s getting additional input and help from other doctors around the world while they’re working on a problem.
Or perhaps some of the detail being shared on the Internet is investment information where people are able to do research and understand how new products are coming to the marketplace or new services are coming and how to invest in those things and help, perhaps even to bring those services to their part of the world, and how to work together and how to collaborate on things.
The Internet also is obviously a lot of fun. There are people using it to play games. There are people using it to keep in touch with family, share photos, all of those types of things as well.
But the Internet as a whole is this large collection of various good uses. But in addition to those good uses, there’s also quite a bit of bad that goes on. And for that reason, I think probably one of my favorite Internet quotes here about the Internet is one from Paul Vixie where he simply states: “The Internet is not for sissies.”
And while Paul is likely referring to someone’s feelings or whatnot while they’re chatting about it, what hopefully I’m going to be able to show you today is it also can be somewhat of a dangerous place and something we need to keep that in mind as we make use of that.
So, let’s take a close look at occurrences and activities on the Internet on just a random day. For the sake of this presentation today, the random day that I selected was the 23rd of March, just a few weeks ago, 2021. And I wanted to highlight and show you all of the things that we were able to see happen on the Internet on that day.
So, for starters, on that day, the SolarWinds Hack was in the news. I’m sure you all saw that information when it was in the press. The hack was effectively a supply chain attack. There were – someone had gained access to the SolarWinds company infrastructure, had found a way to attack and insert malware into a supply chain.
And when all the people in the world had their Orion instances updated, they incorporated this malicious bit of code that allowed a remote actor to gain access to it.
This was a big story. It was attributed back to the Russian Federation, believed to be actors from there, operating on behalf of the government there. And it was a big deal.
Also on that day there was a fresh detail about a Microsoft Exchange hack that was happening. It was believed to involve 30,000 or so Exchange servers that had been attacked by a zero-day vulnerability on the Internet that were Internet-facing Exchange servers. If you’re not familiar with Microsoft Exchange, it’s the mail server system written by Microsoft.
And this was also really big – this was a big deal as well. And in this case it was attributed back to likely Chinese actors. Again, supposedly acting on behalf of the country there, on behalf of the government’s interests.
But those two specific key details, while exciting and while very, very intriguing, in particular, as you look at them as they tie together the ideas of nation state actors and criminal activities, those are really exciting things.
But they were just some of the small things actually happening on the Internet that day. And there is actually kind of a constant background miscreancy happening on the Internet 24 hours a day, seven days a week.
What seems to be happening is, in the most part, many of us are becoming somewhat immune and unresponsive and unreceptive to kind of the overall stuff that’s happening on the Internet, and instead we seem to find ourselves largely responding only to those things that are a really big deal in these types of news articles are helping to feed that.
But let’s take a look at what was happening in addition to those two events that were in the news that day.
Well, on that day, we at Team Cymru, our global sensor network, we have a collection of honeypots and darknets, sinkholes, things like that that are designed to sit and listen on the Internet and try to attract some type of malicious behavior so we can understand how people are misusing the Internet and so on.
Those sensors picked up 27.6 million events that were related to compromised devices on that day. Of those 27.6 million events, they were representative of 191 countries. Keep in mind, there are only 195 total countries.
So we’re talking about misbehaviors recorded and documented, if you will, that originate from essentially every country in the world.
Of those, 3.6 million of them were just specifically bots. And what a bot is, is it’s a piece of code that gets executed on a system, sometimes directly as a file – perhaps a download executable or perhaps a malicious payload in the form of a PDF or a document, Office document, spreadsheet, things like that.
And once infected, those devices then check in with a mothership that gives them instructions on what to do next. Sometimes those instructions are to attack people. Sometimes those instructions are to steal information. Sometimes the information being asked to be stolen is local, from a file system, perhaps documents of a specific type. Or sometimes the information that is instructed to the bots to steal is log-in details that is used to gain access to other systems, perhaps banking details, things like that.
But overall, those 3.6 million bots, there was no statistic in the news that day because there was an incalculable amount of information that was likely stolen.
To give you an idea what that looks like, let’s take a look at this Pony Loader botnet. So Pony Loader is a for-hire platform, operated by miscreants believed to be somewhere in Eastern Europe. It has multiple functions. It’s able to act as both information stealer and exfiltrator. So it can be trained to look for specific files to exfiltrate. It can be trained to look for specific website credentials to exfiltrate.
But that information goes back to these command-and-control servers. So what you’re seeing here is our observation of some specific command-and-control servers found to be used as the communication hub for three specific Pony Loader instances.
Now, you’ll notice the infected red devices that are the dots that are communicating back. Those are actually all over withinside those countries that you’re seeing there.
For the sake of visibility and kind of simplicity, we’re showing just kind of the specific breakdown per country.
So if you note those red dots seem to be showing up in the same places over and over again, that is by design. Now, in the case of the C2s, those are showing what network pump that they’re coming out to the Internet at. That’s why you see the breakdown that way.
So one of the things, though, that’s very worth note is if you note how little time has actually passed here running through. So, we have it sped up, obviously, faster than real time. But you can see in just a few minutes of time that has passed, there have actually been many, many connections from the bot devices themselves talking to the command-and-control servers.
And this is happening 24 hours a day, seven days a week. Now Pony Loader, if you haven’t heard of it in the past, it is a for-hire program. That’s why it’s called “loader.” And there are other miscreant operations that happen together in relation with Pony Loader.
So, for example, various types of click fraud or pay-to-install types of services are sold via Pony Loader. Pony Loader management, they’ll sometimes lease out specific nodes for people to use in their DDoS efforts or in their own or other botnet efforts. Perhaps you could think of it as a DIY business for these folks, because that is essentially how they run it.
So, now, that’s just one example. Let’s take another look at – let’s take a look at another one.
This is XOR DDoS. XOR DDoS is a bot platform that targets specifically Linux systems.
You’ll often hear people talk about the safety that you get from using a non-Windows operating system, things like that. XOR DDoS is an example I give to people why there’s no operating system that’s just inherently better or worse than others. They all have their issues. And XOR DDoS is one of those that shows the attacks that happen against Linux-based systems.
Now, for the most part, XOR DDoS does spread by hosts that are reaching out and scanning, looking for individual specific hosts that are running weak authentication systems.
So this is one of those times when having the ability to do two-factor authentication, things like that, would be a great idea. If you haven’t done so, for what it’s worth, look to enable 2FA on all of your services that you possibly you can. It will save you a lot of trouble and whatnot later.
These bots, these XOR DDoS bots, as you might guess by the DDoS in the name, these are all just nodes sitting and waiting and listening for instructions from the command server to tell them who to reach out and to attack next.
Those bots sit. Once they’re given the instruction of who to specifically attack, they then go and attack by way of various different types of packet-based attacks – SYN floods, UDP floods, things like that, against the target, trying to knock it offline. So that’s DDoS.
But let’s take a look at some point-of-sale malware called Kasidet. Kasidet is similar to how the other – how, for example, Emotet and those types of banking trojan information stealers worked.
This is point-of-sale-specific malware that is spread, in this case it was spread through things like Excel spreadsheets and things like that.
But this is us tracking – this is just one of the C2s that we’re tracking. You can see that there are infected point-of-sale systems all over the world.
And those point-of-sale systems, presumably, if someone were to sit down and make use of them, do result in presumably your credit card information being taken in real time and sent back to the mothership so that they can make use of them.
Now, this botnet functions in real time. So as things are taken off of the individual point-of-sale system, sometimes there are temporary-use numbers and things like that to try to thwart the ability from account information to be stolen.
But in the case of Kasidet when people would go to use it, they can get that temporary number sent in real time back to the miscreant who then maybe also uses it in real time as well.
So the fact that the Internet is keeping these hosts talking, and so quickly, enables for what you could think of as essentially real-time crime that’s going on.
So there are really no specific systems that are safe from those things. And not a lot has actually changed. So, if you’ve followed in the news, earlier this year there was a large takedown for Cridex or Emotet. Here’s a video that shows how big that network was.
This is an older video. This botnet had been taken down. But this is showing kind of what it looks like in its heyday. And this is tracking of five specific C2s that were out in the wild and the scope of infection for those hosts.
Now, in this case I did go ahead and diversify the dots. So you can actually see or get a better idea of what cities and places like that, where the connections are coming from.
But as you can see from – this is almost six years ago – there’s not a lot that has actually changed. This information, this type of pursuit of information, if you will, or information stealing has been going on for a long time, and there may or may not be any end in sight.
But there certainly won’t be without our participation and without all of us trying to do our best to put an end to these types of misuses of the Internet.
So to give you an idea of what all of those 26 million events look like, this is a display of all of the individual events as they’re identified in the course of the 24 hours. And what you’re seeing here is basically everywhere where there are people on earth making use of the Internet, it seems that essentially there are hosts there that are infected and that are taking advantage of the Internet to be used for miscreant and malicious operations.
As you can see, there’s really no safe corners of the Internet. There’s essentially, you know, no network that’s left untouched. And there are hosts scanning, prodding, poking, looking for access to systems constantly 24 hours a day, seven days a week.
So even while we’ve been here presenting today, and while we’ve been here talking today, that end effect is that while we’ve been sitting here, our phones have been scanned. Our laptops have been scanned. Our servers have been scanned and so on. And that is kind of the state of the Internet in the course of a day.
Now, it shouldn’t be thought of only as a miscreant or bad-guy effort as well. There have been instances, and in fact we have a visualization of one, where a country was upset.
So, there’s a website called greatfire.org that tracks government-operated censorship of the Internet from within China. And this again, though quite dated, it shows how quickly people can weaponize the Internet.
So this was a distributed denial-of-service attack that was going to take down this website, greatfire.org.
Now, in our case, also, by the way, note how slowly time is moving at the top here. So this is how aggressive the DDoS attack was. And it’s believed that this attack was conducted in response for some critical press that was shared on that specific website related to the government censoring other people’s use of the Internet within China.
So you can see just how massive their attack footprint was used for this. And what they did was they figured out a way to leverage DNS, the service, as a way to facilitate this attack.
So what you’re seeing are hosts that had all been redirected via DNS. They had all been redirected en masse towards greatfire.org. Now, in our case, though, you see how much of this continuous traffic and attack that you see there, this is only a visualization of less than 3 percent of the actual attack traffic.
We saw considerably more of it. But at some point, data at that point starts to get kind of hard to visualize.
So, some of you may be asking yourself: What does this matter? What exactly does botnets and people misusing the Internet on a constant everyday basis, what does that matter? It’s just packets. It’s just data. It’s just information. It’s just accounts. We can make new accounts.
Well, the video you’re seeing right now is what I’ll present to you as why these things matter.
So, this is a home in Evansville, Indiana, that was identified as the source of a threat of a bombing that would happen on July 4th a few years ago.
And local law enforcement there in Evansville, Indiana, was able to identify, by way of the assistance of some website administrators, they were able to identify the source of the attack of where this threat had come from.
So they, in conjunction with county and state officials, conducted a raid on the home at the very beginning when you saw them smashing through the glass of the door. They immediately followed that with a flash bang that went into the room. And as they charged in, as you saw, there’s a child there and some other folks.
So it turns out this home is occupied by a 68-year-old grandmother who had her grandchildren present with her. And though she herself was not a big user of the Internet, she did have Internet service for the family because, as we saw earlier, the Internet is an important thing to society as a whole. So even grandmothers have Internet access.
Well, in this case this grandmother didn’t know a lot about how to run the Internet in her home, and she had set up the Internet so that unfortunately anyone driving by could gain access to it.
In this case, her neighbor across the street was a young man who had actually decided to make those threats about police. He was a gang member and former felon and so on.
And because of this person’s threats against police officers online about a bombing they were going to be conducting, this family had their house raided, and a S.W.A.T. team come through their home, go through their entire lives, at gunpoint.
When you ask yourself, why do these things matter as a whole, well, ask yourself: What if this was your grandmother, and what if this was something that happened to your family?
As you look around and go through the policies and discussions that you’re having today about how to continue growing and making great use of the Internet, I ask you to keep in mind security as a practice, as a piece of our planning, so that as we move ahead, we’ll have fewer instances of these kind of digital issues splashing over into the rest of the world.
So that’s all I have. I thank you very much for your time, and I hope you got something insightful from this talk today. And I hope you enjoy the rest of the conference. Thank you.
John Curran: I’d like to welcome everyone back. A very insightful presentation and certainly eye-opening.
At this time I’d like to ask John Sweeting, our Chief Customer Officer, to give an update on consultation and premier support. Go ahead, John.
Consultation and Premier Support Update
John Sweeting: Thank you, John. Just one quick note on the presentation you just saw. If you have any questions about that, you can send them to firstname.lastname@example.org, and we’ll compile them and get them over to Dave. And he has promised to get any answers to any questions back out to us so we can get them to you. Thank you.
Okay. So I’m going to give you a quick update on consultations that we have run this quarter, the first quarter of 2021. And also a quick peek at the Premier Support Update. Next slide. Next slide.
Okay. Consultation activity during the first quarter of 2021. We opened a consultation on 8 February and closed it on 8 March about the future of ARIN’s unauthenticated IRR. We had 11 responses.
The highlights of that will cause ARIN to be extending the availability of our non-authenticated IRR for an additional six months. We’ve set a final retirement date of 31 March 2022. We’ll be doing a lot of outreach to customers who have records in ARIN’s nonauthenticated IRR to inform them of options that they have and provide necessary assistance to ensure that we don’t cause any glitches in their operations. And also engineers will be reporting on specific implementation changes as we go along.
We did another consultation that we opened on 16 February and closed on 16 March with about 37 responses. It was on password security for ARIN online accounts.
The outcome of that consultation is ARIN is going to change its password policies to better align with NIST SP 800-63B. Proposed passwords will be checked against the list that contains values known to be compromised. The way this is all going to be implemented will be covered by Mark Kosters in his presentation. I won’t go too much into that.
We’re also looking at future improvements to add functionality to allow organizations that wish to require 2FA, two-factor authentication, for anybody in their organizations that have access to their ARIN accounts and their resources.
We also have a consultation ongoing that just went out on Friday. It will close on 10 May. We always have the option of extending consultations depending on the amount of feedback and the discussion that’s ongoing. So that is open right now. And we are accepting replies to that consult. Next slide.
So we have put together a Premier Support Plan Update. Next slide.
So we have put together a Premier Support Plan. Right now it’s geared towards all organizations that are 2XL and larger – so 2XL, 3XL, 4XL and 5XL. It’s approximately 58 customers at this time.
What we’ll be providing in the Premier Support Plan implementation is there will be a dedicated account analyst.
So each one of those accounts in those categories will have an assigned account analyst from RSD that will stay current on their accounts and will be available to provide those organizations with structured information about their requests and will also help with any escalations that might be required for their tickets or any other issues that they may have.
There will be priority ticket handling. So tickets associated with these accounts will receive priority handling when requested. It won’t be every ticket. Every ticket does not require escalation. So when there’s a ticket that does require priority handling, the organization will have to let RSD know that. And RSD will take appropriate actions on that.
They’ll have a direct technical services liaison that will be available during the ARIN normal business hours for assistance with RPKI, IRR, DNSSEC and other technical services.
We have extended our 24/7 on-call support from eight customers that have been participating to out to those 58 customers now.
There will be a Premier Services Focus Group, which will probably once a quarter or so we’ll have customers – we will invite these customers to a roundtable with executive management – with the CEO, John Curran; myself; the CFO; the COO; Director of comms; RSD; FSD; CFO – to just have focus groups and just hear from them, hear how we’re doing, what we need to do better and how we can help them to be more successful with using their ARIN resources.
And there will also be waived transfer fees for these customers, these 58 customers. So transaction fees will be waived on any Internet number resource transfer.
Next slide, please. Premier Support Plan timeline. So what we’re doing in late 2020, we began the initial planning and looking at this concept. Early 2021, we continued with the development, and we’re looking for a May 3rd implementation.
As I said before, it will initially service all RSD 2XL and larger customers. And there will be updated people, process and tools to support.
Mid to late 2021 we’ll be moving into Phase 2 planning, which would be to define the requirements to expand the service beyond the 2XL and above customers. We’ll have to look of course at tools, processes, Board assessments, availability pricing needs assessments.
We’ll do a full analysis of this and probably do a consult to figure out, hey, how can we best support the community with these premier support plans.
And then in Phase 2, which will be sometime in 2022, hopefully Q1, maybe Q2 possibly, there will be a Phase 2 implementation which will expand the offerings with additional organizations.
Next slide, please. This has just been greater detail, just shows out the different phases. Phase 1 I’ve already covered. You can see late 2020, early 2021 is when we plan to implement it.
Next slide. This is the Phase 2 implementation, which mid/late 2021 is when we’ll begin the planning. We need to get the feedback from the Phase 1. We need to see exactly how this is going to impact, how many requests, how many escalations we’ll be seeing, how many people use the 24/7 line, how often we actually need a reason to be called during off hours in the weekend, in the middle of the night because of our services.
There will be a lot of analysis and a lot of planning going into that. And then hopefully by 2022 next year, the third quarter, we’ll be able to offer the support plan out to other customers that would like to take advantage of it.
Next slide. That’s it. That’s all I have. Any questions?
Remote Host: John, we do have one question in the question and answer queue. Looks like it was just answered.
Paul Andersen: Well, the question – yeah, I think “it doesn’t change in the least” was the answer.
John Sweeting: Okay. If nothing else, then I will pass it back to –
Remote Host: John, it looks like we have a hand up from Chris Tacit. Chris, I’m going to go ahead and allow you to talk.
Chris Tacit: Can you hear me okay, John?
John Sweeting: Yes.
Chris Tacit: I was curious about the transfer fee waiver. Does that apply to specific transactions for which – to which those tickets apply or to parties who are registered for that service while they’re registered? I’m just curious as to how that works.
John Sweeting: I’m not sure I’m catching your question, Chris.
Chris Tacit: Are parties going to be permanently enrolled in this program and therefore always subject to transfer fee waivers, or are they enrolled for a specific period of time to deal with specific –
John Sweeting: For Phase 1? I think I got your question now. For Phase 1, the customers that we’re enrolling in Phase 1 will be enrolled in for as long as they’re within those – meet the criteria, the 2XL and larger organizations.
Chris Tacit: Thank you.
John Curran: If I could speak to this a bit.
John Sweeting: Go ahead, John.
John Curran: Recognize that 2XL customers are large – 2XL large customers are customers who their fees are more than 32,000 annually. Some of these customers have very modest support requirements but are paying significant fees.
The place that we’ve seen where there’s work involved that’s actually additive to our process is when we seek a nominal transfer fee from an organization already paying significant amount from ARIN and it slows down their process, we realized that for organizations of this size, it’s possible to waive the transfer fees because they’re involved in a lot of transactions.
And the amount of work actually is nominal because we worked out smooth interactions. Actually in many cases the fee can actually be the longest pole in the tent in getting the job done.
So the Premier Support Plan is envisioned to be a new permanent ongoing program. As long as the program exists, the organizations that qualify in that tier category will be part of the program. We’re also looking to figure out how to expand it, but we really have to get a grip on costs.
The one other thing I would add is that it’s worth realizing that we have support for our operational services 24/7, every day of the week. We monitor our systems and we maintain them.
The off-hours support that’s referenced in the Premier Support Plan is about particular customer requests. Sometimes the – our services are fine, but the customers need assistance putting in a ticket or getting something processed to utilize our services.
Our services are supported 24/7 for everyone. But we don’t assist people with tickets. That would change for Premier Support customers.
John Sweeting: Thanks, John. So there’s some other questions on here. I’m going to reply to Frank.
Frank Bulk, FiberNet, asks: Is there a risk this creates some fears of ARIN services and support?
Yes, there’s always that risk; however, ARIN is committed to ensure that the service that we provide to our customers today is not affected because we offer some organizations that require it and need to have a higher level of service request that and be given that service.
It won’t affect the service today. We will not go out to answering, taking four days to answer tickets because we are escalating on other tickets that are for larger customers.
So we’ll manage all of that. As John said, that’s part of what we have to figure out as to what these services cost so that we can then offer them to everyone.
And that goes to – Lee had a question that disappeared, asking if somebody that wanted to pay 2XL fees could get this service. I’m sure we’d be very happy for that.
But that’s not what we envision. We don’t envision that we’re going to have to have people pay 2XL fees in order to get the service. That just was the group that we included to actually look into and study these plans.
John, did you have anything on that?
John Curran: No. I think in Phase 2, when we understand our costs better, we can figure out how we can expand it to more customers.
Right now, we are rolling it out with a limited set because clearly we don’t want to – some of this may actually help improve our ability to support customers. Some of these customers already have, as I said – we’re actually smoothing some of our interactions.
But we want to make sure we don’t incur additional costs to ARIN needlessly. Need to understand if we expand it to more customers what that would be.
So for now it’s a preliminary program. But once we’ve run for a while, we’ll be able to talk a lot more about where the program goes long term.
John Sweeting: Okay. John, to Don’s question, if we found the criteria for the support when will you be notified?
You’ll be notified very soon now that we’ve announced this. You’ll be getting an email from both from RSD management as well as the analyst that will be assigned to your account.
And Mercia, so there’s 58 2XL and above customers. There’s like 6,500 other RSD customers. All right. I don’t see any more.
Paul Andersen: There was a question that said will 2XL organizations be automatically enrolled.
John Curran: Yes.
John Sweeting: Yes. 2XL is automatically enrolled. That will be happening between now and the May 3rd kickoff.
Paul Andersen: Another question: Will legacy IPv4 resources be covered under LRSA be included in the Premier Support Plan?
John Curran: That’s to be determined. We have a challenge in that the LRSA customers agreed to certain services and got a fee cap. We don’t know how we’ll treat our Premier Services with respect to people under the fee cap of the LRSA.
John Sweeting: Okay. I think we’re caught up, and I think that should do it. And I’ll hand it off to the next presenter.
Paul Andersen: Mark Kosters.
John Curran: Next presenter is Mark Kosters. Mark, if you would give our IRR, RPKI, and Password Security Update.
IRR, RPKI, and Password Security Update
Mark Kosters: Be happy to do so. It’s pretty interesting, the keynote, and how it was focused a lot on security. And I want to talk about a couple of things that we’re working on within Engineering that deals with security as well.
So next slide, please. So, first of all, is IRR update. What I’d like to do is talk to you about some of the things that are somewhat surprising and some of it – yeah, this makes sense.
So the first part is what makes sense. So when we turned off IRR in terms of putting out new maintainers and so on for ARIN non-authenticated IRR, we did that back in June when we rolled out the new authenticated IRR, or what’s called ARIN now. And the non-authenticated portion is called ARIN-NONAUTH.
The authenticated portion is in the green line here. And so the ARIN part is in orange. And you can see that the number of maintainers in ARIN has increased a lot. This is not surprising. Next slide, please.
What’s interesting here is you can see on the route objects that there’s a close matching on the number of routes that have been added on both the NONAUTH and the AUTH side. They both increased by about 4,000 over this last quarter – last half of the year, rather.
Next slide, please. And you can see that with route6 objects, there is some increase on the number of route6 objects in ARIN authenticated IRR and a nominal increase in the non-authenticated portion.
Next slide, please. So we expected to see a drop in ARIN-NONAUTH, but that’s not really reality. Maintainers who are part of the old legacy IRR have come to life. They’re now registering objects in the non-authenticated portion of the IRR. And the number of objects added is roughly the same in both the authenticated side as well as the non-authenticated side.
And of course we see growth in the number of Orgs participating in the ARIN IRR. So one of the things that I saw as sort of a question is: Did we expect to see a significant drop in ARIN-NONAUTH? I did, but that doesn’t seem to be reality.
So anyways, I just thought I’d give you a little bit of an update on the IRR.
Next slide, please. Now let’s talk about RPKI.
Next slide, please. We had two challenges over the past six months. We’ve had two software updates, which led to some interesting issues. First one was an encoding issue that was seen by a subset of validators.
When we tested against it initially for our August release, we tested against RIPE’s validator as well as NLnet Labs’ Routinator. They both passed our test. And the manifests came out green.
But when we deployed, it turns out that there was a number of other validators that said that we had issues. And we were notified of this and had it quickly fixed. At that point we have increased the number of validators that we test against. And we put it on the webpage, on our webpage under the RPKI section on the validators that we do support.
And we support NLnet Labs’ Routinator, RIPE’s validator for a certain period of time. They now have just announced that it will no longer be supported by RIPE – with the upcoming maintenance and that release, and that’s about it. There’s FORT and there’s RPKI Client. Those are the ones we currently test against.
We do have an observer platform that we run ourselves and we check these things against their outputs – the various validators’ outputs – to make sure that the number of validated route objects that come out of it are actually the same between all the various validators.
And we also included OctoRPKI in that test to make sure that we have a consistent and uniform output. So, that was one of the first lessons learned that we learned over this past year.
The second one is that we have a little issue where we admitted a number of delegated RPKI users in a software update. So after that we did an audit of our implementation against the RPKI RFCs and our test coverage to make sure that we’re totally covering all the particular elements, what’s manual and what’s automated.
And we also hired a Senior Product Manager, Brad Gorman, to help lead this activity. So those are the things that we’ve done as a result. Those are issues that we are sincerely sorry about. And we are trying to do our best to make sure that we’re up 100 percent of the time, all the time.
Okay. Next slide, please. One of the interesting things here is if you look off to the right, you’ll see that we’ve had, that we keep on having growth in the number of organizations, number of ROAs, number of resources. And what’s interesting here is we’ve had a jump and this jump is fairly recent where we went from nine to 16 delegated RPKI participants.
I think that’s interesting. Most of the participants are still – 17 – 1,776 are still using hosted service. But you can see that number of delegated customers is increasing. Next slide, please.
So one of the things that’s happened, which is interesting, is we look at this on almost a daily basis to make sure that we’re doing all the things correctly in RPKI land. And one of the things that we noticed, and hopefully you can see this, is that we are – now have the most number of ROAs out there in the community.
RIPE has been working on this for a long time. They have lots and lots of people actually using RPKI, as well as we do. But we’ve actually surpassed them in the number of validated ROAs that are out there in the wild.
So I thought that was interesting, that we now have a significant portion of RPKI that’s being managed by ARIN.
Next slide, please. So here’s an interesting thing. Much like the keynote, we’re occasionally under attack. And we’ve noticed some things and we want to bring this to your attention. Next slide, please.
We’ve had an instance where there was – actually a number of instances – where we’ve noticed a flurry of brute-force hacking attempts against people’s accounts.
When we initially set this up, our account login behavior was, we did six login attempts, and then we would lock your account. What this did, is with this brute-force hacking attempt, if they figured out your account name, they would actually keep on testing passwords until they got locked out. This led to a number of locked accounts, which was not a good thing to do.
So we actually pivoted and inserted a CAPTCHA within the login process. So if you had, for example, four login attempts, it would then issue a CAPTCHA. And if you passed that CAPTCHA, then it would allow you to have a couple more login attempts before it would actually lock. And this basically stopped the brute-force activity.
So that was a good source stopgap temporary measure that we put into place, and it actually was very successful.
Next slide, please. And here you can see something that we see internally. We look at this at least once a week where we look at sort of normal behavior, in making sure that our systems are operating correctly and that we see sort of standard activity against our system.
And you can see for the most part it’s pretty consistent. We have about five, five and a half accounts logins per minute. And at this point it was currently eight when we took this snapshot. But you can see that here’s how we currently look at our systems.
Next slide, please. Here’s what it looks like when you can see that we’re under attack. And you can see that we had a small one where instead of having essentially five and a half account logins per minute, here you can see we had over 5,000 over a sustained period of time.
And a little bit later, on the 13th and into the 14th, we actually went up to 15,000 queries per second – number of logins per second – where people are trying to – actually try to guess people’s passwords. You can see that most of them were unsuccessful.
Next slide, please. After this attack, one of the things we did is we said, okay, let’s look at this and see the number of invalid passwords.
You could see we had close to 10,000 attempts. Most of these were blocked by almost 250,000 attempts. And invalid usernames, all these people were trying to guess what the username was, and there was close to 11 million invalid users that they actually hit beforehand.
Next slide, please. We were not the only ones that were under attack. We have a private Mailing List that we use between the various engineering activities within the various regional registries, and we talked about this. And this actually made news within the RIPE NCC as well as that they were also under attack by basically the same actors as what we saw.
Next slide, please. So the resultant activity, beyond the CAPTCHA that we put in, is that there was a consultation on login security. And there’s a number of things that we have – are going to do as a result.
One is that we’re going to align ourselves with NIST SP800-63B password guidelines. We’re going to check – as part of those guidelines we’re going to check against a list of known values that are to be compromised so that you don’t inadvertently put in a password that has been compromised someplace else on the Internet. We’re not going to impose any composition rules requiring, for example, mixtures of various character types or prohibiting consecutively-repeated characters. That is not part of the guidelines.
And we’re also going to start rate limiting by using a CAPTCHA and incrementing timeout periods between further attempts. So, if you have a couple attempts, and then we’ll just increase the timeout value by doubling it or tripling it or whatever, so that it would take increasingly long periods of time for someone to actually guess the password and they would have to use the CAPTCHA.
And this would basically make this particular attack not very fruitful for the attackers. And again, this is according to the NIST guidelines. This code will be released in June of 2021.
Next slide, please. So at that point, I am done. Are there any questions?
Remote Host: Yes, Mark, we have a question from David Huberman with ICANN. He says: Mark, can you please talk a little bit about ARIN’s participation in RPKI protocol development at IETF, current status and any goals that ARIN might have for improvements. Thank you.
Mark Kosters: Yes. So we have participated in IETF for years and years and years. And there’s been various suggestions that we’ve put in as part of our input within the SIDROPS Working Group, which is where this RPKI work actually goes on right now.
And we’ve done a number of things within the past couple of years. One of the things that we put in, for example, was a draft that dealt with how we handle trust anchors.
And we put in a draft that wasn’t accepted by the working group, but it was something sort of indicating what we were planning to do with the various RIRs as we went forward and that all of us would have – basically say we would have all resources within our trust anchors for a couple of reasons.
One is to essentially mitigate the amount of brittleness that does occur in RPKI, especially when it deals with RIR transfers. That’s one of the things we wanted to alleviate.
This is something that – we went forward. There’s some protocol development going on within IETF to make the RPKI validation less brittle, of which we’re playing a part of as well.
There’s some other things going on as well within IETF that we’re well abreast with and making sure that we implement when the standards are ready. Thank you very much. Good question. Next question.
Remote Host: Yes. We have a question from Kevin Blumberg with The Wire. What’s the percentage of users that are now utilizing MFA? Has a hard requirement been investigated? Brute-force attacks are common.
Mark Kosters: Yes, I think he meant 2FA – two-factor authentication, is that correct, Kevin?
John Curran: MFA, multifactor. He might mean two, three, name, text, fingerprint, retina ID – and then you have to sing a song.
Mark Kosters: Okay. Okay. Well, you don’t want to hear me sing, obviously.
So we do have existing 2FA implementation out there right now. There’s also an ACSP to put in yet another form using YubiKeys, et cetera. So we have some very – sort of, degrees in that we want to go forward with. 2FA is out there, sadly, is not as well used as we would like. And that is available now for those people who want to safeguard their passwords and everything else, their accounts, please do so. Please use the existing 2FA implementation that’s out there.
John Curran: Mark, if I could add something there.
Mark Kosters: Yes.
John Curran: One of the things that has come up is some organizations have said they’d like to use two-factor authentication, but they note that it’s turned on on a per-user basis.
So what we’ve looked at – and it did come out in the consultation responses – we’ll be looking at a feature that allows an Org, an organization, to set mandatory two-factor authentication for all its assigned users.
That way, if it’s your policy that you want everyone to use two-factor authentication, the accounts associated with you will have to have it turned on.
We’re not going to do that automatically, because each organization has its own decision as to what’s appropriate for its ARIN online accounts.
Mark Kosters: Thank you, John.
Remote Host: Next question comes from Rob Seastrom with Capital One Cyber, ARIN AC: Have you decided on a minimum link? NIST SP800-63B says more is better, but has a suggested bare minimum link that seems short. Related, will there be a maximum link? I.e., if I want 70-character-long pass phrase, is that okay?
Mark Kosters: That is a good question. I will have to get back to you, Rob, on this question in terms of what our maximum length is within our application. So that’s a good question, and we’ll get back to you.
Remote Host: That’s all the questions.
John Curran: Any other questions for Mark? If not, thank you Mark. Very helpful.
Next up, I’d like to have Lisa Liedel give the Registration Services Update.
Registration Services Update
Lisa Liedel: Thank you, John. Next slide, please.
We’re just going to talk a bit about some of the RSD statistics and some new services that we’ve been offering and that we will be offering.
Next slide, please. Currently ARIN has about 39,000 organizations that we serve. We have about 18 percent of those are ISPs or member organizations. But we have another almost 43 percent are our end-user customers, and another 39 percent are our legacy customers.
Next slide, please. Our RSA coverage for IPv4 kind of stacks up like this. From the 6.5 million IP addresses in ARIN’s inventory right now, we have about 49 percent are under a standard RSA with ARIN, and about 14 percent are under a legacy RSA. And another almost 37 percent are not covered.
Next slide, please. RSA coverage over time, we like to see it going up to be covered under RSA or legacy RSA, which it’s doing. So we’re in pretty good shape there. As we get more transfers coming in for M&As and even 8.3 transfers, we’ll see that go up even more.
Next slide, please. This is just a little bit on our Caribbean region. Just wanted to show that they’re going on to the waiting list. For the first quarter of this year we had 61 Caribbean organizations enter the waiting list. And after we filled in March, there were two that were left on the waiting list.
Next slide, please. Again, this is our waiting list growth just within the ARIN region. And back in 2016, 2019, we had some really big spikes and folks weren’t going on the waiting list.
We now see that they go on and off the waiting list with our quarterly distributions, and it seems to be going at a much better pace. We filled over 250 requests at the end of March, beginning of April for our waiting list distribution.
Next slide, please. These are our reserved pools. They’re in pretty good shape still. We have – anything that is issued for Section 4.4, Critical Infrastructure, if that’s reclaimed or returned, it goes right back to the pool.
And the same for Section 4.10 for transition purposes. If it’s reclaimed or returned, it goes right back to the pool. So we should be in good shape for a while yet.
Next slide, please. And this is our IPv6 profile under Registration Services Plans. So we have a little over 39 1/2 percent of our IPv6 is – I’m sorry, our IPv4 users only. That doesn’t mean they don’t have IPv6. They could have it from a provider peer or they could have it in a different Org ID.
And with IPv6 only, there’s about 10 percent. And again, same thing, they could have IPv4 from a provider peer or in a different Org ID. Then we have about 50 percent that have both IPv4 and IPv6.
Next slide, please. This is our IPv6 networks created by year. In the first quarter of 2021, we see a big anomaly here. We see 56 – over 56,000 IPv6 networks being created. We noted that one of our largest ISP customers had created well over 46,000 IPv6 SWIPs.
Next slide, please. And this is IPv6 issued in the Caribbean region, just another way to show you that they are moving into IPv6, and most countries in the Caribbean do have IPv6 now. Next slide, please.
And these are the number of /24s transferred by quarter in the ARIN region. And the IPv4 – I’m sorry, the 8.4 transfers fee, 29,000 or the 26,000 that’s listed there, about 2500 of those were transferred out and the rest of them were actually transferred in to ARIN. That’s actually compiled both in and out.
Next slide, please. So the services in the RSD structure has changed a little bit over the past 12 months. About a year ago we started offering a chat service. And we also released the new Routing Registry. And last month we moved the Registration Services Agreement process from the end of the process up to the organization create.
We’re hoping that that will help remedy some of the delays at the end of the process. In May we’ll be offering the Premier Support Plan. With these it’s brought more need for technical support and an increase in our customer contacts. So that’s led us to a little bit of change in the RSD structure.
Next slide, please. And most of these folks in RSD you know. We have a couple new folks. We have Nathan Newman. Nathan came in, I believe, in August of last year. And he is our technical support specialist. He will be providing the technical services for IRR, RPKI, DNSSEC and RESTful calls.
And Reese Radcliffe is our Registration Services Manager. He’ll be doing the day-to-day operations with ticket management and working with our customer resource analysts.
Next slide, please. So our chat service, which we implemented last April, and I think I’ve shown this once before, we do see with chat we have about 50 percent of the call volume when you compare them together.
We haven’t seen the call volume go down, but we still receive about 50 percent as many chats as we do call volume.
Next slide, please. Our Internet Routing Registry, Mark talked about that a lot. We got the authenticated version of IRR and a web interface in June; and in February we had some RESTful deployments, RESTful IP deployed. This is where Nathan will step in, take on a lot of those technical services responsibilities.
Next slide, please. And this is the – moving the RSA to the Org Create process happened at the beginning of March. We had a lot of questions with customers that had an Org created, and when they got their resources at the end, they found out their legal department would not sign with the name that they created on the Org ID. So it kind of put them back to the whole process again where we had to get the Org ID straightened out.
With that we found that already a lot of folks scheduled vendors and consultants to come back in which caused them pain and delays because they had to reschedule and that type of thing.
So moving the RSA to the beginning of the process should alleviate all of that at the end of the process. We’ll make sure we have everything correct up front.
So, so far for the first month we’ve had 319 requests for Org IDs. 180 of those are still pending where we’re waiting for Registration Services Agreement or some vetting information from the customer.
16 of those were abandoned because they weren’t legal entities, and then 123 have actually been completed with signed RSAs in March.
Next slide, please. Our Premier Support Plan, John Sweeting talked about that earlier today. So I won’t go over all these again. But suffice it to say, our Customer Service Analysts Level 3, Mike, Misuk, Eddie and James, will be supporting this as the dedicated account analysts.
Next slide, please. That’s all I have.
John Curran: Any questions? No.
In which case I’m going to slip in here and talk about another consultation that was an addition at the last minute.
ARIN Fee Consultation
John Curran: So I’m John Curran, President and CEO of ARIN. My presentation is on a consultation that we actually launched on Friday, which is the ARIN Fee Consultation.
So next slide. Next. So we base our fees on equitable cost recovery across the community. And we don’t routinely change our fees. There’s some organizations that in the registry you feel every year reset the fees based on their total costs. ARIN does not do that. We leave our fees the same.
People are used to paying them, and periodically we – every few years, as our costs increase, periodically we adjust.
These two have sort of come together. And we’re looking at a – we have a consultation out there to do a significant fee change. And the fee change that we’re looking at is trying to get all of our customers on the same fee schedule.
That would be moving the customers on the end user fee schedule to the RSP, the Registration Services Plan schedule. We dropped this consultation on Friday, and it will be open for 30 days.
Next slide. So we’re going to transition end users from a per resource maintenance fees to the registration fee schedule. We’ll be transitioning legacy holders from the same, only the legacy holders are subject to an annual cap that’s in some of the Legacy Registration Services Agreement.
We’ll be raising that annual fee $25 per year as allowed, but it might take a while before legacy resource holders under LRSA are paying comparable fees.
We’re providing a temporary IPv6 waiver – as been requested by the community – so that organizations that have more resources – IPv6 resources – than 3X will be able to have a larger amount of resources without paying the 2X category.
We’re implementing a $100 fee for Org Create and Org Recovery transactions. As noted, these are entailing a bit of cost to make sure the vetting is done properly. And yet the vetting has to be done properly, lest we risk hijacking or people doing misrepresentation that leads into the sort of situations that are undesirable on the Internet.
And increase in the transfer processing fee, all of this is in the fee consultation. Next slide.
Why change the fees? So presently we have – we’re providing, for all practical purposes, the same services to all the customers who are having an agreement with us.
Customers who are paying on a per resource block basis, presently paying $150 per record. So that’s ASN, IPv4 block or IPv6 block.
Yet someone else in the same industry in the same market might be paying, because of the size of the block, they might be paying $4,000 a year rather than $150 a year.
We don’t think that’s desirable long term. And so we propose to move the end users to the same fee schedule. Everyone will pay the same Registration Services Plan. It does mean organizations that does have larger resource holdings will pay more.
This will generate more revenue for ARIN. That’s very plain. If everyone moves over and everything – nothing consolidates no one goes elsewhere, it could be about $3.8 million.
We expect it will actually be less. And people have asked why is that appropriate? Well, as I said, we see our costs go up 2 to 3 percent every year. That’s natural with the costs of staff, inflation and services.
Over the course of four or five years, that can be become up to 10 percent of costs that need to be recovered.
This will help us address that. We’re also looking at long term how to lower that ongoing creep. But that’s not part of this consultation per se.
This is about doing a change to get everyone on the same page. We have not been still, even though our fees have remained unchanged, we’ve extensively invested in new services.
ARIN Online, new authenticated IRR, RPKI efforts have all been funded and expanded under the current fees.
This will get everyone lined up. So what I mean by that is everyone will be on the same fee schedule, including organizations that were ISPs, end users, legacy holders, and it gives us a sense of fair play. We don’t have some customers who are effectively using their resources just as another customer is, but paying one-tenth the cost. And that’s very important because as the IP registry market has matured, we don’t see the same distinctions.
Nowadays, many people are using address space and they’re not allocating it to customers because it’s in a pool in a data center being used for virtual hosting or cloud. Yet, another customer will be doing the same thing as an end user.
The address space is all registered to them. They’re also not subdelegating it permanently to customers; there again, hosting virtual computers or cloud. Both are perfectly allowed circumstances. Both of them involve serving customers, and yet we’ve treated them historically differently.
So by having our fees uniform we make sure that it’s fair to everyone. And it provides predictability. People want to know what our long-term fee strategy is. This answers that question.
That’s actually all I have. I wanted to point out, next slide, that the consultation is taking place online. So if you go to ARIN Consult, you can see the discussion there. We welcome comments. Feel free if you know someone who might be interested, to have them participate.
I’ll do a summary and provide it to the Board of Trustees. This is proposed for 2022. You can see the proposed fee schedule. It is actually the same fee schedule. It’s the Registration Services Plan fee schedule. The only difference, of course, being that it would apply to a larger community.
But the fee schedule and the descriptions of the waivers and similar, it’s all available online at that URL.
That’s all I have. I guess I’ll take brief questions. We’re not doing an online consultation here. But if people have something for clarity, I’m happy to pick it up at this time.
Paul Andersen: If the legacy holder was willing to accelerate their true-up, is ARIN willing to negotiate on this issue with jumping straight to the final result in one year? That’s from David Farmer.
John Curran: If the legacy holder was willing to accelerate their true-up, is ARIN willing to negotiate with jumping straight to the final result in one year? I don’t know what negotiation is.
Paul Andersen: I wonder if he means, if he’s meaning, John, the cap and if they want to just jump to their final company all at once.
John Curran: Any LRSA holder that wishes to go to an RSA fee schedule, we’re happy to accept that. And as I said, because we have had people actually do that. So that’s certainly an option.
And we may see some of that as a result of, for example, the Premier Services Plan, because obviously that would be something that might entice someone under the LRSA to move to additional services. We’ll talk about that.
We need to look at that, David. If you want to reach out to me directly, I’ll make sure I understand your question.
And impact on legacy holders. Just to say legacy holders, if you’re a legacy holder under an RSA today, you’re presently paying $150 per resource record per year. And then that’s capped to an LRSA cap of $150.
So you’re not paying more. You’ll now be paying on a much larger fee schedule, but because of the cap, the vast majority of LRSA holders will see no change in their fees. That cap will go up $25 per year.
This consultation includes a statement that we’ll be raising the LRSA cap $25 per year every year, okay.
So eventually, someone pointed out, in some number of centuries, LRSA holders might be paying the same fees as everyone else.
Paul Andersen: John – John, I was going to – I popped up actually not to be the Q&A moderator but to say I realize that the consultation dropped on Friday, but we’re obviously here Monday, Tuesday, Wednesday, and there’s an Open Mic each day. Feedback from the community is important. We understand that some people’s fees are going up; others are going down.
We don’t do that lightly, but we do want to hear your feedback as we try and plot the course. I just wanted to add that, John. That there’s Open Microphone at the end of the day.
So if people have thoughts they wanted to add, as John said, it’s not an online consultation. It’s important that your feedback eventually go there. But if you had some comments, we can certainly take it.
Kevin Blumberg raised a question while I was going, John, if you want to hit it.
John Curran: Certainly. Let me run over and get the open questions. In previous consultations you had an overview of percentage impact.
Actually, we didn’t put it in the consultation announcement. But on the ARIN Consult Mailing List, if you look at the archive, we have a breakdown by category of how much people will be – in each category, how the fees will change in that category.
So you can see all the percentages right there. We actually outline more than 40 percent of the organizations actually see a fee increase because they’re in the smallest category.
If you’re a small organization, this is actually a pretty wonderful change. I’d recommend go to the ARIN Consult list. We actually posted that, Kevin.
With that I’d like to give it back to Lisa. She has another presentation to give. The Policy Implementation and Experience Report. Over to you.
Policy Implementation and Experience Report
Lisa Liedel: Thanks, John. Next slide, please. So we’re just going to talk about section 5 of the Number Resource Policy Manual, AS numbers. This is the current text. And the three sections that are in bold are the three in particular that we’re going to discuss.
Next slide, please. So the first section that we’re going to discuss is the section that says sites that do not require a unique AS number should use one or more of the AS numbers reserved for private use.
The most popular question we get here is how do I know if I require unique AS number? And our typical response is if you don’t have the need to use it on the public Internet, then a private ASN should satisfy your needs.
So to help clarify that for customers, we just thought you might want to consider maybe changing the words a little bit to: Private ASNs should only be used when there is no plan to use them on the public Internet.
Next slide, please. And then the section where we outline unique routing policy and the multi-home sites. Unique routing policy is somewhat problematic for customers. They don’t really understand what that means, and most of our ASNs are issued under the multi-home policy anyway.
So we just had a suggestion that you might want to consider reversing the order to help make this a little easier for customers and just if they plan to connect the network using BGP or multi-home, or using your network requires routing policies to be deployed through unique only to your network, unique routing policy. That might help customers a little better as well.
Next slide, please. And then the last section is AS numbers are issued based on current need. An organization should request an AS number only when it’s already multi-homed or immediately become multi-homed.
Given that all of our resources are issued based on justified need, you might want to consider removing this or even replacing it and just saying that you can request an AS number when your network plans are ready and when you’re planning to use BGP or have a unique need for your own ASN.
Next slide, please. And this really isn’t a policy experience report, so to speak, but this seemed like the most appropriate place to put it since it was part of the Number Resource Policy Manual. Section 3.2 talks about distributed information services, the use requirements for that.
There’s a line in there that says that RWhois servers, for instance, must be operational 24/7 and they must allow public access both to ARIN and to the community in general.
We currently have about 712 organization identifiers that have RWhois servers listed on them. But only 250 of those are currently accessible.
We do know that some organizations have moved over to SWIP instead of using the RWhois. So they’ve probably just forgotten to remove their RWhois server.
If you fall into this category or if you changed your RWhois server and you just need some assistance with that, we ask that you open up an Ask ARIN ticket, and we’ll be happy to help you with any of that.
Next slide, please. I think that’s it. Yes, unless you have any questions.
Remote Host: Lisa, it doesn’t appear we have any questions. Thank you.
Lisa Liedel: All right. Thank you.
John Curran: Very good. At this time I’ll now turn it over to Mr. Sawyer to do the Advisory Council and Policy Docket Report. He’s the Chair of the ARIN AC. Go ahead. We’re working on making him presenter. Here we go.
Remote Host: Just a second.
John Curran: In the meantime, I’ll tell a joke. Maybe not. An IP address walks into a bar and asks the bartender, can I have a cider?
Advisory Council and Policy Docket Report
Leif Sawyer: Boo, John, boo. I’m assuming I’m coming through here finally. Good morning, everybody.
John Curran: Yes, you are.
Leif Sawyer: Great. I’m Leif Sawyer, the Chair of the ARIN Advisory Council here. Welcome all to ARIN 47.
Next slide, please. We’ve got a great group of our 15 AC members who have been doing a lot of great work this past year here since ARIN 45 and ARIN 46.
We have a lot of returning faces, and our two new members, Gary Giesen and Matthew Wilder.
Next slide. There’s been quite a lot of policies we’ve sent to the Board since ARIN 45, really, and 46 – the inter-RIR M&As, 4.1.8 waitlist updates, other waitlist updates, IPv6 nano-allocations, great stuff coming down the pipeline, that’s all the Board has already implemented. Hopefully those are able to be used by the community as we all would want them to be.
Next slide, please. Bunch of new proposals on our docket that we are working. And next slide.
That’s interesting. I missed our current docket slide. I don’t know what happened to that. There it is. Excellent. Thank you. So as you can see, these are the current policies – proposals and draft policies that we are working on. A couple of Recommendeds as well. There’s one editorial change that we’ve done.
Next slide. So, last year our previous Chair, Tina Morris, implemented the following three working groups as a way to help improve the cycle of community feedback through the AC and to help propel the policy changes that the community is seeing.
Next slide. And so our PDP Improvement Working Group has created a new draft of the PDP which we just received some initial feedback from last week. And they’ll be taking the comments received to address points within their draft PDP and then resubmit it back to staff and legal.
Next slide. The Number Resource Policy Manual cleanup has been going through this, submitting editorials and draft policies and doing just a heck of a good work. I’ve sat in on a few of those meetings, and they’re doing some really good cleanup work in there. So, I just want to call them out for really helping to make the NRPM a much better document.
Next slide. Our Policy Experience Report Working Group is going to be reviewing the report that Lisa just provided and identifying places where we can address them. So that’s great.
Next slide. We did want to give a shoutout to Chris Woodfield, who I saw in chat is attending the meeting. Thanks, Chris, for all your hard work. We really miss you. We miss seeing your smiling face and hearing your laugh after hours. Great sense of humor. And it was a great asset to having us.
Next slide. And also to Tina Morris who advanced to the Board of Trustees in January. She also provided a number of years of service to the AC. And, of course, I wouldn’t be here without Tina’s direction and assistance. So, thank you so much, Tina.
Next slide. And that’s really the entire introduction to what’s happening this week. And if there are any questions, I’ll be happy to try and answer them.
John Curran: Any questions?
Remote Host: Doesn’t appear at the moment that we have any applicable questions.
John Curran: Okay. If not, thank you for the presentation.
And at this point we’re coming up on our break. I want to let people know if you stick around during the break, we’re going to have a stretch, I believe, is that at this break? There should be some stretching – or is that at lunch?
Remote Host: Go to the next slide, please.
John Curran: Next slide. There we go. That’s what I expected. If you stay through the break, you can stretch with Erin, and there’s a trivia game. Otherwise, if you want to go on break, we’ll be on break for just over 30 minutes, and we’ll return back from break at 2:15 Eastern time.
For those who want your break, now is the time to refresh your beverages, stretch your legs, or stretch with Erin. I’ll look forward to seeing everyone back here at 2:15 Eastern time. Thank you.
(Break from 1:40 PM to 2:15 PM.)
Adopted Policy ARIN-2020-2: Reinstatement of Organizations Removed From Waitlist By Implementation of ARIN-2019-16
John Curran: If everyone will get settled, we’ll resume the meeting.
This is our policy block in the afternoon, where we handle advancing policies along the Policy Development Process. This also includes reporting on significant policy actions.
As such, I have the honor of being the first presenter. I’m going to be talking about Adopted Policy ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16.
Next slide. So, as people are probably aware, when we suspended the waitlist, there was a period of time when we had the waitlist suspended because of significant fraud.
As a result of that, there was an updated policy for issuance from the waitlist, ARIN 2019-16, which applied criteria for getting subsequent allocations or getting allocations from the waitlist. And those criteria were applied to everyone new to be coming on the waitlist and all the organizations on the waitlist.
As a result, a number of organizations were removed from the waitlist who had waited some period of time. The waitlist was suspended. When it was reopened, the criteria called for them being removed.
This policy, ARIN 2020-2, added a section to provide a different transition for those organizations – to restore the organizations that were on the waitlist to the waitlist and have them evaluated under the new criteria but not the full set of new criteria because they had already qualified once. This was a pretty contentious policy.
Next slide. So it was introduced in March. It was discussed by the community in our October meeting. It was actually considered – supported by the community and was sent to Last Call by the ARIN Advisory Council, having met the criteria of technically sound providing for a fair distribution of IP addresses and supported by the community.
The Last Call became contentious. And in the Last Call period there was quite a bit of discussion of why we were doing this and whether it made sense. As a result the ARIN Advisory Council let it revert to Draft Policy. If the ARIN Advisory Council doesn’t send something to the Board after Last Call, after a period of time it automatically reverts to a regular Draft Policy. That’s what happened; it reverted.
There’s a petition process available for the community to say they want a second look at something. And in fact there was a successful petition to have the Board of Trustees receive that policy as a Recommended Draft Policy rather than allowing it to revert and go back to the beginning as Draft Policy status.
So it went from the AC to the Board as Recommended Draft Policy after petition. And the Board of Trustees had to consider it carefully. The Board of Trustees looked at it. We provided materials, briefing the Board regarding how the policy did or did not qualify, the issues involved and its consideration. And the Board of Trustees decided in the end to adopt it.
This is the first time we’ve had a policy petitioned from Last Call to the Board and the Board of Trustees as a result of that petition decided to – and the qualifications of the Recommended Draft Policy – decided to adopt it. And it has been implemented. Next slide.
It changed the criteria such that organizations that were removed were put back on the list. There were 17 eligible organizations when ARIN 2020 was adopted, and – next slide – I think we can report all of them have been done.
There were 17 request tickets initiated by ARIN staff. All 17 were filled. And that temporary section that was adopted has been retired. Effectively the prior policy implementation is complete and all we did was implement it as per this updated text.
So, we’ve had a successful policy, the policy has been implemented, and now actually the section it is defined in is retired. The new NRPM was issued in mid-March.
Next slide. Just to point out, petitions in the policy process, this is the section under which it was petitioned. And it required support of at least 25 different people from 25 different organizations which was met, which was how this policy ended up going to the Board.
And I’ll now take questions on ARIN-2020-2.
Paul Andersen: Questions for the presenter in this interesting format.
John Curran: Any questions?
Paul Andersen: We have to give it a second, because sometimes there’s a lag if people type.
It appears there’s no question, John. Thank you for the presentation.
John Curran: Okay. And again –
Remote Host: I’m sorry. We have one question.
Paul Andersen: See, you try to leave that time but it takes extra time. The question.
Remote Host: Chris Woodfield from Twitter: Is there a record of the allocations made under this policy?
John Curran: Yes, there is. The record of the allocations made under the policy are actually the same as all issuance from the waitlist. So parties can – who look at our daily stats, we have issued file. They can find the issuance that occurred of these blocks.
We haven’t called them out or distinguished them in any manner because, as it turns out, this is – there’s obviously privacy issues involved. Everyone is – we don’t publicly disclose or call out specific allocations, but the data is in our normal reporting.
Paul Andersen: I know you were presenting on that, so I’m just going to say there’s been a breaking development here.
We’ll go to ARIN-2020-6 next, which is the Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers, to be presented by Amy Potter.
John Curran: Very good. Amy?
Paul Andersen: We thank Amy. Owen had a sudden emergency. So, Amy is stepping in here. So please be kind. And, Amy, whenever you’re ready, start your video and take it away.
Draft Policy ARIN-2020-6: Allowance for Ipv4 Allocation “Swap” Transactions Via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers
Amy Potter: Sure. So 2020-6 is a policy that deals with what we’re calling swap transactions. It’s something that has been occurring – that Registration Services has been allowing – but has not been codified in policy. So, we’ve been going back and forth on how exactly we should include that in NRPM.
Basically what happens is you have an organization that has a larger block of space than they really need. Say they have a /16, for example, but they’re really only using maybe a /19 or so of it, so interspersed throughout the block.
What happens is an organization that has a need for an entire /16 comes and if they have some extra space lying around or if there’s another third-party organization that has an amount of space that’s appropriate for what the organization that’s holding the /16 has is that organization will receive a transfer of a smaller block, renumber under that smaller block and then transfer the larger block to an organization that actually has need for that space.
If we can go ahead to the next slide.
And next the slide after that.
And basically this policy enables more efficient utilization of space and allows for single prefixes to be announced rather than a bunch of smaller pieces being in the routing table.
Next slide. So we’re still working on the current text. We’ve gotten some feedback from the community, but it’s sort of tapered off over time.
In this meeting we’d really like to have some feedback on a couple of key points so we can figure out exactly how to modify the text to make sure it fits with the desires of the community.
Next slide, please. So there are sort of three main issues that are being considered right now. Right now there’s a question of whether or not there should be a cap on the size of the smaller block that’s received in the swap transactions. So this is the smaller block that the organization that’s holding too much space would receive transfer of – renumber onto that smaller block and then transfer out the larger block.
Some numbers that have been thrown around for that are a /19, a /18, or just making that based on needs justification. The way that would work out is if we just ignored the utilization of the larger block they’re not fully utilizing because they’ll be transferring that out anyway. And then base the size of the smaller amount of space that they can receive on what they otherwise would have been able to qualify under needs policies.
Then the other issues that we’d like feedback on is whether there should be a cap of time that organizations have to finish the renumbering project and swap out the space.
We’ve been looking at 12 months, 24 months or no cap at all and just sort of leave that to the parties that are involved in that transaction to deal with that outside of ARIN.
And finally, should there be consequences for a failure to complete the swap? There have been some concerns expressed about the potential for abuse here.
So one thing that’s been thrown out is whether or not ARIN should revoke the smaller block that was received if they don’t complete the transfer in a certain period of time.
Or if anyone else has some other ideas about what they think would be appropriate here or if you think it should just be left to the parties to deal with, we’d like to hear that as well.
Next slide, please. So basically just –
Amy Potter: We’re basically just looking for some feedback on this question. So, we would love to hear from the community on their thoughts here.
Paul Andersen: So, thank you, Amy. Let’s move back to the slide. As well some great questions. This is a Draft Policy, not Recommended Draft Policy. If we were in the in-person meeting, I’d be showing ARIN policy and saying we’re only up here in the policy process.
So this is still early, and the kind of feedback, for those new to ARIN is, any feedback is great, even just that specifically focusing on the problem to be solved. So the problem statement: Is this a problem that you think the AC should continue to work on? That’s great to have.
Or if there’s any feedback you have on these specific considerations that Amy has raised in the presentation. That’s also. So please use the Q&A function or raise your hand, and we will start to form a queue here. And we’ll have a discussion as long as we have comments.
So let’s go to our first Q&A then.
Remote Host: First question comes from Kevin Blumberg with The Wire: A percentage cap would be much simpler. Time limit is required as it seems like a logical abuse vector.
He follows it up with: That should be between the parties regarding policy. The receiving organization should fall under having received a transfer and not eligible for standard length.
Paul Andersen: Thank you for that, Kevin. As a reminder, when you’re typing your question, your name is automatic but your affiliation is not. And some of them we do know, so we do fill them in. If you could try, please put your affiliation. We’d appreciate it.
Next comment, please.
Remote Host: Mike Burns says that penalties should be no further transfers until the swap occurs. And has a follow-up question: Does the large block request this prior to a transfer? Can they do it as part of a pre-approval?
Paul Andersen: I don’t know if Amy wants to or staff wants to address that from an interpretation standpoint.
John Curran: John?
Paul Andersen: Go ahead, John. I can’t see you, John, so I’m not sure. Go ahead.
John Curran: I was asking John Sweeting if he wanted to comment, but.
Paul Andersen: John Sweeting I think will answer them.
John Curran: I’ll –
John Sweeting: Go ahead, John.
John Curran: Okay. Does the large block request this prior transfer or can they do it as part of a pre-approval? Is that the question?
Paul Andersen: That is the question.
John Curran: Okay. It’s interesting – the ultimate answer is going to depend on the final language. If it’s desirable that they be able to pre-approve it that way, we’d need to know about that because clearly a swap changes the nature of the approval.
If someone is going to do a swap, we don’t want to count the space being swapped as part of the approval process. So I would say they could pre-approve a transfer with a swap but pre-approval that doesn’t involve one may not be applicable.
Paul Andersen: It does sound, though, John, that this would be a good thing for the AC to consider getting clarity on so there’s no interpretation problems down the road.
John Curran: Right. Very much so. This is a complicated – there is also a question of importance here.
This is a complicated introduction of process that can fail on multiple parties. So we need to understand how important this is to have a policy of this effect.
John Sweeting: And this is John Sweeting. I want to point out, though, that the pre-approval – I think they’re talking about pre-approval, a different type of pre-approval, because pre-approval usually comes from the recipient. And it would be the source that actually wants to get a smaller block to be able to release a larger block.
So it would be a totally different process there, I think, for pre-approval. But it depends on when this becomes to staff and legal – I don’t believe we’ve done a staff review on this yet, have we, Amy?
Amy Potter: You did have a previous version, but we’re still playing with the text based on feedback.
John Sweeting: You’ll want to get that back in front of us after this meeting.
Paul Andersen: Just for the record, Mike Burns, thanks for adding IPTrading is his affiliation. So thank you.
We’ll take our next question. Then we’ll go to the question, please.
Remote Host: All right. We have Andrew Dul with 8 Continents Network, ARIN AC: I don’t support the policy as written. I would suggest removing the option of using waitlist space as part of a swap.
Paul Andersen: Okay. Thank you for that, Andrew. And thank you for plugging that. And I’ll ask our question person to give me the next one because there’s a bit of misorder. I’ll leave it to you to take which one.
Remote Host: I believe it’s Mike Burns again: My understanding is the needs test for the small block is avoided if the policy is chosen. Does the buyer of the large block have to be identified in advance?
He follows that up with: I want to get a small block, avoid the needs test and get pre-approval to sell.
Paul Andersen: I think that’s feedback we have to take on – Amy, I don’t know if there’s – is that clear?
Amy Potter: I think what we were thinking in terms of the smaller block is that there would still be a needs justification process in place. It would just either – it might have a cap on the maximum size, but it wouldn’t just be an automatic sort of approval for the smaller block. Both sides would be completing any needs justification.
On the smaller side, it would be either capped at, say, an /18 or /19 or just be capped at whatever they would otherwise have been able to establish via needs justification.
Thank you for that. Next question. Next question.
Remote Host: Next question is from David Farmer, University of Minnesota. I support the concept of the policy. I suggest a percentage limit, like no other transfers until completed. I’d like to see pre-approval of a swap be part of the policy.
Amy Potter: Could I ask David a question?
Paul Andersen: Yes, you can.
Amy Potter: Would you like pre-approval as a requirement. And if so, how does that differ from normal justification that you would engage in when going through a transfer? How would you like to see that differ?
Paul Andersen: David, if you could take a moment, type that response, we’ll pin that, come back. Let’s go to Wendy’s question.
Remote Host: Wendy Leedy, with Amazon Web Services: Block size should be based on needs with a 24-month time cap. There shouldn’t be any consequences from ARIN for failure to meet this time cap.
Paul Andersen: Okay. And we’ll do Mike’s question. I don’t think we’ve done Mike’s question yet. Mike, I’m having a hard time – sorry. Mike, you had a question, I think two points: How can I justify with a largely empty /16, I can’t justify 50 percent?
John Sweeting: I can take that real quick. Basically you would have to show the need, but if you were wanting to get a /22 so that you could free up the entire – your entire /16, you’d have to show us how you’re using that /22 currently. That would be the need. It wouldn’t be 50 percent of the entire /16.
Paul Andersen: Okay. Thank you for that one. That’s still the original question. Can we take our next question, please.
Remote Host: All right. Next question is from Gary Giesen, CentriLogic, ARIN AC: Undecided whether I support the policy, but I support its continued development.
One, I believe a reasonable cap is required until more experience is gained with the policy, should it be implemented, to reduce risk of abuse, which I believe this policy might be prone to. I think a /19 is reasonable. Renumbering out of anything larger than that and any reasonable timeframe may be painful.
Two, I believe this should be a time limit. I think 24 to 36 months is reasonable. I believe, three, that some reasonable consequence should occur for failure to complete the transfer. At a minimum, revocation of a smaller block or even the larger block.
Paul Andersen: Thank you for that feedback, Gary. I think David has given his response now. So can we go back to that.
Remote Host: Absolutely. David Farmer says: I think they have to notify ARIN that they want to make a swap. Otherwise, any time cap is meaningless.
Paul Andersen: Okay. Thank you. The questions are coming in fast and furious on this one. So let’s take our next question or comment.
Remote Host: All right. We have Mike Burns again with IPTrading: My problem is how the small block is justified if the large block is empty.
Paul Andersen: John Sweeting, did you want to address that?
John Sweeting: Mike, if you’re using no IP addresses at all, it would be very difficult to justify that you need to keep – that you need to get some so you can sell the ones you aren’t using.
Basically I think – I believe this swap, the purpose of it is for people that are using a smaller piece of a larger block want to get that smaller piece first so they can renumber out and then sell the larger block.
So if you’re not using any of that larger block, there’s no reason to get a swap that could –
Paul Andersen: Mike indicated a second ago his question was answered and it was just the way the questions come up here. I just want to make sure they’re addressed. He said you addressed that previously.
There’s somebody going by the name Holden. Give us your full name. We’ll get to your question soon, but it didn’t come through correctly. Let’s go to the next comment or question. Chris Woodfield.
Remote Host: Chris Woodfield, Twitter: My take on Mike’s question, I think, that may depend on the velocity of the market. Assuming there’s reasonable expectation that the party will be able to find a buyer within a certain period of time, then I don’t feel that the buyer needs to be identified.
Paul Andersen: Thank you for that. Next comment, please.
Remote Host: Gwen Newton. Not allowing transfers until completed may cause issues for other transfer needs for 2XL organizations.
Paul Andersen: Thank you. We’ve got about 10 more minutes. Feel free to ask your question or raise your hand if you would like to speak in real time. Let’s go to our next commenter.
Remote Host: Next commenter is Tina Morris with Amazon Web Services. I’m in favor of formalizing the process. This allows for large aggregated blocks to stay intact and be used by organizations that need space rather than sitting unutilized.
Paul Andersen: Thank you, Tina, for your feedback. Our next one is from Holden Carrillo (phonetic). I’m sure I botched it. I apologize.
Remote Host: I’m really curious about what folks see and potential avenues for abuse. And Holden is with Pigs Can Fly Labs, LLC.
Paul Andersen: Very amusing entity name. If people have comments on some of the abuse, I think it’s relating to some of the chat. The discussion in chat is not going to make it into the meeting. If you want to give an examples of that, we’re happy to have them. We’re, however, out of questions or comments. I’ll give a last opportunity for people who want to raise their hand to speak or ask a question.
Amy, anything you’d like to add or further comments? Again, noting there’s the three considerations that she raised, which I don’t think we really got too much feedback on some of them. So perhaps that could be –
Amy Potter: We’ll send out a note on PPML as well, if you would like to think it over, provide feedback later. Any feedback you like would be appreciated.
Paul Andersen: You always have the forum to contact the shepherds which in this case are Owen DeLong or Amy Potter, or approach any member of the AC offline or you can send a message to the ARIN Public Policy Mailing List, which I’m sure you’re all subscribed to.
However, seeing that there’s no one else responding, I’ll make one final call, then we’ll close the virtual queue and move on to the next policy.
We’ll give it a couple more seconds because every time we try to cut it off, it seems to be one second too early.
While I’m waiting for this, I want to thank you, Amy, for literally stepping in at the last minute. 30 seconds to go for the presentation.
Hey, Amy, can you present a presentation? So thank you for playing the role of Owen DeLong today.
We appreciate that. We’re all virtually give our thanks to Amy for the great presentation. The microphone is now being closed.
This is a Draft Policy, and there’s been no poll requested. The feedback that has been raised will be passed on to the AC. I think John is going to introduce us to the next presenter. Thank you, Amy.
John Curran: Thank you, Amy. Thank you, Paul, for your able moderation. Our next policy up is Recommended Draft Policy ARIN-2020-7: 4.4 gTLD Micro-allocation Clarification.
Alicia Trotman is the AC shepherd presenting it. Because this is a Recommended Draft Policy, I have a staff introduction that I will go through. Recognize that this policy could potentially be adopted after this meeting and become part of the Number Resource Policy Manual, the NRPM.
Without further ado, staff introduction: Shepherds Alicia Trotman and Joe Provo. ARIN proposal 290 was submitted on 3rd June 2020.
On the 23rd of June it was accepted by the AC as a Draft Policy, which means the AC found it was – it had a description of a problem to be solved. They decided to work on it.
Things that are completely outside the scope that the AC can set aside as being outside of the scope. They found it as within the scope of the policy process, accepted it as Draft Policy.
As a result of the discussions with the community, it was revised on the 14th of July 2020.
It became a Recommended Draft Policy in November. This occurs after the Advisory Council is sure that it is technically sound enables fair administration of number resources and has the support of the community.
It was presented at ARIN 46. And now it’s back before us at ARIN 47. Next slide. Problem statement. As stated in 4.4, Micro-allocation, the current section of the Number Resource Policy Manual, ICANN-sanctioned gTLD operators may justify up to the equivalent of a /23 block for each authorized new gTLD allocated from the free pool or received via transfer but not from the above reservation.
The phrase “new gTLD” is confusing and refers to all gTLD deals that have been created since June of 2012. But we don’t say that, we say “new gTLD.” That’s the problem statement.
Next. So our understanding of the proposed change is we remove “new” from “new gTLD” which takes the policy that’s back in 2012 and makes it a little clearer. It is absolutely clear and understandable and doesn’t pose any particular problems.
Next. No material legal issue. The legal assessment and resource impact, very straightforward. Could be implemented within three months of ratification by the ARIN Board of Trustees. We would update, of course, our training and our guidelines and the standard documentation the community uses.
Okay. Next, no feedback within the PPML in the last few months. At this point I’ll bring the staff introduction up. Next slide. Alicia, thank you.
Recommended Draft Policy ARIN-2020-7: 4.4 gTLD Micro-Allocation Clarification
Alicia Trotman: John pretty much said –
John Curran: Said the whole thing, yeah.
Alicia Trotman: It’s a pretty simple recommended policy. Just to add there wasn’t any activity on PPML for a few months. But recently since the slides have been created, we did have some positive feedback. So that I can add to this.
And I would open up for any questions or discussion at this time.
Paul Andersen: Microphones are now open for any questions or comments on this proposal. We have about 15 minutes allocated, yes, for any questions.
Please make use of the Q&A functionality. Please raise your hand if you would like to speak.
Again, just for this because it is the first Recommended Draft Policy of the conference, this is much farther ahead in the process than the one we just had, which was Draft Policy.
As John said earlier, this is the last time you may see this policy.
And I don’t want to say Last Call, because we have that too, but it could potentially be the last opportunity in open forum like it was discussed.
It’s very important to either write your support, we already have one person that’s done this, or opposition. If you’re opposed it’s helpful to have any reasons that you have that.
But it’s really important because the AC will be after this meeting effectively trying to decide whether or not to move this policy to potentially the final stages.
With that preamble, we don’t have a lot of comments. We just have the one from Kevin Blumberg of The Wire who says he supports the policy as written.
Does anybody else want to give feedback? We’re starting to get feedback. Can we have our first feedback item?
Remote Host: Martin Hannigan with ARIN AC: I believe I authored this one back then. The change is totally consistent with intent. In 2012, there was a new gTLD program, e.g., pro.co and such. It was indeed all new and unknown. The language was best. Now it’s a decade later and they’re not so new anymore. My apologies, not the AC, the ASO AC.
Paul Andersen: Formerly of the ASO AC. Thank you, Martin, for that. Other comments or questions? We have time to do this. I don’t want to rush. But we’re also lacking any voluntary here in the official channels.
Go ahead for our next comment.
Remote Host: Frank Bulk with FiberNet Communications and Premier Communications: I support this policy as written.
Paul Andersen: Thank you, Frank. Other comments or questions? Give it 30 seconds. Because seems like every time I did give time we had a comment come in late on the last one which we directed that person to the PPML.
We will close the microphone, virtual microphones, if we don’t start seeing substantive comments probably in the next minute. Let’s go to our next comments.
Remote Host: Holden Carrillo says: I support the policy as written.
Paul Andersen: Thank you. Next one.
Remote Host: Gary Giesen with CentriLogic, ARIN AC: This policy is straightforward and uncontroversial. I support it as written.
Paul Andersen: Thank you. Okay. The microphones will close in 30 seconds. So please put your last comments in.
Seeing none, the microphones will now close. I’d like to thank Alicia for her presentation. Albeit brief. And we are now going to take a poll as this is a Recommended Draft Policy.
First, I’ll ask is our full team armed and ready?
Remote Host: We are ready.
Paul Andersen: Thank you. So we are going to make use of the Zoom polling functionality. You got warmed up during the break, hopefully. So the question that we’ll ask is are you in favor – it’s right there. Are you in favor or against recommended policy 2020-7 as written?
So if you can use the poll, please use the poll and respond now. Anybody who can hear my voice or is part of this is able to respond.
If for some reason you’re having a problem using the poll mechanism, please use the Q&A mechanism, either say in favor or against. But only if you can’t make use of the poll functionality for some reason. I know there’s been a few people with some clients that don’t work on that.
Just give time here for the poll to close. Another 30 seconds or so.
Remote Host: Give a full minute total?
Paul Andersen: We’ll give some –
Remote Host: We’ll wait.
Paul Andersen: Normally if we’re at the in-person, which I do look forward seeing many of you again in person at these events, I hope you’re all staying safe. Up here in Ontario, Canada, we’re all back in lockdown. Not looking like that anytime soon. Isn’t this where we’d have a joke or banter or John would sing a song?
I don’t know if you know this, but John is an accomplished singer, opera singer, I hear.
John Curran: Opera or awful?
Paul Andersen: Like I said, it’s one of the jokes. Okay. The poll now being closed, I will ask our poll collectors to give us the results.
Remote Host: Good news this is a easy one to do. At the close of the poll there were, apologize, 120 attendees; 47 voted in favor, zero against.
Paul Andersen: This feedback will be presented to the AC for their consideration. Thank you very much. And we’ll move on to the next proposal.
John, you’re going to introduce the next speaker? No, we’ll not have a poll in favor of having John Curran sing. He’s got to be in the moment. He’s got to feel it.
John Curran: I’m not feeling it today.
I did actually, though, get some time at the mic I probably shouldn’t have had. I realize now with the virtual format Alicia should have presented the slides for the last presentation. And but now I’ve caught up with the new virtual format.
So as such, my role here is to introduce Joe and then turn it over to him.
Our next presenter is Joe Provo. He’ll be presenting Recommended Draft Policy ARIN-2020-8: Clarify and Update 188.8.131.52 Annual Renewal Fee. With that, Joe, take it away.
Recommended Draft Policy ARIN-2020-8: Clarify and Update 184.108.40.206 Annual Renewal Fee
Joe Provo: You don’t need to see that I’m going to take a page from Mr. Curran and speak a little slower than I normally do.
This one is similar to the previous policy: Relatively straightforward. Not nearly as brief. But we can just go to the next slide and we’ll get started on it. It’s got a long title because it has a little bit of history.
It came from the Policy Experience Report that the staff generates. If you tuned into the meeting earlier today, you would have heard Lisa give us this meeting’s Policy Experience Report where things regarding implementation challenges confusing bits to ARIN customers and members of the community get raised.
Basically the experience that the staff has implementing a policy such that we on the AC can factor that into adjustments finessing and so forth.
This has already been presented at a previous meeting. It’s had a little bit of text massaging as we’ve gone.
Similar to the previous policy, it is a recommended draft. So all the admonitions that both John and Paul have given previously regarding this may be the last time you see it in a public forum, and I’m sure Paul is going to say it again.
That all applies here as well. Next slide, please. So the staff and legal comes from the most recent iteration of the text. Raise no significant issues.
Basically we’re striking a section that refers to fees in 220.127.116.11. In general, we have a separation between certain areas in ARIN operations and policy.
Basically all things, financial fees, fee schedules, that’s all the purview of the Board and does not belong in policy. Policy is purview of the community. And we on the AC help implement that as your voice.
Therefore, this was sort of a conflict and created some confusion. The intent here – next slide, please – is to make this relatively minor change. You see there’s no issues on the staff and legal.
So next slide, please. This is a summary of the problem statement. I gave a preamble. This formally came from our Policy Experience Working Group within the AC. As indicated, the fees are not considered to be part of policy.
And we – next slide, please – worked through making adjustments in a previous iteration. And after some examination and consultation with the community, it was decided that the entire Section 18.104.22.168 should just be struck because it only talks about fees and repercussions.
And a highlight here is that when we took this new definition to be added to 2.x, a sharp-eyed member of the community noticed the typo for “contractual.”
In general, should typos get past the AC, community and the Board, they get cleaned up by staff at implementation. That shows someone read it in detail. We like that feedback.
I’m just not going to regurgitate what’s written here. I’ll give you a moment to read through it, in that we’re simply declaring an RSA exists as by the scope of this document. We’ll refer to it in multiple places.
Next slide, please. Again, we got a pointer to the typo. Some discussions regarding legacy resource allocations that neither the staff nor legal, nor the President of the Board had – hi, Chris – had indicated were issues.
And so this last iteration of text only had that feedback from one person. So the question is: Do we not have community support or is it just too straightforward?
So next slide, please. We’re on to the discussion. And we’d like you to tell us how to proceed, and I do want to raise the point that we have a few other references simply to RSA within the NRPM. So this kind of plugs a hole where those are sort of loose, untethered references, and with the hat of being on the NRPM Working Group, we’ve been looking at a lot of these things as holistic changes as well.
So they’ll probably – if this goes forward, they’ll probably fall out to be some additional shoring up to make sure any of those references are in line with the new definition. Thank you.
Paul Andersen: Thank you. And NRPM, by the way, for you is the short form many of us who have been around too long refer to the Number Resource Policy Manual that we like to call NRPM for short.
And Joe is quite correct. I want to remind it is very important to give the feeling of community support right now because this is the last opportunity you may have.
It may come back, obviously, but it could proceed to the Board without another in person or virtual meeting.
So with that, I open up our comments and microphones. Questions for our presenter, for staff on this.
Again, it’s a fairly straightforward one, but that does not mean that the feedback – even just saying in favor or against is very useful to the Advisory Council. And then as this is a Recommended Draft Policy, we will have a poll. That’s about all the filler I can give. We’ll wait for some Q&A.
If we don’t get Q&A, we’ll threaten you with John Curran’s opera singing.
Questions, comments, favor, in against.
John Curran: It makes me wonder whether we need to have less finely crafted policy, because really well-done policy raises no comments as does policy that no one’s interested in whatsoever.
Yet, if you have a defect, you’ll get some comments. So perhaps next time around, Joe, you can insert a defect and we’ll at least hear from people.
Joe Provo: I’ll add more than just typos next time.
Paul Andersen: It is one of the comments we commonly get in organizations is if hear nothing, you must be doing something right; because, trust me, you’ll hear about when you do something wrong.
But our banter between the three of us raised three shows of support. David Farmer, University of Minnesota: Support as written.
Gwen Newton, DXC: Also in favor.
Louie Lee of Google Fiber is also in support. So thank you to those three.
We’ll give another 30 seconds for people. And again, I’m not trying to rush anybody. We need to give some feedback.
It’s all coming in. Frank Bulk, FiberNet Communications, Premier Communications: In support.
And Donnie Lewis, no association, also supports as written.
Gary Giesen, CentriLogic, ARIN AC, supports.
Is there anybody who would like to give a reason why they would oppose this either by raising their hand or give a comment? That would be helpful.
We now have also Kate Gerry of NetAcute – I don’t know, I’m pronouncing that wrong, Kate, I’m sorry – is in support. And John O’Brien, University of Pennsylvania, also supports.
John Sweeting: Maybe NetActuate.
Paul Andersen: NetActuate. That’s what it said. I don’t know why my brain couldn’t process that.
Danielle Carroll, University of District of Columbia, also supports as written.
Going once. Give it another 20 seconds. It seems to come, the seas have calmed. And we’ll go to our poll.
So I note, only because I’m looking at the chat and it will close, as I see some people putting in support in the chat. If you could put that in the Q&A.
I will – just Brian Jones of Virginia Tech – put that on your behalf, this one. Just so we close off, but make sure to put that in the chat. There we go, Brian put it up officially.
Okay. With the microphones now closed, we thank Joe for his presentation. We will now go to a poll. So again same as before. We are looking for anyone to give us their feedback on whether they believe this proposal as written is something that can move forward or cannot.
If we could have our poll. Are you in favor or against Recommended Draft Policy ARIN-2020-8 as written. Please either indicate in the poll or use the Q&A function.
Only if you are technically unable. Please do not use the chat. We cannot poll the chat. Another 10 seconds here. Looks like we started off. Can we get the poll results?
Remote Host: Yes. The polls are closed. At the close of the poll, there were 118 in attendance; 41 voted in favor, zero against.
Paul Andersen: Thank you. This feedback will be provided to the AC for their consideration. And we will go on to the next presenter, which is me.
Public Policy Meeting, Day 1 - Open Microphone
Paul Andersen: We’re going to Open Microphone. John, don’t go away. It says it’s me, but it really is – this is – so the technical thing is the Open Microphone at the end of the day is for anything you’d like to raise, maybe something that’s just come up on a policy that you’ve seen.
You have an idea for new policy, and you’d like to get feedback from the community. Or anything else about ARIN. We generally like stuff about ARIN, the organization, to be on the Members Meeting day, but we understand that if the attendance doesn’t allow. We’ll try and entertain the best.
So either raise your hand if you’d like to speak or type a question or comment or topic that you’d like some feedback either from the Board, the AC or John, who is here, or staff.
We have 10 minutes allocated. Sometimes these can be barn burners; sometimes we get not much. So we’ll see if there’s any topics.
Just a reminder, we have two more exciting days of ARIN policy. We are running a bit ahead. Appears to be you all are so content. As John said, we’re apparently crafting such good policy, such good process, this goes to a testament of the AC and staff.
But I guess if there’s no other questions, going once, twice, three times. Okay, maybe what we’ll do, I’ll start – because I’m also doing the closing announcements – if there’s really a burning question, show it in a few seconds, I’ll answer it. Otherwise, let’s go to closing announcements.
Public Policy Meeting, Day 1 - Closing Announcements and Adjournment
Paul Andersen: If I could have my slides, please. Thanks again to our Bronze Sponsor, who not only sponsored but gave a great keynote speech. We’d love your feedback on that. That’s a new item we’ve put in to change a bit up the format in the virtual. If you have feedback, let the teams meeting staff know on that.
Next slide please. This is day one of three. We start at the same exact time tomorrow, noon Eastern. Day two has more policy global reports. We’ll hear from four regional registries and I* organizations to get an indication what’s going on. We’ll get an update from our governmental affairs.
One of the benefits of the virtual meeting is that our government affairs team that’s generally always on the road and never able to come to our virtual meeting, can come and speak. I’d love to hear that.
Next. And you can join us for a do-it-yourself happy hour. Bring your own snacks, beverages, tour of a selection of destinations and catch up with some friends.
Again, we’d all like to see you in person soon, but we’ll have Adam “Squirrl” McClintock for a live cooking demo. A link to the event is on the agenda. We’ll give it right below. It’s in the chat now as well.
Okay. Next slide. Again, just the link to that form. It’s now in the meeting chat or at the bottom of the agenda.
And last slide, I think, is next.
Remote Host: That actually is our last slide and we’re going to leave it at that slide.
Paul Andersen: We’ll leave it so we can see it.
Remote Host: So they know how to get where they’re going. They’re all set.
Paul Andersen: Since there’s been no questions on Open Mic, we’ll adjourn the meeting for the day.
We’ll call the meeting back to order at noon tomorrow Eastern. But we, of course, ask you all to come join us for happy hour at 4:15, which, apologies, we’re running an hour early. Beverly, are we going to keep that time stick?
John Curran: Yes, 4:15.
Paul Andersen: You get an extended break and hopefully we’ll see many of you in just over an hour. Thank you, everybody. We’ll see you tomorrow again.
John Curran: Thank you, everyone.
Paul Andersen: And stay safe.
(Meeting adjourned at 3:15 PM.)