ARIN 46 Public Policy Meeting, Day 1 Transcript - Wednesday, 14 October 2020 [Archived]

Public Policy Meeting, Day 1 - Opening Announcements

Paul Andersen: Good morning, everyone. I say “morning” even though for some of us it’s now afternoon. Welcome to ARIN 46, our second virtual policy meeting here. Regrets of course we could not all be assembling in Seattle where of course it would still be morning.

Of course, world events have prevented that. But I’m very proud of the work by our Advisory Council and staff who worked tirelessly to bring this format to you.

As I mentioned, it’s the second of our virtual meetings. The first one, as you know, was put on shorter notice. We kept to a much more simplistic form just getting policy through.

But we’re hoping this one brings a lot more of the spirit and community that we’ve grown to enjoy at our various meetings throughout the region.

So without any further ado, I’d like to welcome you all and go over a few housekeeping – next slide, please.

So for those that are new, first, welcome. Welcome to ARIN. This is an open community, which is represented by a large number of volunteer community leaders.

My name is Paul Andersen. I’m the Chair of the Board of Trustees. And listed here in attendance are all my fellow Board Trustees. Your Board is charged with overseeing ARIN as the organization and ensuring that we are responsive to you, the community, in ensuring that we manage the resources on behalf of the community.

Next slide. We’re here – the main topic today is to talk a lot about number policy. That’s led by an amazing group of volunteers listed here which is our Advisory Council – 15 members, volunteer as well – a group that is responsible for shepherding policy through our open, consensus-based, and bottom-up policy process. And my thanks to all of them who have put in countless hours to make these meetings a success.

Moving on. We also are today joined by our NRO Number Council, the Number Resource Organization Number Council. These three elected, and again volunteers, represent you at other RIR – ICANN Coordination Number Council, which shepherds a variety of responsibilities including the shepherding of global policy for coordination and also picking the representative for regions to the ICANN Board.

Next please. So let’s talk a little bit about how we’re going to have to do things a bit differently. Normally we’d be at a podium, all of you in the audience. We’d be enjoying tasty cookies provided. Unfortunately, this time you had to cook your own, but there’s a great recipe provided. Hopefully you all had a chance to try those.

We’ll be using Zoom. I suspect many of you, this will not be your first Zoom call if you’ve been around for a bit, but maybe your first Zoom webinar, which is slightly different in a few respects. Next slide, please.

So there is a chat that you got that you can make use of. The chat in this setting is to represent the hallways and such so that you, the community, can speak to each other, ask questions and just get to know each other.

Please note that everyone, and just over a hundred of you, now will see everything on that chat and you’re free to use that. But please note that’s not on our official record.

Next please. Again, if you want to talk with all the attendees, please select that. If you would like to ask a question of the staff, just check all panelists that will go to a group behind the scenes that is running the meeting for us.

Next, please. Just a few reminders. The chat, please always stay professional. Please try and keep on topic. And discussion of policy, chat can get feverish. If there are discussions off topic, it can be quite difficult. As always we request that all attendees and any interactions, especially chat, follow the ARIN Standards of Behavior. That can be located on our website. I’d ask all of you to review it if possible. It’s very important that we all treat each other with respect and professionalism in this regard.

Next slide, please. So this meeting, we’ll have the code we’d have for those in-person on the floor. If you wish to speak on the floor you have two ways.

The first is to use the Q&A panel. If you click on that you’ll see the question box come up. You can then click the – type in your question. Your question will be queued among other participants and it will be read by either myself or one of the staff assisting me at the appropriate time.

Because this is a virtual meeting and it can take a little bit of time, feel free to ask questions anytime during a presentation, but note that in most cases we will wait for the appropriate microphones to open for you to say that.

Next, please. And if you would like to speak in the more traditional way, you can click the raise hand. That will be indicated to our staff. And when the microphones are open for or the queues are open for people to speak we will call on you one by one. You’ll be, just to note, you’ll be given an invitation when it is your turn to unmute. So please make sure that you do unmute so that you can be heard. And then you have the floor to make your statement or question as you want. Again, please, as always, being professional in following our standards.

Next, please. As the Board Chair, I’ll be moderating all discussion of policy. We ask that you limit your comments to germane comments to the proposal on the table.

Please always, every time, even if you are a long-time member of this community – to clearly state your name and the affiliation that you’re speaking of when you’re recognized to speak, or please include that in the question and answer. That’s very important because as a reminder this meeting is being webcast. This meeting is also – a transcript is being kept and we just want to make sure that the record is complete.

Moving on, to give you an idea of the attendance breakdown, at least where people have indicated. The bulk is always in the United States, but we have 15 people from the Canadian region, 136 from the United States, five from the Caribbean, and 15 who are outside the region.

Next, please. Slides are available on the website at the URL below. A transcript in real time is available as well. And my apologies always to the transcribers, I will try to remember to slow down.

We are, of course, recording this event and it will be also available for live streamers.

So that’s the process and procedures, so we’re going to get going on the day.

First thing we’re going to do is do a bit of a give-away. We had a Newcomer Orientation via Zoom as well last week which allowed people to see selected representatives on staff and learn about ARIN. We are giving away a $100 Visa gift card. And the winner is – and you must be present to win – Richard Wagner. I’ll go up to my internal and say do we know if Richard –

Zoom Host: Richard is not on the call, so can you pick a number between one and six – I’m sorry – one and eight, or would you like Owen to do it?

Paul Andersen: I think I should pick a random – I’m going to look – a random participant from the list. I’m going to pick Owen DeLong. Can we open Owen’s mic?

Zoom Host: Owen, can you pick a number between one and eight, please?

Owen DeLong: Three.

Zoom Host: Our winner is Nia Brown. She’s with us. Our winner today will be Nia Brown.

Paul Andersen: Congratulations, Nia. Thank you very much for that.

So moving on to our agenda. We have four recommended draft proposals for consideration today, which will be in the format of the two days that we have here. We’ll be effectively starting with proposals and then go to presentations. And then next week we’ll have our Members Meeting. Today we’ll have three proposals you see here before our first break – 2020-1, -2 and -3.

Next slide, please. And yes, I understand apparently I might have a bad microphone. During the first presentation I will try and go figure that out.

We’ll have one presentation after the break. And then we will have a presentation on our Grant Program, Registration Services Department statistics, an update from Mark Kosters on routing security and services update. And we’ll end the day as a group with an open microphone which allows anyone to come and raise a topic of their choosing that’s been discussed today or perhaps a policy that they’ve thought of during that.

So that will end the formal agenda. There will also be some breakout sessions after the formal sessions and we’ll talk about those a little bit later.

So with that, I’m going to ask Chris Tacit to come up and present the first Recommended Draft Policy, ARIN-2020-1: Clarifying the Holding Period for Resources Received Via 4.1.8 Waitlist. Chris, you have the floor while I go find a better microphone.

Recommended Draft Policy ARIN-2020-1: Clarify Holding Period for Resources Received via 4.1.8 Waitlist

Chris Tacit: Thank you very much. I gather the way this is being done is I’m going to do the stuff that normally staff would do first as well. Is that right?

Paul Andersen: That is correct, Chris, the floor is yours.

Chris Tacit: So if you could go to the next slide, please. So here’s the history of the proposal. All of the activity with this proposal has occurred in the current year. Please go ahead.

This is staff’s understanding of the proposal. Basically those who have obtained an 8.2 transfer would be exempted from the waiting period.

And the remainder of the 60 months would continue to apply to the M&A transferred space after the transfer is complete. And there’s an example provided there to clarify that.

Next slide, please. So staff and General Counsel appear to have no concerns with either implementability or legal issues. And the resource impact appears to be minimal with implementation, implementation of being possible within three months after ratification by the Board.

This is the problem statement, and basically it derived from a Policy Experience Report that identified that the status of 8.2 transfers with regards to either being or not being exempt from the six-month waiting period restriction was ambiguous. So this proposal seeks to clarify that the 8.2 transfers would be exempted.

Sorry. Go ahead. Next slide, please. So the change is quite small to the text of, the existing text of Section 4 .1.8. And you can see it there in the red font, basically making it explicit that eligibility for transfer would not apply to Section 8.2 transfers.

Next slide, please. Despite a few attempts to generate discussion on PPML the volume of feedback has been very low. There have been two or three vocal community members who have expressed concern that the proposed exception would lead to fraud because it’s easy for someone to kind of incorporate a company and create some sort of shammy .2 in order to create an exception.

On the other hand, the counter argument is that people who are engaged in this conduct are going to do it anyway. And we’re better off to have the exception be explicit in order to ensure that people don’t try and use other methods to bypass it. That could reduce directory accuracy.

So that is kind of the two opposite points of view that have been expressed, but as I say, by a very small minority of people. Most people have not said much of anything about this policy.

Next slide, please. Since this is non-recommended draft state, it’s possible that the AC would recommend adoption at this point.

So obviously we would like to make sure that the community has an opportunity to voice any other opinions or concerns it might have with regards to this RDP.

So with that, I guess I’ll turn it back to you, Mr. Chair, and ask if you would ask people if there are any questions or comments.

Paul Andersen: So, thank you, Chris. So first if you have any comments or questions about this, either click the raise-hand button to be put in queue to speak or start typing your question in the Q&A.

This could be potentially the last time the policy is before the community. So even feedback such as in favor or against is very useful to the AC. So hopefully, as Chris said, we’ve had some – a little feedback, we can turn up now. But I don’t see anyone giving any feedback. We’ll give it just a second.

So after this there will also be a poll taken and anyone who – I’ll explain how that works in a second. That will be another opportunity to give feedback.

So I see that Gary Giesen from CentriLogic says he supports the policy as proposed. Thank you, Gary, for that feedback.

Any other feedback?

Okay. Again, just because it’s virtual, I’ll give a 20-second warning here to last call. If we don’t have any hands raised or comments by that we’ll close the comments.

I see David Farmer, University of Minnesota. I support the policy as written.

Give it a few more seconds.

If there are no further comments, we’re going to close the queues. We’ll not take any further comments in the Q&A or the raised hand, assuming I’ve not missed any. I’m seeing, Beverly, if I missed any?

Zoom Host: We’re clear.

Paul Andersen: I’d like to thank Chris Tacit for the lovely presentation. We can all give a lovely clap here. And we will now go to a poll. So this poll is opened to anyone that can hear or is participating in this meeting. And it’s popped up in there.

So the question is: Are you in favor or against Recommended Draft Policy ARIN 2020-1 as written? Please either indicate in the poll that’s popped up in favor or against. If for some reason you’re not able to use the poll – we know some people who come in on the web cannot – use the Q&A section and just say in favor or against and we will ensure they are counted. We’ll give the 30 seconds for everyone to make their decision.

Last call. All right. We’ll close the poll now. And I’ll ask Beverly if you could give us – or staff – if you could give us the results when you tabulate it. It might take a second.

Zoom Host: At the close of the poll, there were 118 in attendance. 53 voted in favor and three against.

Paul Andersen: Thank you. That feedback will be provided to the Advisory Council for their consideration.

We’ll truck right along to ARIN 2020-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16. And we’ll ask Alyssa Moore to give the presentation. Go ahead, Alyssa.

Recommended Draft Policy ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

Alyssa Moore: Hi, can everyone hear me okay?

Paul Andersen: I can hear you.

Alyssa Moore: I’ll assume that means everyone. All right. So am I being given control of this presentation?

Paul Andersen: It’s just easier to say next slide.

Alyssa Moore: This is Recommended Draft Policy Reinstatement of Organizations Removed From Waitlist By Implementation of ARIN 2019-16. Next slide.

This originated – it was first proposed in January of this year. Moved to Draft Policy in March, and the AC moved it to recommended draft in September.

Next, please. It’s undergone Staff and Legal Review and can be implemented as written. Next please.

By way of staff comments, the policy does not create any legal issues and has a minimum, minimal resource impacts.

Next, please. So, by way of background, last year the ARIN Board suspended issuance of IPv4 through what is known as the waitlist in light of some fraud that was occurring with the resources that a few organizations were receiving from the waitlist.

And the Board responded quite quickly once they realized that this was taking place and suspended the waitlist at that time.

And this triggered a process under the Policy Development Process in which the Advisory Council could recommend an updated policy to take its place without going through the full policy process that would normally be undertaken. And that resulted in the removal of some organizations from the waitlist.

Next slide, please. So the new policy that was implemented and is presently in place limits the size of block that ARIN can issue to an organization on the waitlist to a /22. It also places a limit on the total holdings of any party that’s eligible for resources from the waitlist. And that limit is a /20. So an organization must hold no more than a /20 with resources in order to be eligible.

And it also makes any block received from the waitlist ineligible for transfer until a period of 60 months has occurred. And the idea with that is to prevent flipping of resources obtained from the waitlist.

All of this to say that it resulted in some organizations being removed that many of which felt that they should not have been removed because they were abiding by the policy and processes that were in place at the time that they got themselves on to the waitlist.

Next slide, please. So, here I just have a comparison of the old policy and the new policy that is now in place. So the criteria on the left are the ones under which these organizations who were removed would have qualified under the criteria; on the right are what exists now.

And next slide, please. So the problem statement and this Policy Proposal is that the implementation of 2019-16 caused some organizations to be removed from the waitlist that were approved under the old policy’s eligibility criteria, and that these organizations should have been able to stay on the waitlist when it was reopened to allow them to receive an allocation of v4 up to the policy’s new maximum size of a /22.

Next slide, please. So we were able to pull a couple of stats since the last meeting on what the change in the waitlist looked like. So at the time the new policy was adopted, 2019-16, there were 365 requests on the waitlist. So, 37 of those were removed because the organization held more than a /20. So that goes to the total holdings criteria.

79 of those 365 were just adjusted down to receiving a /22. So they may have requested a larger block, but they worked with ARIN to adjust their request to coincide with the new maximum size. So they would have been notified in ARIN Online and they just made that adjustment. And then the remaining 249 were unaffected by the policy change. Next slide, please.

So the remedy to the situation that’s proposed by this policy is to restore some of those organizations that were removed. And so this would work as kind of temporary language in the Number Resource Policy Manual because it would be a one-time restoration of these organizations. And it’s not a piece of language that needs to stay in the NRPM for longer than it takes to just put those organizations back on the list.

So, it says ARIN will restore organizations that were removed from the waitlist at the adoption of 2019-16 to their previous position if their total holdings of IPv4 address space amounts to a /18 or less and the maximum size aggregate that a reinstated organization would qualify for a /22.

So the /18 is different than what the current policy says now at the /20. So this would encompass a few of the organizations that had more total holdings than is now allowed under the current policy. But the /22 would remain the same in that that’s the largest block you can request and obtain from the waitlist.

And all restored organizations would extend their two-year approval by – and this is a variable by the number of months between July, which is when the present policy was implemented, and the implementation of this new policy if it passes through this community process. And then any request met through a transfer in the intervening time would be considered removed from the waiting list. And the implementation timeline would be immediate. Next slide, please.

There was some lively discussion on PPML. There were 23 comments in favor. And I just copy and pasted some comments that I believe captured the spirit of sort of both sides of this conversation.

So many of those who were in favor are community members who were affected directly by the changes to the waitlist. And many were also just coming out in support of those organizations and felt that this was the fair thing to do.

The comments against the spirit of those is largely that, hey, any ISP or business that made plans that hinged on getting v4 from the waitlist probably didn’t have a great business plan to start with and you shouldn’t be putting your eggs in that basket.

Policy changes at the movement of the community and “too bad, so sad” kind of thing. So that’s sort of the spirit of both sides of the discussion there.

Next slide, please. So in terms of discussion today, I’d like to understand from the community, should organizations that were removed from the waitlist as a result of this policy update, should they be reinstated? So that’s kind of the big question. And if you are in favor of a /18 still the appropriate size – we talked about this a little bit at the last meeting, if /18 appropriate size for total holdings and is /22 still an appropriate size to be administered from the waitlist.

And with that I will turn it back over to you, Paul.

Paul Andersen: Okay. We’ll try the ever-continuing saga of improving the microphone. I tried something different. Hopefully better. The microphones are now open. I see we already have a few questions lined up. So, again, put your question in or raise your hand in the forum.

So, why don’t I take the first from the Q&A. Beverly?

Zoom Host: I’ll remind those that are putting in Q&A to please also put your affiliation. Makes it much easier for us.

First one I have is Owen DeLong, Farsight Security, ARIN AC. Am I correct in understanding that this policy would affect only 26 organizations?

Paul Andersen: Alyssa or staff, could you address that?

John Curran: This is John. That’s correct.

Paul Andersen: Okay. Thank you. Thank you, Owen. All right. Let’s go to one more Q&A.

Zoom Host: I have Celeste Anderson from Pacific Wave. Have any of the affected organizations already reapplied given the new requirements?

Paul Andersen: I don’t know. John, can we address that?

John Curran: We’d have to go check on that. There’s certainly organizations that are waiting to apply or to be reinstated by this policy.

I don’t know whether or not any of them have requested, but if they have, they understand if they’ve received an allocation since then, they don’t qualify. But staff will go dig that and report back ASAP.

Alyssa Moore: If we can actually just click back to that stat slide, there’s a metric on there that will help us understand that. Right here.

So the 79 number, where it says “79 requests were adjusted to receiving a /22,” so that is under the new requirements of the policy that’s now in place. So those 79 were adjusted down, but the 26 organizations who this policy would affect now, they were removed because they weren’t able to adjust it down to that /22 because their total holdings exceeded the eligibility criteria now.

Does that make sense?

John Curran: Right. Unless those organizations have since released address space in some other way, there’s no opportunity for them to use the current policy. And, so, I expect all of them are still pending because we have no way of processing them under the current policy.

Paul Andersen: Okay. Let’s go to our first microphone person. So, let’s go to Chris Tacit, please, if we can let him go.

Zoom Host: Chris Tacit, you have the ability to unmute.

Paul Andersen: And we’ll go to Kevin next if you want to queue him up as well.

Zoom Host: Sure.

Chris Tacit: Thank, you Mr. Chair. So first of all, Chris Tacit, Tacit Law and ARIN AC. I support this policy. I think it’s just a matter of basic fairness.

I don’t think it’s so much an issue of what people did or didn’t count on because when you’re on the waitlist, you never really know if – even if you’re solidly on it, if the timing is going to work out for your business plans.

But I think from a community and ARIN perspective, there’s a fairness issue here. The reason we suspended and modified the policy was to prevent fraud. But for those who were legitimately already on the list and there was no issue of fraud being committed, I think that they ought to be reinstated for that reason.

So thank you.

Paul Andersen: Thank you, Chris, for that. We’ll move on.

Kevin Blumberg: Good morning. Actually, good afternoon.

Paul Andersen: It’s still good morning in Seattle.

Kevin Blumberg: I support the policy as written. I believe both of the sizings in your presentation are correct and appropriate.

As I brought up in the last ARIN meeting my only concern is that the precedent that this sets, and I wanted to stress because this was a unique situation of an emergency policy and some very radical changes being done, I think we can treat this policy differently.

But the notion that, especially for organizations that do not have space that are not under an RSA because if you’re under an RSA, that’s a whole different thing, that policy can be either locked in time or based on what you were looking at when you originally submitted the request rather than what is live within the NRPM.

We need to be very careful about that. So I agree with the fairness aspect, but I don’t agree with the notion that the – sorry, the people who are supporting it are supporting it because when they originally applied it was this and therefore they should be given it. So I hope that clarifies my part.

Paul Andersen: Kevin, can you just give your name and affiliation.

Kevin Blumberg: Kevin Blumberg, The Wire.

Paul Andersen: Thank you, Kevin. And I’m going to go and alternate on some Q&As.

First one, David Farmer University of Minnesota. I support the policy as written. I believe the /18 limit provides a balanced approach allowing a few entities back on to the waiting list. Thank you, David. Next one, Beverly.

Zoom Host: Next one, Owen DeLong, Farsight Security, ARIN AC. If we do this, I support the /18s and /22s limitations of the necessary – of fairness.

Paul Andersen: Chris Woodfield, Twitter and ARIN AC. He asked the question, is the current amount of space on the waiting list sufficient to fulfill the 26 reinstated requests? And do we have any estimate on how this will affect the wait times for Orgs on the list today?

John, I see your hand up. John Curran.

John Curran: Yeah, there’s more than sufficient space available. Because we still have space we’re cleaning up, this will result in probably a one-month change. In other words, to the extent that we – this policy is recommended to the Board and then adopted at implementation, our next quarterly issuance would be slightly smaller. But I don’t anticipate it having a substantial impact over the long term, the amount of space involved is de minimis.

Paul Andersen: Okay, thank you for that. Next question, please.

Zoom Host: Andrew Dul has his hand raised, but he’s in panelist mode and he can’t actually raise his hand. Until we can switch over to him, go ahead.

Paul Andersen: Let’s keep doing some Q&A because they’ve been waiting for a while. Let’s get Q&A please.

Zoom Host: I don’t have an affiliation. Isaac Adegbemle. How active are the affected organizations in deploying IPv6?

Paul Andersen: I don’t think we have that data, Isaac. That’s not something we would ask; any data would be anecdotal. But John might have some anecdotal data for you.

John Curran: Just recognize that ARIN normally would not ask that of the requesters when they go to the waitlist. So I don’t think it’s something we’re able to generate.

Paul Andersen: Let’s do one more Q&A and then we’ll go to the hand up.

Zoom Host: Steven Feldman, Viacom, CBS. Are there any other mechanisms in place to ensure that the reinstated applicants would be engaging in the fraud that triggered the original policy change?

Paul Andersen: I think as an overall any application for any resources always has a degree of fraud. We both take reporting from the community and internal mechanisms that staff have developed. So I don’t think we would treat these any different.

John Curran, did you want to add anything to that?

John Curran: I just want to say that the original suspension was due to an egregious case of fraud that involved fraudulent companies, companies that were shell companies created solely for the purpose of applying fictitious IDs and similar.

It caused us to stop and pause the policy. Our mechanisms have since improved at detecting this but also the type of fraud that occurred that originally caused the original policy changes was somewhat unique and unlikely to be replicated.

Paul Andersen: Let’s go to Andrew Dul then. Andrew, name and affiliation, please.

Andrew Dul: Andrew Dul, ARIN AC, 8 Continents Networks. Observation for Alyssa. In your slides today, you asked about the question of whether you’re using a /18 as the cut-off or not.

My understanding is that this is a recommended draft of this policy, and that’s really not up to debate given the nature of the text phrase. Is that not your understanding or are we still debating the /18?

Alyssa Moore: Given that it is recommended, it is my understanding, but I put that question up there just to do the gut check with the community again to say, like, this is what the policy says.

So, I mean, the ultimate question after this will be should we be moving forward with this policy or not.

Andrew Dul: Thank you.

Paul Andersen: Just from a queue management – we’re not time crunched. We’re actually a little ahead. But if you do want to speak or put a comment, I’d ask if you could put that – especially raise your hand – soon so we can manage that.

Let’s go to another Q&A. I’ll go with this one, Matthew Wilder from TELUS. Not a statement for or against the policy, but rather an observation. I just want to comment that this is a case where fairness is in the eye of the beholder. Those who have been dipping into the waitlist will no doubt be bothered by the changes in policy. On the other hand, there’s a matter of fairness to organizations that could get the waitlist IP addresses in the future if we adopt these changes.

Thank you for that, Matthew.

I see Steve Ryan has his hand raised, so, Steve always gets – for those who don’t know, Steve is our General Counsel. I would always ask if he has something to say that we hear it quickly.

Steve Ryan: It’s a mistake and I apologize that I’ve interrupted the meeting.

Paul Andersen: Oh, okay. Always good to hear from you, Steve. These things happen. Let’s move on then to Robert Seastrom.

Zoom Host: Rob, you can talk now.

Robert Seastrom: Rob Seastrom, Capital One, ARIN AC. I have a question for John Curran. And I’m being delicate in how I word this so Counsel does not jump on my case.

Paul Andersen: He was preemptively putting his hand up, then. He sensed this coming. Sorry, go ahead, Rob.

Robert Seastrom: The actual wording we have here is that this affects organizations that were on the waitlist as of 2019-16’s implementation.

And I want to make sure that we’re not going to have collateral issues involving suddenly making any organizations that were under suspicion of fraud now or in the past suddenly eligible that we thought that matter had been disposed of if we move this forward. Thank you.

John Curran: You will not. There’s no conflict there in that regard, because you have to be in good standing to have your request processed. To the extent we have an organization that we’re dealing with any issues, they’re no longer part of the normal process and would not be reinstated by anything like this.

Robert Seastrom: Perfect, appreciate it.

Paul Andersen: I’ll ask staff to read the next question and at the end of that exchange and its response we’ll be closing the queue. So, please raise your hand or type your question and we’ll deal with any of those post queues. So, ARIN staff, take it away.

Zoom Host: Chris Woodfield, Twitter, ARIN AC. Is it a correct statement that the additional restrictions, in particular the move from a 12-month to 60-month hold period, will apply to these one-time distributions?

Paul Andersen: Would Alyssa or John like to address that?

John Curran: To Alyssa – the current proposed text is what would apply. So we would go to the current policy in applying it.

I’m not sure – Alyssa, do you want to talk about the idea of a 12- versus 60-month hold period?

Alyssa Moore: Sorry, is the question is the hold period being changed?

Paul Andersen: The question was is it correct – the question was, and if Chris Woodfield wants to speak, he’s put his hand up, so why don’t we open his mic.

Chris, you’re good to go ahead. State your name and affiliation, though.

Chris Woodfield: Chris Woodfield, Twitter, ARIN AC. I just wanted to confirm that the other changes that were made as part of the emergency policy will apply to these one-time distributions. The size limit is in the proposal, but the 60-month hold period, we changed it from 12 months. Just want to confirm these one-time distributions will be subject to that 60-month hold period instead of the original 12.

Alyssa Moore: Yeah, it’s my understanding that it’s the intent of the policy that that would, the 60-month would apply. And that’s what staff has interpreted from the –

John Curran: That is correct.

Alyssa Moore: Staff and legal.

John Sweeting: This is John Sweeting. We actually apply that 60-month to anything that’s been issued from the waitlist, prior to or after the change, unless somebody got a transfer of waitlist space in the 12-month period and it happened before that change. Then it was 12 months. But anything that has not been transferred, it goes 60 months from the date it was actually issued on the waitlist.

Chris Woodfield: Great, thank you.

Paul Andersen: Seeing that all the questions have been addressed, we will now close the queue on this proposal. I thank Alyssa for her presentation.

We will now entertain a poll on this, as it’s Recommended Draft Policy. I’ll ask the poll question be put up again asking those that are in favor or against Policy 2020-2 as written. So please either vote on the poll or you can do a Q&A.

I’ve heard some people would like to register abstentions. The poll does not actually allow for that. But if you do not click an answer one will not be submitted, and you’re free to put that in the Q&A and we can try and sort that.

Generally I would not call for abstentions for policy proposals, but if that’s a key, please let us know.

Give it a bit of time. Let’s try the entertainment portion. I’ll try this.

John, the question has become was the color of the beard picked to match the virtual background, or was the virtual background picked to match the beard?

John Curran: Well, I didn’t pick the background so it could easily be a testament to the color of my beard.

I know if that’s what’s been done, we’re moving closer and closer to a pure white background over the years.

Paul Andersen: Okay. Give a few more seconds. There’s ten seconds, and then we’ll close the poll and hear the results.

All right, the poll being now closed, I’ll ask staff to give us the results.

Zoom Host: At the close of the policy: 125 people in attendance. 42 voted in favor and 14 against.

Paul Andersen: That information will be provided to the AC for their consideration. And we will keep roaring into our next presentation which is ARIN 2020-3: IPv6 Nano-allocations. I’ll ask Andrew Dul to take it away when he’s ready. Andrew, the floor is yours.

Recommended Draft Policy ARIN-2020-3: IPv6 Nano-Allocations

Andrew Dul: Okay. Everybody hear me okay?

Paul Andersen: I can hear you. Apparently people can’t hear me, but I can hear you.

Zoom Host: You’re good.

Andrew Dul: Here we go. Here we are talking about nano-allocations today. Next slide, please. For IPv6.

The history of this proposal, most of which all occurred this year, the original proposal was in February. It’s gone through a couple of revisions as noted on the slide and was recommended by the Advisory Council initially on July the 21st.

Next slide, please. So the Staff and Legal Review for this is fairly clean. The suggestion at the bottom was adopted by the shepherds. So we fixed the one issue that was noted in the initial staff review.

Next slide, please. The legal review creates no material issues. And the resource impact would be small, only a three-month after ratification by the Board and just the update of the standard training guidelines and documentation.

Next slide, please. Let’s take a look at the problem statement for this. What is this Policy Proposal all about?

So basically this is about fees. And we’re – since a policy cannot deal with fees we’re adding policy to change the way that people can get certain allocations.

So the issue is with a 3X-Small ISP, one who only has a /24, an IPv4 addressing, who obtains the smallest IPv6 allocation today, which would be a /36, their fees would increase from $250 to $500 a year. And as you might imagine, this is a disincentive for some organizations who just don’t want their fees to go up.

And since the start of 2019, there were 29 organizations that requested, and at this point have abandoned or withdrawn their requests. And four are still pending. So this is an issue that affects the smallest ISPs. And there’s two to three dozens of these, at least at this point, have tried and decided that maybe I don’t want to do this and raise my fees.

Next slide, please. Here’s the fee categories as they are currently. You’ll note that the /40 is the bar for a 3X-Small. And the current policy only allows a /36 as the smallest ISP block. So what we’re doing is creating a new category that allows for /40 IPv6 blocks. Next slide, please.

So here’s the text that we will be modifying. The new text is in red. So we add the ability to add a /40. And we have some specific unique requirements around the 40 that we designed so that this encourages IPv6 adoption but also doesn’t suggest to people that they should be getting smaller blocks just for dollars perspective. So it really is intended to limit it to the smallest ISPs who only have very small IPv4 holdings today.

And the second slide of the text, please. And this is the restrictions on partial returns and also about how you cannot expand your block – you can only go one way; you can go larger. You can’t go smaller. And that’s also intended to be kind of this one-time carve-out. If you’re super small, you can get super small nano IPv6 block. But if you grow, then you have to grow only in the larger direction.

Next slide, please. So the changes since our meeting back in June. We added text to clarify partial returns so that there was no confusion about that. Only full returns would take someone off of the category, out of the category and a partial return wouldn’t be permitted.

Next slide, please. So the questions we have for you today are: Do you support the recommended draft as written? And are there any issues that you still think need to be addressed in this policy before that we would normally send this to Last Call assuming that the community widely supports this policy?

So, thank you.

Paul Andersen: Thank you, Andrew. Thank you for that presentation. We’ll throw open the mics to questions and comments. Let’s take a slide back, actually, since it’s better to have the questions there.

We have our first question. So let’s go to that. The Q&A first.

Zoom Host: All right, our first question comes from David Farmer, University of Minnesota. I support this policy as written. Further, I believe this is an important policy to remove a small barrier to the adoption to IPv6.

Paul Andersen: Okay. There it is. And the next one, please.

Zoom Host: All right. We have Lee Howard, IPv4.Global, by Hilco Streambank. I see that 33 3X ISPs have applied. 33 times 250 is 8,250. How many 3X ISPs are there in total?

Paul Andersen: Do Andrew or John want to address the question?

Andrew Dul: I don’t know the answer to that.

Paul Andersen: John Sweeting?

John Curran: I’ll get the information momentarily. The last time I checked there was approximately 1,100 3X ISPs. I’ll double check. 1,175 is my off-hand recollection.

Paul Andersen: If you could pop up, John, when you have a number, we’ll put that into the record. Thank you for that.

Okay. Let’s go to a microphone. Chris Tacit has his hand raised. Let’s go to Chris.

Zoom Host: Chris, I’m giving you the ability to speak.

Chris Tacit: Thank you. Chris Tacit, Tacit Law, ARIN AC. I support this policy as written. I think it’s really important to remove any impediments to IPv6 adoption. At the same time I would encourage, as a separate matter for the Board to consider whether or not there should be some sort of modification to the fee schedule, because I am concerned about tailoring policy to fee schedules as an approach generally if what we’re really trying to do is indirectly affect what people are paying.

If from a routing-efficiency or allocation-efficiency perspective, it makes more sense to allocate /32s or /36s, I’d like in the long term to see us revert to that rather than creating an exception solely for the purpose of having people save fees. Thank you.

Paul Andersen: I think the Board position has always been that, yes, creating policies to impact fees is, in fact, the point of it. Fees should not be part of the policy discussion. And our answer always is after any policy or really anytime we have to sometimes adjust the fee schedule to ensure that the principles by which we set fees are being met and that the organization is in a healthy state.

So that’s always something that we have to examine at the end of that. But we always enjoy and take community feedback on that.

John, did you want to add anything to that?

John Curran: No, I think you got it right on.

Paul Andersen: Okay. I’m told now that the mic is better. I thank you all for your patience. Okay.

I’m going to go out of order and go to Rob Seastrom because the timing of his hand popping up sounds like he might want to address something Chris Tacit said. Let’s see if my sentiment is correct.

Zoom Host: Robert, you’ve been given the ability to speak.

Rob Seastrom: Thank you. Rob Seastrom, Capital One, ARIN AC, and the original author of this proposal. And it should probably go without saying that I support it, although if it had changed to something that I didn’t support I would mention that.

I’d like to speak specifically to Chris’ comment or question about address space. ARIN’s policy operationally has long been that if an organization gets smaller than a /32, it is carved out of a /32. Then that space is set aside due to the sparse allocation process that we have for IPv6.

And it’s clear in the text there that this is going to be no different if would be a /40 carved out of a /32. So as they grew there would be no deleterious effect on the routing table.

From a technical soundness perspective, this works. We should discuss the – go on to discuss what the community likes in terms of the fairness and fee schedule and whether it’s appropriate, et cetera. Thank you.

Paul Andersen: Thank you. John Curran notes that there are 411 3X registration service-paying customers. He put that in the chat. Just to put that in the record. Actually I see, John, your hand is up now. Did you have something else you wanted to raise or did I beat you to say it?

John Curran: I just wanted to say my recollection of 1150 was the 2X category. That’s why I thought there was so many. But 3X is relatively small.

Paul Andersen: All right. Let’s go to the questions, I’ll do the next one, ask for my assistance.

First, we have Owen DeLong of Farsight Security and ARIN AC. I prefer that the Board address this through modification of the fee schedule so that a policy would be unnecessary.

I think the proposal has been carefully crafted to minimize the long-term impacts of undersized IPv6 allocations. I support the policy as written unless or until the Board addresses the fee problem more directly.

Thank you, Owen. And I think I just referred to the earlier comments since you asked the Board staff.

Next question, please.

Zoom Host: We have Gary Giesen with CentriLogic. What would be the impact to revenue of addressing this problem through fee changes instead? I’m a bit leery about sacrificing one of the main goals of IPv6 aggregatability for the sake of a few dollars. I would rather lower fees instead. I understand this cannot be done through policy to address the barrier to adoption.

Paul Andersen: I don’t know if we can – I think the math is kind of there. So you could do it quite quickly. I don’t actually have it off the top of my head. I don’t want to guess. I’m sure somebody is going to be fast with that. I think it’s safe to say yes, Gary, it’s not a massive amount of money, but we also have to balance the fact that there is a certain amount of work that goes into any assignment or allocation that we do and maintain the services that we all enjoy as a community. So that has been obviously a factor.

John?

John Curran: Yeah, the amount of money is –

Paul Andersen: $102,750 per year. Thank you, we have it.

John Curran: It’s a small amount compared to ARIN’s overall budget. There’s a fairness question because the amount of work involved quite frankly for organizations is not such that it drops significantly lower. In fact, smaller organizations tend to actually require a significant base of maintenance.

So there’s a concern of just an equity question, but the proposal to reduce the fee – just that category, not the whole schedule, but reduce the fee for that category – has been put before the Board.

We have a number of fee issues that are on the schedule to look at. We also have the fact that we have ISPs and end users paying in two very different ways that has been raised as an issue of equity.

So it’s before the Board. They’ve referred it to the Fin Com. Staff is coming up with proposals for them to look at. It’s going to be an active topic next year.

Paul Andersen: Thanks for that, John.

Rob Seastrom, do you still have your hand up? I assume it’s been taken down. Rob, you have the floor.

Robert Seastrom: My apologies. I went ahead and discussed my comment to Gary in the chat window. So, no further.

Paul Andersen: Okay. Thank you. Okay. I’d ask if you want to speak on this issue, we have a few more minutes before the break. So, but I’d just like to be able to manage queue expectations. So please either raise your hand or ask your question. Let’s go to our next question.

Zoom Host: Brian Jones from Virginia Tech. He supports the Draft Policy as written and supports moving IPv6 adoption forward.

Paul Andersen: Thank you, Brian.

Next question is from Leo Vegoda, And Polus LLC. I agree with Chris Tacit that using policy address fee issues is not ideal. That said, the changes to the proposal since the last meeting have made it acceptable. I support its current form.

Thank you, Leo. Next question or comment.

Zoom Host: All right. Kevin Blumberg, the Wire. I would far rather see this as a fee waiver than a policy. IPv4 and IPv6 subnet sizes are not equivalent and can’t be.

If an Org uses 256 /48s, then they would look equivalent to 256 IPv4s over /32s. However, that same organization could have a /24 of IPv4 and give out 16 million /64s. This policy erases years of good stewardship on appropriate sizing of IPv6 allocations from the community.

Paul Andersen: Thank you, Kevin, for that. Next question, please.

Zoom Host: All right. Celeste Anderson with Pacific Wave. What are other RIRs doing with similar allocations? Are they allocating smaller IPv6 blocks?

Paul Andersen: I don’t know if staff can comment on policies in other – Andrew, you’re aware from this process. I wouldn’t want to comment off the cuff.

John Curran: We would need to research that. It’s documented in the comparative policy matrix on the NRO website. I’ll dig into it and come back.

Paul Andersen: Thank you for that. Okay. Last call for questions or comments? Let’s go to the floor. Chris Woodfield has the floor, please.

Zoom Host: Chris, you have permission to talk.

Chris Woodfield: Hello. Hi. Chris Woodfield, Twitter, ARIN AC. I’m aware that IPv6 allocations as they are – as practiced today are allocated via sparse addressing principles, which means that in almost every case when someone receives an IPv4 allocation, the space adjacent to that allocation up to a certain number of bits is at least unofficially reserved for any expansion that customer, that member may have.

And with the intent if that customer, member then comes back to request more v6 space, that can be accomplished simply by changing, moving back the mask on their existing allocation instead of allocating a separate block.

In the case of the /40 micro allocations, do you anticipate having the ability to do the same where a member who receives a /40 allocation and then comes back and fills that block, requests a /36, will be able to receive that /36 sparsely, such that they don’t need a new block; they can just use the same block but with a lower mask, a shorter mask?

Paul Andersen: Okay. John Curran.

John Curran: I just want to say that it’s unclear that parties using smaller allocations will suffer any deaggregation as a result. If they expand with time they’ll get adjacent space, which was set aside with sparse allocation that we use.

So I just wanted to point that out. I guess the point of the concern that some people have about issuing smaller blocks to parties for IPv6 is it creates a pressure for them to potentially do smaller allocations to their customers. And while ARIN doesn’t set customer allocation size, the larger blocks we issue, the more it encourages larger blocks to be issued to the end users.

Paul Andersen: Okay. Thank you for that, John. I’m going to close the queues at the end of the next question or interaction, so, please raise your hand or type your question. So let’s take the next question, please.

Zoom Host: We actually do not have any further questions in the Q&A.

Paul Andersen: Oh, I think my thing is out of date then. I’m sorry. I show two. But as you say that, I see that they have been previously answered. So sorry. The Zoom platform is malfunctioning on me. It doesn’t seem to be my day for this.

Let’s go to David Farmer, and after Dave Farmer we’ll be closing the queue. Please go ahead, David.

Zoom Host: All right, David, you’re free to talk.

David Farmer: David Farmer, University of Minnesota. My comment is to Celeste’s question about the other RIRs.

Our fee schedule is significantly different than the other RIRs and the impact that the v6 block sizes have, at least in my opinion.

And so there isn’t an apples-to-apples comparison to be made. But our fee schedule creates a much larger impact at least relative size-wise. And so that’s my opinion on it. Thank you.

Paul Andersen: Thank you, David. So with that, I see our queues are cleared. So we’ll now close them. We have a few minutes before break. This will be our last proposal before the break, but we will now have our last poll.

So I would ask if everyone is ready that we bring up a poll on 2020-3: IPv6 Nano-Allocations. I’d ask that you vote either in favor or against on the poll. If you’re unable to, please use the Q&A. So let’s go ahead and please bring that up and we’ll give 30 seconds for everyone.

Ten seconds, last call. If you can’t see the poll, please use for or against in the Q&A. We’ll now close the voting and I’ll ask for results from staff when available.

Zoom Host: All right. At the close of the poll, there were 124 participants, 42 in favor and 12 against.

Paul Andersen: Thank you. That information will be provided to the Advisory Council for their feedback.

With that, that brings us to an exciting break which you want to stick around for because there’s going to be stretching with Erin and Buzzword Bingo. So go make sure – if you haven’t already, go download your bingo card. I haven’t looked at the bingo card. I don’t know the words. I won’t try to push that way. But you can win a gift card if you type “bingo” in the chat when you hit a bingo. With that we’ll take a break until 1:40 PM Eastern. With that, please stick around.

John, anything else we need to add or are we good? Or, staff, anything I forgot?

John Curran: I just wanted to note that the other RIRs, upon review of their policies just to make sure I was current, are using a /32 as the smallest allocation size for their ISP customers as best I can tell. So that is just a data point that was asked.

Paul Andersen: Okay. I’ll turn it over to the staff for the break. We’ll be back after the break. Thank you, everybody.

Zoom Host: We’re going to give everybody a five-minute break, and then we will continue with stretching with Erin.

[Break]

Recommended Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers

Paul Andersen: As we come up here at 10:40 in Seattle, 1:40 in Virginia, we will be resuming momentarily here with our program.

Are we ready on the staff side? Sorry, I might have gone quicker –

Zoom Host: We’re all set for you.

Paul Andersen: Excellent. We have one more policy today and then we’re going to get into our presentation block.

So our last RDP today is Recommended Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers. And Kat Hunter will be the presenter. Kat, take it away.

Kat Hunter: Can you hear me okay?

Paul Andersen: I can hear you okay. I hear people can hear me okay, and I thank everyone for putting up with my Zoom issues today.

Kat Hunter: Excellent. So, this is Recommended Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers. Myself and Rob Seastrom are the shepherds for this policy.

This is the history of this. It’s actually – this has been fairly fast. It’s mostly editorial to align utilization requirements.

So there weren’t too many changes that were required. The text itself had a lot of changes, but the actual content inside of the policy didn’t really change all that much.

So next. Staff and Legal Review. The staff understanding is that this replaces RFC 2050, which references sections in Section 4.2.3.4.1 and 4.2.3.6 with references to end user assignment utilization requirements in Section 4.3.3.

Staff comments were that this would align requirements for the downstream customers with existing ARIN end user policy and remove outdated RFC 2050 references, which has been a source of confusion in the past. And that this was clear and understandable and can be implemented as written.

No material legal issues.

Resource impact seems to be minimal. And the only thing that would be required would be the normal staff training updated guidelines and internal procedures and standard documentation updates.

So the policy goal. This Draft Policy replaces outdated RFC 2050 references in Sections 4.2.3.4.1 and 4.2.3.6 with references to the end user assignment utilization requirements in Section 4.3.3. Next.

So how did we get here? The AC Working Group – there are a few AC Working Groups right now working on various items, but this specific one is currently working on cleaning up some of the existing NRPM text. This was sent in as a policy update to correct the language.

Given that RFC 7020, which supersedes 2050, no longer carries specific utilization requirements for downstream customers of ISPs, the RFC reference may be removed from Section 4.2.3.6, instead of referencing Section 4.3.3, currently 50 percent of the utilization within 24 months to harmonize the utilization requirements for both ISPs and to their downstream customers. Removing these references from Section 4.2.3.6 will simplify the language of that section. Next.

So I broke this up to try to understand the policy better. Normally I put all the current policy together and then put all of the proposed policy together. I broke this down into sections so you could actually see what’s changing a little bit better.

The current policy, part one, for this specific section for utilization reassignment and allocation for prior allocations must show that each customer meets 80 percent utilization criteria and must be available via SWIP/a distributed service which meets the standards set forth in Section 3.2 prior to your issuing them additional space. Next.

So this is the rewritten policy just for this section. Downstream customer requesting address space from an upstream ISP must document a plan to the allocating ISP for their utilization to conform to Section 4.3.3 reassignment and reallocation information for prior allocation must show that each customer meets the 80 percent utilization criteria and must be available via SWIP/a distributed service, which meets the standards set forth in Section 3.2 prior to your issuing them additional space. Next.

So the current policy, this part two section, actually takes up two slides. Once cleaned up it only takes up one slide. It’s much easier and a little bit cleaner to actually read through, although the content once the RFC references are cleaned up is much easier to understand.

Under normal circumstances an ISP is required to determine the prefix size of the reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically a downstream customer justifies reassignment by demonstrating they have an immediate requirement for 25 percent of the IP addresses being assigned, and that they have a plan to utilize 50 percent of their assignment within one year its receipt. This policy allows a downstream customer’s multi-homing requirement to serve as justification for a /24 reassignment from their upstream ISP regardless of host requirements. Next.

Then there’s more. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer’s multi-homing requirement and may assign the customer a /24 based on this policy.

Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of their customer.

This information may be requested by ARIN staff when reviewing an ISP’s utilization during a request for an additional IP address space. Next.

So that was all consolidated to this. If a downstream customer has a requirement to multi-home, that requirement alone will serve as justification for a /24 allocation.

Downstream customers must provide contact information for all of their upstream providers to the ISP for whom they are requesting a /24 and utilize a border-routing protocol between the customer and the ISP. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification.

ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. Next.

So, the summary of all of that. This was obviously the result of the NRPM Working Group. Initially it was under discussion whether this would go in as just an editorial policy or whether this would go in as a full policy. We opted to do it as a full policy just because there was so much language that actually changed inside of all of the different sections.

We wanted to make sure that we weren’t actually functionally changing or breaking anybody’s processes by changing the language and the references. So it simplifies the language, removes the reference to a deprecated RFC.

We did check with multiple organizations not just on PPML which received positive reception, but also a few other organizations to see how this would functionally affect them and make sure we weren’t breaking anything.

Everyone that we reached out to said that this wouldn’t actually impact them in a negative way or wouldn’t impact them at all. And if anything, it made it easier for them to discuss with their end users, the language – there wasn’t so much to actually explain to the edge customers that don’t do this sort of thing on a daily basis. It clarified a lot of issues.

And staff and legal. No inherent issues and fairly simple implementation. So after this meeting, we would like to send this to Last Call if there aren’t any issues with this. Especially since this is editorial and this cleans up a lot of language, we’d like to get this through to make everything more clear.

So I guess that’s pretty much it for the policy. Are there any questions?

Paul Andersen: Are there any questions on this policy proposal – 2020-5?

Kat Hunter: Or concerns.

Paul Andersen: Concerns, comments on policies?

So we have, I think, three which we could do as one. Why don’t we just do them as one, please.

Zoom Host: I have Owen DeLong, Farsight Security, ARIN AC. Suggest removing the word “your” in “prior to ‘your’ issuing them space and the proposed policy part one.” Otherwise support as written.

Kat Hunter: I agree with that, too. It seemed a little odd there but I think there’s – we’ll work on that.

Paul Andersen: Thank you, Owen.

Zoom Host: Two hands.

Paul Andersen: I see we have two hands. Sorry, I’m having a small problem. There we go. Zoom is being a bit weird today. Let’s go with Chris Woodfield, please.

Zoom Host: Chris, you’re all set.

Chris Woodfield: Chris Woodfield, Twitter, ARIN AC. Just a little bit of background on this. The Working Group that generated this policy, I am the Chair of that Working Group, we are tasked with evaluating potential new policy as a result of ARIN’s Policy Experience Reports. So the impetus for examining this came directly from feedback from ARIN customers filtered through the registration services group and brought in, I believe this showed up in one of last year’s Policy Experience Reports that this clause was a source of confusion.

Obviously speaking in support of the policy, and I’ll note that Owen makes a good point of the use of the word “your” there, in examination of it now seems odd and unnecessary. So I would fully support striking that word from the proposal.

Paul Andersen: Thank you, Chris. That’s good. Next – did we lose our comment? Kevin Blumberg, please.

Kevin Blumberg: Kevin Blumberg, The Wire. Absolutely agree with Owen. “Your” isn’t really needed and syntactically incorrect.

I have a question regarding 4.2.3.6. If you could bring up the slide, just for following the bouncing ball on that one.

So the part that I’m curious about is the /24 reassignment to multi-home. So the new text. Thank you. And it says “and utilize a border-routing protocol between the customer and the ISP.”

One of the use cases for getting a 24 allocation and AS number and BGP is not necessarily to have two upstream providers. It’s to have a primary upstream provider and to have a unique routing scenario to a cloud provider, as an example, that dead ends at that cloud provider.

It’s for having a globally unique numbering scheme but not actually being an ISP or an upstream. Is the language here too specific, or is it general enough to allow for a scenario where it is not going to two upstream providers but is following more of the unique routing protocol scenario where multi-homing is allowed?

Paul Andersen: I’ll just unmute. John, did you want to –

John Curran: It’s sufficiently general to handle the case. We have had parties apply for address space who have indicated that what they want may be different after they get the address space than what they get it originally at because it’s for standby or a dedicated cloud connection or a dedicated service provider. We don’t police their subsequent use if it’s more specialized.

Kevin Blumberg: So, John, it’s only that as long as they are saying “I’m connecting to two ASes – whether they’re upstream and propagating the route is not the relevant part to me.” As long as that’s allowed, then I fully support this.

Otherwise it seems like it’s actually limiting down from the original sort of multi-homing concept of having a unique routing policy.

John Curran: I don’t think it would be restrictive, but it’s up to you. If you wish to make it clearer, you are the Advisory Council.

Kevin Blumberg: Well, not me but –

Paul Andersen: Kevin –

Kevin Blumberg: Like I said, I do support it and I do ask that that be looked at just as a potential concern that we might have to get fixed after the fact again.

Paul Andersen: Thank you for that comment. I’d like to time manage and close off. So, if you’re going to wish to speak, either raise your hand or type a question. If you have to type a long question, you can just give us a short typing comment so we can keep you in the queue. We’ll close the queues after the next two Q&As. So, let’s do both, please. Staff?

Zoom Host: Brian Jones, Virginia Tech, support as written and agree to remove “your” from Owen’s comment.

Paul Andersen: Thank you. And next one.

Zoom Host: And Gus Reese, Cogent Communications. I support the policy as written. I’ve allocated many /24s to our end users using 4.3.2.6 to multi-home via BGP to us and to other ISPs.

Paul Andersen: Thanks, Gus, for the comment. We’ll close the queues and go to the last speaker, which is Owen DeLong.

Zoom Host: Owen, you should be all set.

Owen DeLong: Can you hear me? Okay. Good.

In response to Kevin, I think he’s conflating the traditional requirements for getting an ASN and the requirements here for getting a /24 from all of your upstream ISPs which is what this policy is about.

I don’t see a useful case for getting /24 from one ISP to use with multiple uplinks either to that ISP or to another ISP where you don’t use a border gateway protocol or some form of exterior protocol at your border with that ISP in order to have the routing move to the active connection when the other connection fails. So I don’t think that this requirement is overly restrictive.

Paul Andersen: Okay. Thank you on that feedback. Obviously can be passed on to the AC.

That closes off this topic, 2020-5, and we’re on time. I would ask everybody to take a second and contemplate as we bring up the poll.

This will be our last policy and our last poll of the day. So, on the issue of ARIN 2020-5 Recommended Draft Policy, please let us know if you are in favor or against as written. A reminder, if you’re having any problem voting, please put it in the Q&A and we’ll make sure it gets collected.

A reminder that tomorrow we have day two and we have three policies – Allowance for IPV4 Allocation “Swap” Transactions via 8.3 and 8.4, gTLD micro-allocation clarification, and Clarify and Update 4.2.1.2 Annual Renewal Fee – and of course more presentations which we’ll get to in a second.

We’ll give another fair warning. And the poll is now closed. I ask staff to give us the results of the tabulation, please.

Zoom Host: At the close of the poll there were 119 attendees. 48 voted in favor and three against.

Paul Andersen: Thank you. That information will be passed on to the AC for their consideration. My thanks to Kat Hunter for a great presentation. My belated thanks, also, to Andrew Dul for his presentation. My apologies for that.

That ends our policy block. We now are going to move into a series of short reports starting with our grant program. So, Jennifer, take it away.

ARIN Community Grant Program Recipient Presentations

Jennifer Bly: Thanks, Paul. Hello. Next slide.

Today I’m going to be talking to you a little bit about the ARIN Community Grant Program. Next slide.

It was launched last year in 2019 and it provides financial grants and support of initiatives that improve the overall Internet industry and Internet user environment.

Next slide. The project eligibility guidelines for applicants when they apply must fit into one of the categories: technical improvements, registry processes and technology, informational outreach, or research. And they must each broadly benefit the Internet community within the ARIN service region.

Next slide. In 2019 we had four projects selected to receive a grant. And those projects have since been completed, and they’ve submitted their final reports on September 30th. And we are going to hear from representatives from each of these projects today.

So we’re going to hear from Phil Roberts with the CrypTech Project, Sander Steffann with the Global NOG Alliance, Nalini Elkins with the IPv6 Training for Enterprises Project, and Keith Mitchell with the DNS-Open Source Tools Enhancement and Maintenance Project.

Without further ado, I’ll let them take it away.

Phil Roberts: Thanks to the ARIN community for inviting me to give an update on the CrypTech Project. And thanks to the ARIN community for supporting us through a grant in 2019. We appreciate your contributions to us.

I’ll talk about the CrypTech Open Source Cryptography Project, and bring you up to date on where we’ve been and where we are.

We are about building hardware security modules in an open fashion. A hardware security module is a dedicated appliance for cryptographic operations. And the main thing it does is generates, protects and stores secrets. An example of this would be a private key in a PKI system.

These modules are very expensive. There are very few vendors and vendors are pretty closely connected to national security agencies around the globe. So it causes us to have some doubt about integrity of these kinds of devices.

This is a hardware security module with a bunch of applications that it enables. These are a bunch of different versions of hardware security modules. You can see a rack-mounted unit, you can see a USBE-type device. All of them are hardware security modules providing different levels of functionality.

The CrypTech Project is a multiyear effort to move towards an open HSM platform. We’re designing this to be open, auditable and trustable. It was thought up by a few people in the IETF. It’s been going on for a few years. And we have reasonable confidence of it being and staying open and being relatively more secure because of that.

We have a core team that’s spread around the globe, including developers in North America, Sweden, Russia, Germany. It’s an open development project. We have signed commits to Git repositories that are available to anybody to look at.

CrypTech has tried to make itself radically open. All our hardware designs and all of our implemented software are publicly available. There’s a link to how to get to the repositories and a link to how to find the Mailing Lists. And we’ve made them very open in terms of licensing. We use a 3-Clause BSD License on all the software and FPGA code, creative commons for all documents. We want to make it as permissive as possible for people to use this technology.

This is a picture of the CrypTech alpha Board. It’s about 4-by-6, I think, maybe 5-by-8. It sits inside a little case. This is the current version.

Part of the funding from ARIN has helped us design the next iteration of this, and I’ll talk about that in a little bit.

Here’s kind of a review of the things that we’ve accomplished. We have open sourced hardware and software published. The main use case continues to be RSA signing. We do that at a really good rate now, 80 signatures a second.

For a device like ours that’s a very good rate. It was about eight before we started doing the work that was funded in part by the ARIN grant.

In the past we’ve been able to hash base signatures in ED25519.

We had an external security audit in 2018 that was very positive. There were no critical vulnerabilities, vulnerabilities that were identified were fixed by the end of 2018. And the reviewers thought we had a very solid design from the security point of view in dealing with its cryptographic aspects.

The grant this year has enabled us to move on in a couple of ways. We did a redesign of our RSA which got us to 10X performance improvement. And we started looking at a next iteration of hardware. One important part of that is an open master key memory. We’re implementing that in a new FPGA. It’s a Lattice iCE40 device. All of that will be open – all of it is open now; we don’t have a prototype yet.

And we’ve started working on a bunch of things for a new version of the hardware. As you can see from here some of these things are done. Some important things on this is moving the designs to KiCad, which is an open board design system, integrating this FPGA-based master key memory and completing the new RSA cores, which has allowed us to get the better performance.

And we’re ready to make a new prototype of this board. We’re just lacking funding for that right at the moment. So all the design work is complete. It’s published. We’re just waiting to get some prototypes printed.

These are all of the people who have funded CrypTech. And I put ARIN on here in this past year. Thank you very much for your support. Almost all of the donation, almost all of the funding goes towards paying the developers.

We pay our developers to develop the hardware and software. And that’s where it is. We have some funding that goes towards hardware and producing prototypes. We try to cover that where possible through crowd sourcing it through Crowd Supply.

But thank you very much to ARIN for your participation in this project and your contribution in the last year. So, thanks to the ARIN community for your support. I’m Phil Roberts, and that’s my contact information if you have any additional questions.

Sander Steffann: Hi, I’m Sander Steffann for the Global NOG Alliance. This is the project that we’re working on and have worked on for the last year and are still working on. So we are a not-for-profit foundation founded to help network operators around the world.

So we have some network operators in Gambia. We have them in Uganda and we are helping the Greek Network Operator Group.

We’re trying to help them so they can focus on their community. What we do we take away all the boring stuff like hosting the website, hosting the email, the mailing lists, provide the tooling for event management – all those things we try to take care of because that’s not what a NOG should focus on. What they should focus on is their community. We try to do that by providing all the tools they need so they have enough time to do useful work for that.

And the problem we ran into is that we provide WordPress websites, we provide event management tooling using Indico, but those have two completely different web interfaces.

They don’t look anything alike and it’s really confusing for the users. Here’s an example. On the left is our own website and on the right is the web interface from Indico.

And people who want information about one of the events have to log into a different system, are presented with a different user interface and, yeah, it’s just not user friendly.

So what we decided to do is to get a professional WordPress developer and have them write a plug-in that uses the Indico API and imports everything into the WordPress website so you get a consistent look. So we decided to do this and make it a completely open source. So it’s going to be in the WordPress plug-in index that’s provided by WordPress. So anybody who wants this can just install the plug-in, put in the URL and the API key for Indico and they get all the event information in their website.

So we’re going to provide support for that over the next couple of years. And this is the main thing we did with the money we got from the grant program.

So what does it look like? This is an example. Unfortunately, the plug-in isn’t live yet. So this is just a little preview. This is our main website. So this is what it looks like. It has a standard text, WordPress information.

And then one of the components you can enter into WordPress is, for example, it’s called planned activities here and these are all the different events that are in Indico. You can see where it is. These days it’s usually an online event. There’s a short summary. And then there’s a button where you can go to the event information.

Here’s what that looks like. Sorry for the typo. Like I said, this is just a little preview. So the basic event information, bit more extensive this time. And below that there’s a full timetable, speakers, links to all the presentations that people can download.

There will be links to information about the speakers if the organizer put that in Indico. There will be links to the videos that have recorded if there are any.

All those things will now be part of the normal website. So every NOG can just use Indico to organize their event. And then automatically all that information is presented on the main website and easily available for everybody to see.

This is the main thing we’ve been working on. This is the total budget we got from ARIN. So we got $5,000 for tool development. So 4500 of that was spent on the development company for the plug-in. We still have 500 left for further improvements and support.

And then we got $2,000 for infrastructure and hosting. Now because I’m personally just sponsoring all the hosting and we’re hosting everything on my own servers, we didn’t need to spend any money on that. So in these days of corona what we have done is we’re spending that money on helping those get access to Zoom and Hopin other online conferencing platforms, so they can have much better virtual conferences online.

And most NOGs are, they don’t – either they’re a foundation that’s purely funded by sponsoring, or they’re not even an official entity at all. It’s just a bunch of volunteers organizing this for their community. So they usually don’t have the funds to get a subscription to services like this.

So we are getting the subscription for them and then using that subscription to support as many NOGs as we can.

This is a quick overview of what we’ve been doing. And thank you for your attention.

Nalini Elkins: Hi. Thanks so much. This is Nalini Elkins, and I’m the president of Industry Network Technology Council.

And our project was IPv6 Deployment at Enterprises. As many of you are probably aware that the enterprises – people who have managed private networks such as the large financials, even many folks in the government and so on – have really not deployed IPv6 nor do they plan to do so.

Somebody was joking around with me and said, yeah, we’re going to be ready for IPv6 about 24 years. That’s only a slight joke.

But it creates a problem for the Internet as a whole because there’s additional complexity to maintaining multiple stacks, security issues and so on.

So what did we want to do? What we wanted to do is we wanted to talk to these people. We want to see if they might be able to raise the implementation priority of IPv6. But one of the problems was many of them haven’t gotten trained in IPv6. So they see it as being unnecessarily complex. Don’t get me wrong, it is complex, but maybe not as quite as much as people think.

So that’s what we did. We provided technical training. And we gave a number of webinars ranging from the introduction to IPv6 to neighbor discovery, which is one of the new protocols, which is in IPv6; IPv6 addressing and address planning, which are major issues because it’s the address itself which has changed. And the entire way that one wants to think about address planning is different.

Also, how do you transition from IPv4 to IPv6. And one of the things that our enterprises use is DHCP for giving out addresses. How is all that going to work?

And then of course the biggest problem as far as a lot of people think is security. How are we going to do security?

And we were fortunate enough to have quite a few of the folks at the IETF who actually wrote a number of these RFCs, engage in discussion with our enterprises, with us. And so that was great to have.

We also published an article aimed at the executive, to raise their awareness because a lot of people tell us, well, that’s all well and good but I can’t get my executives to really understand this.

So how did it work out? Well, I feel like we had quite a few folks. But I would say probably overall our webcast probably about 700.

And they were senior technicians from federal and state governments, military, the financials, and even one from our Native American nation. So it was great to see.

The breakout is – by and large, they were from ARIN, which I think is again was the aim of what we were trying to do is do this for the ARIN attendees.

Here’s a little testimonial which you guys can read. They were kind enough to find our webinars useful.

So, what’s next? We’re going to work with a partner in the Asia-Pacific region, specifically India, to extend this work to the APNIC region. And we have received a grant from ISIF, the APNIC Foundation to do that.

And we hope to continue this work with ARIN on IPv6 application conversion security and troubleshooting because those are, again, issues that have been pointed out by our enterprises. And so that we hope we will be able to work again with ARIN. So thank you so much.

Keith Mitchell: I’m Keith Mitchell, president of DNS-OARC. We’re grateful to being one of the recipients of an ARIN Community Grant over the past year, and I’m going to spend a little bit of time telling you what we’ve been doing with that.

What is DNS-OARC? Like ARIN, we’re a nonprofit membership organization, and we’re here to make part of the Internet’s operational infrastructure work better. We don’t operate critical resources ourselves, but we work with a lot of people who do. And we’re focused on the domain name system.

We do a number of activities. Much of that is community building, knowledge sharing, best practice. We also do data gathering and we work as an liaison channel between researchers and operators.

One piece of the DNS infrastructure I think is quite relevant here is in-addr.arpa, which is very relevant to the operations of Regional Internet Registries like ARIN and anyone who operates Internet address space.

A part of our work, which is specific to the ARIN grant, concerns the various open source software tools that we maintain and develop.

I mentioned we’re a membership organization. We have 100 participating organizations. Many of these contribute towards our software. Many of these are DNS top level domain registries, Internet service providers, vendors of open source software and DNS hardware, and also a number of the other Regional Internet Registries.

So the software projects. The software we do is not production operational software. It’s not the thing you would run your network on. Rather, it is there for measurement, testing, interoperability, data capture and gathering, analyzing data that you’ve captured, telemetry to measure the performance of your infrastructure. You can see there are a list of the various tools that have received support from the ARIN grant over the past year.

There’s a number of things that we have done with this. When you’re developing open source software everyone is very keen for it to be new software, and there’s authority of interest and people develop new tools or they fund us to develop new tools. Or quite often some of the things that happen is that after that first flurry of excitement, then we finish up inheriting the software that perhaps gets orphaned.

All this software is useful, but the thing about open source is it’s really only useful if it’s actively maintained in terms of things like bug fixes and security patches.

And not everybody is prepared to fund that. Being able to have the ARIN grant to actually fund that has been really useful. One of the other things that we’ve done with a lot of the software is a common automation for development and building. We’ve been able to do, over the past year, to do fully automated package management, so that overall releases, there are ready-built packages for all the common operating systems.

And just by using this software, there’s a whole bunch of things that can do – DNS is better understood; it’s measured. You can find out how the DNS is working on your network and potentially debug it and optimize it.

This is not the only software that we do. We have other open source projects which have been funded by other parties. There’s still a lot of our software development that’s funded by our member subscriptions. But one of the nice things that’s happened over the past year is that ARIN has been able to fund software which we’ve kept in good shape and that’s been in good enough shape that we’ve been able to source funding elsewhere to develop that further.

This will give you an idea of the frequency of releases that we have. You can see the big one there is our domain statistics collector. But there are a whole bunch of other tools that have been worked on.

This will give you an idea of the activity. You can see from the pool requests that we have active participation and contributions from our community. And I hope that the issues created and closed demonstrates we’re responsive to requests and to maintain and improve the software.

That’s pretty much it. You can find more information on our software page. That has got links to things like our licensing policy, links to the mailing lists that we operate for various projects and to our GitHub project pages.

And also if you are interested in funding particular DNS software development then we’re certainly open to that.

And the final thing I’ll say this is not my work. Almost all of this work has been done by our software engineer, Jerry Lundstrom. And Jerry will be happy to answer questions that you have with our software.

One final thing I want to share with you. This is not directly funded by ARIN over the past year but something that we developed is a tool which allows RPKI validation of the path that your name resolution is happening on.

So we have a tool called Check My DNS, and you can use this to verify that the path between your local and name resolver and the authoritative server for the domains you’re querying is actually RPKI validated, which we hope will contribute towards the deployment of RPKI.

That’s all I have to say. Thank you for your attention.

Jennifer Bly: Thank you very much, grant recipients, for those presentations. Congratulations on all the great work you’ve done over the past year.

Now I’ll just give you an update on the 2020 program. The Grant Selection Committee has reviewed applications and made their selection recommendations based on the selection criteria, which included alignment with eligibility guidelines, relevance and reach, impact, budget, and likelihood of success.

The Grant Selection Committee included Michael Abejuela, myself, Peter Harrison, Kerrie Richards, Patrick Voigt, and Matthew Wilder. Thank you, all, for your great work as part of this committee and volunteering to be on it.

And the Board of Trustees has also reviewed and approved the selections. And you will be seeing an announcement soon. If you are with us for the last day of ARIN 46 on Friday, the 23rd of October, you will see a list of those recipients. And I do hope you will join us for that. Next slide.

A few program stats. We received 13 applications this year from one association, seven corporations, and five other organizations as they self-identified. Two were from Canada, seven from the United States, one from the Caribbean, and three from outside the ARIN region.

The categories that they self-selected included nine from Internet technical improvements, five under registry processes and technology improvements, five under informational outreach, and three categorized themselves as research.

The total funding requested was just a bit over $300,000. And the average funding requested per project was about $23,500. Next slide.

And lastly, if you know of a project that needs funding, is not for commercial gain, and it benefits the Internet community within the ARIN region, we invite you to apply for an ARIN Community Grant. The program budget is $60,000 USD, and it will be awarded in varying amounts starting at $1,000 and based on project need.

The call for applications will be issued in spring 2021. And you can learn more and apply at the link on your screen. We encourage you to share about this program with your friends and colleagues. And hopefully we’ll get a lot of great applications.

Paul Andersen: So we’re actually going to – thank you, Jennifer, for that. If there are questions or comments I think we have to save them for time purposes for the open microphone. We’d like to roll right into the next presentation. Thank you, Jennifer, for putting this together. And thanks to all the grant recipients and the Grant Committee for doing that. I hope you all come to open microphone and give us some feedback and comments on that.

So we will move right into the RSD Statistics Report, which is Lisa. Lisa, take it away.

RSD Statistics Report

Lisa Liedel: Thanks, Paul. I’m just going to do some of the RSD statistics. Next slide, please.

The organizations served by ARIN. You see that we have about – almost 40 percent of the organizations are legacy organizations. And we have another 17 percent which are member organizations. Those are organizations covered under Registration Services Plan. And then we have almost 43 percent that are our customer organizations or end user organizations.

Next slide, please. Our IPv4 coverage under RSAs kind of stacks up like this. There’s about 48 percent of our IPv4 is covered under a standard Registration Services Agreement.

We have about 12 and a half percent covered under a Legacy Registration Services Agreement. And we still see that we have about 39 percent that is not covered under any agreement with ARIN at this time.

Next slide. IPv4 RSA coverage. This is just over time to see how it’s been going up for coverage. And we see that coverage under an RSA is increasing due mostly to transfers and now we’re seeing some increase because of IRR and RPKI coverage, just so that members can participate in those.

Next slide, please. This is the waiting list since June 2015. We’ve seen a lot of big peaks and valleys. But we’ve noticed since the implementation of some of the new policies regarding the waiting list and the minimum of a /22 that could be issued, we’re seeing a much steadier flow coming in. And people are actually willing to go on to the waiting list now as opposed to back when there were almost 400 people on the waiting list. It seemed like nobody wanted to be there.

Next slide, please. This is our IPv4 reserve pools for 4.4 critical infrastructure and 4.10 transition space. They look pretty healthy right now. I don’t foresee a problem with them running out anytime soon. And I know when we get space back that were issued from either of these pools, either through revocation or voluntary return, that space goes back to the pool where it came from. Next slide, please.

Under the coverage for IPv6: under Registration Services Plan, we see we have almost 51 percent of users have IPv4 and IPv6. Those under Registration Services Plan that only have IPv6, there’s only about nine percent, but we need to remember those organizations may actually have IPv4 from their providers. And then we have another 40 percent that have only IPv4. But, again, they may also have IPv6 from one of their providers.

Next slide, please. And this is just the IPv6 networks created by year. This includes all the SWIPs that are created from all the ISPs as well. We see we had a pretty big decline into 2020. We hope to see that go back up soon. Next slide, please.

And this is just a few transfer statistics I thought we would share with you. Looks like we are starting to see a nice even pace now with tickets coming in. These are actually completed transfers by quarter. Previous years we saw a lot of spikes, a lot of ups and downs. But it looks like it’s starting to steady out.

Next slide, please. And these are the number of /24s transferred by quarter. And I do apologize. I neglected to include anything that was transferred from other regions. And if memory serves, for third quarter 2020, we only received around 100 /24s from RIPE NCC and APNIC combined. We actually have received our first transfer to come in from the LACNIC region, but that’s not yet been completed.

Next slide, please. And our registration services is offering a new chat service to any member that is logged into their ARIN Online account. We started offering this in April.

We can see right around June and July, we had a pretty good spike of people coming in. And that would coincide with the release of our Internet Routing Registry updates. And we can just see that the number of contacts that we have or conversations that we have opposed to the number of visitors, that looks a little off. But that just means that we had multiple conversations from the same visitor or the same customer.

And the conversations that we have are about 50 percent of the call volume that we typically get. So, we’ve really increased our contact with our customers, which is great. And next slide, please.

That’s it. That’s all I have.

Paul Andersen: Thank you, Lisa. We have time for a few questions. And you also have the open microphone if you can’t think of them now. A few seconds here before moving to our Routing Security and Services Update by Mark Kosters.

Okay, looks like no questions, but Lisa will be around for the open microphone if you think of them. Thank you very much, Lisa, for that presentation.

Mark, over to you.

Routing Security and Services Update

Mark Kosters: All right. So hopefully you all can see me. I certainly can’t see you. This is Mark Kosters, and I’m here to talk about engineering matters. And I’m speaking to you in Chantilly, Virginia, at ARIN’s offices. And let’s go on to the first page here.

Next slide. Here you can see our agenda. And our agenda is – ARIN Engineering is actually working on four things right now. It’s a four-pronged approach. We’re working on tech debt, which I’m not going to talk about so much here. But I am going to talk about the IRR update and statistics, RPKI update and statistics, and finally directory services and its statistics.

And what’s interesting about this is there’s a lot of interesting behaviors here. Some of which I really don’t understand and maybe you can help me understand a little bit.

Next slide, please. So as you all know, we rolled out a new IRR that lives beside the old Internet Routing Registry on June 10. So, we now have two sources of information.

First, we have ARIN, which is indicated in the regional Internet Routing Registry system as – by its source. And we have two sources that actually come from our database.

The first source is ARIN, which is comprised of authenticated IRR objects.

These things are tied to the networks of which you hold. ARIN-NONAUTH is essentially the old system where they’re nonauthenticated objects or objects from organizations that are not under contract.

So we have two separate routing registries here, both of which are published from ARIN. So the authenticated side is truly authenticated against ARIN’s resources, and only those users can actually put routes and route6 objects based on their network space that they have within it.

And you can do that via two ways. One is if you had an existing maintainer before we did the transition on June 10, you could use the template system. Or if you come in since June 10, you can use our web interface, which is new.

ARIN-NONAUTH still exists, and it only exists for those who had maintainers before June 10. No longer can you create new maintainers in the space. It has no authentication of objects, much like the old IRR did. And you can only use the template system.

Also one of the things I will say, jumping back to ARIN’s authenticated side, is that once you – if you were in an old system on June 10 and you decided to use the web interface on June 11, from that point onward, there’s adequate warnings that were put into place, that you are then graduated from the template system into the web UI system.

So anyways, that’s one thing I wanted to make clear. Since June 10 we’ve put out numerous incremental improvements. And we continue on. So let’s go on to the next slide, please.

So what we’re planning on doing right now is we are making sure that all the staff actions that are done, like transfers, or changes in the ARIN’s registry, are also reflected in the IRR.

For example, if the space that was once held by an organization – that’s transferred to RIPE, all those routes and route6 objects, et cetera, are going to be removed as part of the transfer. So as well as getting new space or giving space to someone else, those routes are going to be removed if they existed prior to the transfer.

So one of the other things that we’re working on is focusing in on a new RESTful API. We’re looking at the existing APIs that are out there and trying to do the best thing that the community would expect.

And it’s going to be integrated within our existing RESTful interface system called Reg-RWS. And you can anticipate seeing it in January of 2021.

Next slide, please. And here’s where things start getting interesting. As you can see here you have this sort of blue-green line, which is the old IRR, the ARIN nonauthenticated IRR. And you have the darker blue line that is authenticated IRR. As you can tell the maintainers that transitioned, that were available on the old IRR, there’s 2268. And it graduated by 800 to a little over 3,000. And of course there was a corresponding drop within the legacy or old IRR.

Next slide, please. But this is where things kind of get interesting is you would think that the old IRR, the nonauthenticated IRR, would start having a drop in the number of routes.

That is certainly not the case here. You could see that it increased by almost 10,000. Likewise, if you see here, the number of authenticated objects also increased by a good number as well, so 8,000. So this is one of the things I found fairly surprising when I went ahead and did the graphs for this.

Next slide, please. Route6 objects is slightly different. Here you can see that the nonauthenticated portion of the IRR has been essentially flat but the number of IRR objects that are, that in the authenticated side went up by almost, by a huge amount, by almost 4,000 routes.

So definitely route6 is definitely preferred by the new authenticated IRR. Next slide.

So here you could see our RPKI statistics. One of the things that we’ve put out is we put out a new HSM. The 4765s that we had before has been replaced by IBM 4767. And we did this because the old system was end of service, end of life.

We had to import this new system from Canada, which was interesting. And had to go through a way of moving through one country to another requires a sort of importer that is acceptable by the US government, which we did, and which was kind of interesting, but it happened. And we are able to bring these things in house and actually deploy these things.

So when we did this, we actually implemented a very simplified interface to our new HSM and removed many of the architectural limits that caused restrictions in various areas. For example, one of the things that we had with the old system is that we could only have a few numbers of ROAs that could be deleted at one time. That’s now been changed. It’s a much higher number – it’s not unlimited but certainly much higher.

We also had the restricted number of manifests that we could create in the old system. That is now gone.

We have limits but are still working on upping them over time. So, for example, if you want to delete more than 20,000 ROAs at one time, go ahead and contact RSD.

Now, right now there’s no one organization that has more than 6,000 ROAs. So I don’t see this as really a problem at the moment. But it’s something that we are actually working on.

Next slide, please. So our challenge here was that the initial rollout was very smooth on August 12, 2020. We tested the code and it worked great. ARIN’s – RIPE’s validator and NLnet Lab’s Routinator. And when we deployed all the tests and all the web sites were green, and everything was golden.

But within an hour we received notifications of validation error reports from those people who use the FORT and OpenBSD RPKI client. We then worked with the OpenBSD folks with our own engineers to dissect what was actually going on, and actually found a very small encoding error that we had to fix.

This was fixed within 24 hours. It was a fairly obscure thing, and we were very happy on the efforts that the OpenBSD folks had to help work with us, because that greatly reduced our time to figure out what the heck was going on.

As we went through this process, we discovered that there’s many different validators that have different ways of interpreting these crypto objects that come out of the RPKI system.

This led to a very significant discussion within the IETF, which is the Internet standards body for the Internet, on how to handle these errors.

And frankly there was no good or firm conclusion on the best way forward within IETF. And this is something we looked – we were looking for guidance from the IETF.

So lessons learned here is, we’ve tested against two validators. But we need more. We need to go beyond what RIPE and NLnet Labs have. We’re going to list those sites that, list those validators that we’ve tested against on the ARIN website. And we’ll also have monitoring expanded to include multiple validators as well.

Right now, every time we deploy a new update to the RPKI system in terms of putting out new data, new ROAs, everything else, we actually revalidate to make sure it’s correct before we push it out. And we’ll include beyond the existing validators we use today, which are RIPE and NLnet Labs validators. We’ll go ahead and start looking at others as well. Next slide, please.

Here you can see our statistics that I brought up many times in the past. And the interesting things I’ll mention here is in May we had a significant uptake from the number of people who are using delegated. It was one or two for years.

But it jumped up to eight and it’s because of a new delegated system called Krill that’s available by NLnet Labs that people started experimenting with.

Right now we have nine delegated people actually in the system, of which five have – it’s a two-step process. First they say, I’m going to run delegated. Then the second thing they do is they say, here’s a cert that we’re presenting to you to set up the RPKI service.

That second step has only been accomplished by five of the nine people. So there’s essentially, even though there’s nine that said they want to join in the delegated system, there’s only five that are actually playing with it today.

The other thing that’s of interest is you’ll notice from May of 2020 until September of 2020, we’ve had a huge uptake in the number of ROAs and also covered resources. So you can see that RPKI system is starting to take off.

Next slide, please. Now what I want to switch to is our directory service systems, which is comprised of Whois, Whois-RWS and RDAP – and to a lesser degree RWhois. Much of our staff time is actually spent on these systems.

We have pretty heavy use on these systems. We have occasionally alarms going on these systems from people hammering them quite hard. And we spend a lot of time diagnosing what the problems are and figuring out how to solve it.

This is also the largest use of our resources. We have three what we call “public facing sites,” PFS sites, that serve up multiple iterations of these servers.

So there’s three main sites, and each site has six or more instances of these engines running on these boxes, all sort of behind load balancers so that you don’t see when one goes down or two goes down or whatever else. All this is transparent to you.

But you can see that this is pretty significant amount of resources. And these are not small boxes. These are fairly beefy boxes. Next slide, please.

And you can see that we are seeing traffic unlike what we’ve ever seen before in a consistent basis. You’ll see that in 2010 we had a spike. And it was a very bizarre spike. And it was something dealing with some changes made with various people using open ID software. For some reason they were actually coming and actually doing a query against us to find out who that client was.

And it was a mistake and that was taken out. And the social media sites that have used it have soon found a different way of actually finding out who they’re actually talking to. Now it’s a slightly different story where these are more consistent. You can see on the blue line how we’ve actually gone up on Whois traffic. And you can see that Whois-RWS is also seeing a sizable increase as well.

Next slide, please. And here’s our RDAP statistics. It also is growing. You can see that at one point we had a peak on traffic, a little over 200 queries per second. And that was a spike. It has come down.

Now we’re starting to see steady growth again against RDAP. And what was interesting here is we’re seeing close to 200 queries – well, 175 queries per second against our RDAP nodes, most of which are on v4. Very little on v6. Most are on v4. And it’s about four percent of v6, and the rest on v4.

And what’s interesting here is that people are starting to use RDAP. And ours from the sharing that we’ve done with the other regional registries, we’re by far the highest trafficked site for Whois, Whois-RWS and RDAP in terms of number of queries seen. For example, APNIC is seeing a third of what we’re seeing today, if not more.

Next slide. Thank you. So my question is, why do we see such increased use? Do people not understand or know about getting our data in bulk via bulk Whois? Maybe the other thing is, people legitimately need the data but they need it in real time. And there’s a couple of cases of that.

Maybe people are servicing trademarks or some sort of DRM sort of technologies that need to see these things in real time – monitoring for illegal use of copyrights and so on.

It could be for inventory management. Who knows? And we have also seen malicious bots, and we’ve seen widespread activity against malicious bots. And then there’s also other things, and I brought this up in the past, of people using recipes via cloud services to harvest Whois data. And there’s one case in particular. Mark’s blog – and, no, it’s not me, but a different Mark who he came up with a “here’s how you go ahead and set up Amazon Web Services and here’s how you get data from ARIN and how you can really sort of blast them to get all the data you need.”

So the end result is we spent a large part of time actually tuning our systems to deal with the increased load. We’ve done a lot of code efficiency works. We’ve done a lot of OS tuning work. And we’ve also increased the use of tarpitting on our load balancers.

Essentially if they come over a particular query threshold, we put them in the slow lane. And after a period of time they keep up that traffic we actually start dropping them off in terms of their queries.

Next slide, please. So with that, any questions?

Paul Andersen: Any questions for Mark? Mark, you already have a question. Why don’t we go straight to it and I’ll ask everyone to quickly queue up and quickly go into open microphone as well.

So the first question is from Mike Mazarick. Does the HSM and the crypto security have any commonality?

Mark Kosters: The HSM and the –

Paul Andersen: – the crypto security have any commonality, was his question.

Mark Kosters: That’s sort of an interesting question. So the HSM is – essentially what it does is it creates two things: keys and also signatures based on those – those keys or other keys.

And so essentially it’s a signature generator and also a signature signer.

And, so, those things are high security modules and hardware security modules, whatever you want to call them, and they’re actually out there for people to use.

Paul Andersen: Thanks, Mark. I don’t see any other questions burning, however Mark will stick around as are all the presenters who were here this afternoon.

With that, we’ll open it up to open microphone.

Public Policy Meeting, Day 1 - Open Microphone

Paul Andersen: Open microphone is, generally we say, a little bit focused more on the policy today. But we’ll have one today, one tomorrow, and one next week at our Members Meeting. So, if you have questions on the presentations, questions that have come to your mind today or just general questions or comments, now is the time to raise it.

And the first comment is from Aaron Hughes, 6connect. Just want to thank the ARIN engineering team, in particular, for the really easy interface for ROA creation. Even if customers don’t have it, it makes it great for those who do. D’oh, too late.

Mark Kosters: Thank you.

Paul Andersen: Other comments, questions, please raise your hand.

Zoom Host: Paul, we have a question from – you have a question from Aaron Hughes.

Paul Andersen: I already did that one.

Zoom Host: You did that one, okay.

Paul Andersen: I wanted to keep that ball rolling.

Other comments or questions, please raise the hand. Going, going once. Quiet bunch today, but there are, of course, breakout rooms coming up shortly which we’ll open up.

Okay, not seeing any questions, you obviously can put your questions in chat. You can, of course, reach out to the Board or the AC or staff via the various lists and email. And, of course, you’ll have your opportunity tomorrow and next week, so we hope you’ll use it.

So with that, I think we’re going to go – end of the in-person. Again, there’s going to be some breakout sessions, which we’ll explain. I’ll turn it over to John Curran for the closing remarks. Thank you to all our presenters.

Public Policy Meeting, Day 1 - Closing Announcements and Adjournment

John Curran: Thank you, Paul. Thank you to our presenters, staff presenters for their work. I’d like to give you some closing announcements.

I’ll note that we have breakout sessions going on right after this meeting, or not right after. So let’s talk, at 3:15, so in approximately 25 minutes, you – it’s going to be separate Zoom rooms. Each one is a room where you would go to have smaller chats with people on particular topics.

So we have six breakout rooms. They’re shown on the screen. One is to meet the Board, the AC Chair, and the AC Vice Chair.

One of them is on RDP ARIN-2020-2, more discussion on that.

One is an NRPM Cleanup Working Group. The ARIN AC has a team that’s working on catching up, cleaning up errata on the NRPM, the Number Resource Policy Manual.

One is on the Policy Development Process Improvements Team. Again, the ARIN AC has a group that’s been working on that. Interested in your thoughts on improving the Policy Development Process, which we’re following today.

We give Policy Experience Reports from time to time. And there’s a group working on improving our Policy Experience Reports. And that’s also going to have a breakout room.

And then a room regarding the ARIN Fellowship Program. We have a fellowship program which brings people to learn about ARIN and how our meetings work, our policy process.

It’s usually something we do on face-to-face meetings. But we’re going to be talking about the fellowship program, talking about directions to take it.

We’ll have staff members in those rooms, so they’re available. And that’s going to be at 3:15. So, you get a quick break, and then you can continue with the breakout sessions. When the breakout sessions are over, we’re not coming back as a full meeting. We’ll see you instead tomorrow.

Next slide. So, day two starts tomorrow, noon Eastern Time. And I look forward to doing another day of interesting discussions. We have some policy work and then we have some reports and ARIN staff reports.

So thank you very much for coming. I look forward to seeing everyone in the breakout rooms or seeing you tomorrow.

Paul Andersen: Before you do drop off, just because there’s a bit of an internal chat, the link to the breakout session is in the chat. We’re just making sure it’s on the website. It may have not made it there. And I’m sure that is eagerly – but just before you drop off, make sure you see the link. Amanda has posted it in the chat there, so you can just join that link now if you want. And at 3:15 they’ll commence. Just so you guys know where the breakout rooms are. Sorry about that, John.

John Curran: Very good. Look forward to seeing everyone either in the breakout room or seeing them tomorrow. It’s been a good meeting. Bye-bye.

[Meeting recessed at 2:54 PM ET]