ARIN 41 Public Policy Meeting, Day 1 Transcript - Monday, 16 April 2018 [Archived]

Please Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting. If additional clarification and details are required, videos from our original webcast are available on our YouTube channel.

For an executive summary of this day of the meeting, read the daily digest on the TeamARIN website.

Public Policy Meeting, Day 1 - Opening Announcements

John Curran: Okay. Please come in and be seated. I’d like to welcome everyone. I’m John Curran, President and CEO of ARIN, the American Registry for Internet Numbers. I’d like to welcome you to Miami for ARIN 41, our Public Policy and Members Meeting. Welcome.

We have a full agenda for today. So I’d like to get started. We have a number of folks. First, the meeting is under the auspices of the ARIN Board of Trustees. They are all in attendance here at this meeting.

And so they are in the room as well – Dan Alexander, raise your hand; Dan’s back there. Paul Andersen, our Chair. Nancy Carter, our Treasurer. I’m the President and CEO. Patrick Gilmore, Board member. Aaron Hughes, Board member. And Bill Sandiford, who is our Vice Chair.

We also have our Advisory Council here. And to save time I’m not going to read all the names, but I ask the Advisory Council members, please stand. Come on, stand up. There’s only four of you, there’s more – five, six – there’s a few. Stand up. You’re an Advisory Council member, come on. Thank you.

Okay, the Advisory Council is the one – thank you.

(Applause.)

John Curran: Okay, round of applause for the AC. They’re the ones that do the hard work.

The Advisory Council is responsible for the facilitation of the ARIN Public Policy process. So our Policy Development Process is actually administered by the AC. They’re the ones who work on the draft proposals that come in from the community.

They’re the ones who refine them, who try to work out any rough edges and then bring them forth here for discussion. They are elected just like the Board. We have our elections every year for the Board of Trustees and the ARIN Advisory Council.

For the NRO Number Council, ARIN region, the NRO Number Council is the body that works on global policy development, a 15-member body with three from each of the Regional Internet Registries.

So the three from the ARIN region are Kevin Blumberg. Kevin, where are you? And Louie Lee. Not here. Okay. Is his hat here? No. And Jason Schiller, who is a remote participant.

The 15-member NRO Number Council is also referred as the Address Supporting Organization Address Council. And the reason it’s referred to that is when we’re working within the ICANN community, the number community is referred to as the Address Supporting Organization. So the NRO Number Council you’ll also see referred to as the ASO AC in that context.

We have a number of attendees from remote, from other RIRs. My RIR colleagues, raise your hand. AFRINIC and APNIC. Paul Wilson I know is here. And LACNIC, our friends from LACNIC. Yes. And RIPE. Yes. Excellent – and company. Very good.

We have the full ARIN management team. I won’t go through all the names. I’ll just tell you this is the ARIN management team. One important development, Richard Jimmerson – Richard, where are you? For those who don’t know it, Nate Davis is ARIN’s Chief Operating Officer, and Nate has been working with ARIN now, well, forever. He’s basically been the backbone. He’s the one that does all the work and I’m the one that gets all the credit.

Later on this year, at the end of this year, Nate’s going to retire to sit on a beach and play golf and all those things, and we are going to need a new Chief Operating Officer. We started that process early. And Richard Jimmerson is our Chief Operating Officer-elect. Richard, stand up.

(Applause.)

John Curran: We’re not sure if we call him COO-elect or COO-prime. Evil Nate has come up as another name for him. But Richard will be taking on that responsibility so you’ll see him ghosting Nate and following in parallel.

I’d like to welcome the ARIN 41 Fellowship recipients. ARIN has a Fellowship Program which enables people who might need support in order to attend the meeting in person. And we have fellows that we bring from each of the sectors from the ARIN region. So from Canada, can I have our Canada fellows and mentors stand up.

Each fellow, come on, Canada, there’s the mentors. Where is my fellows? There we are. There we are.

Okay. Each fellow is peered with a mentor who helps them get familiar with the meeting and how we do our processes. Can I have the Caribbean fellows stand up and their mentors?

There we go. And these are people who are coming to ARIN to learn and to get familiar. The mentors help with that.

And then in the US and outlying areas, our fellows, please stand. Thank you.

These are people learning about the ARIN processes through the Fellowship Program.

Newcomer Orientation. So people who are relatively new to ARIN, we run a Newcomer Orientation usually the day before – that happened yesterday – where they get to meet the ARIN team and learn about how we do things.

And we also do a drawing for the people who attend the newcomer orientation. If I reach down here, there will be a bowl. I need to draw from the people who fill out the survey. I’ll ask a random participant, Owen, if he could come up and draw one.

Observers to repeat ARIN meetings will know my RAND function is broken, yes. For the Newcomer Orientation survey, thank you for filling these out; they help us tune the survey. The recipient who will receive a $100 ThinkGeek gift certificate, which we’ll mail out to them, is Blaise Arbouet. Thank you for filling out these. They’re invaluable to our process.

I’d like to welcome the remote participants. You don’t need to come to ARIN. We do welcome you and it helps, but you can also participate remotely if you can’t make it.

We have a webcast. We have a webcast, which is available. We also have an alternate YouTube webcast. So two different streams out there.

We have a live transcript. So this is for people who want to be able to follow. You might be in a place where you can’t listen live to the audio but you can see the script. Sometimes it helps to go back and see what someone said.

So we have a live transcript. This means it’s important for everyone to speak slowly and clearly at the microphone. There’s some wonderful person back there trying to do live transcription. And so in their name, speak slowly and clearly when you’re at the mic.

All the meeting materials that we have are available online. So they’re in the Discussion Guide that you have. Everyone should have a Discussion Guide like this, or its electronic equivalent. And it has all the proposals being considered, copy of the policy process and the current policies.

We have a virtual microphone and consensus polling for remote participants. Even though you’re not here, you can participate in the discussion. Raise your hand to ask a question. It will be read out by the remote moderator.

You can actually, when we do a poll in order to get a gauge of support, you can participate in that as well.

You must be registered in order to participate in the virtual microphone and the consensus polling. Why? This is our public process. We literally will change our policies based on what happens in this meeting. People are entitled to an accurate record of what was said by whom that went into our Policy Development Process. So you must be registered in order to be a remote participant who participates in the microphone and the polling.

If you just want to watch the media stream, you can watch the media stream. If you actually want to participate, people are entitled to know because we need an accurate record of how our policies were developed.

Okay. Attendance. So we have attendees from Canada, 10; United States, 84; 38 remote participants; eight from the Caribbean; and 16 from outside the region.

Emergency procedures. Please note the emergency exits. Mostly behind you. In the event of an evacuation, the front of the hotel is where we all gather. Hopefully we don’t need this. But always good to know.

I’d like to thank our sponsors. Webpass from Google Fiber and webcast sponsor Google as well.

(Applause.)

John Curran: Very good. Okay. We have a meeting app. You can go download the meeting app from the iPhone App Store or the Google Play store and open it up and it will give you schedule, information about the events. Very useful to have.

Rules and reminders. When we’re speaking at the microphone, again, this is our Public Policy Meeting. This is governed by our Policy Development Process. The Board of Trustees chair will moderate discussion of the draft policies so that everyone can speak and everyone can be heard.

We’re not trying to have a free-for-all here. One person speaks at a time. The Board of Trustees chair recognizes you, and you speak.

When you’re recognized, state your name and affiliation at the microphone each time. We all – a lot of us know each other, but please state it so it’s in the record.

Please comply with the rules and courtesies in the Discussion Guide. There’s a set of rules. We have a standard of behavior that governs people here.

We’re all professionals. We’re all here to get a job done. Please treat each other with mutual respect. If there’s a challenge with this, then we have processes for dealing with it.

Never really had a big problem, but they are there. If anyone should have an issue, please contact myself or look at the guide for more information.

I found a blank key. That’s very cool. Okay.

Today’s agenda. So after – we’re going to have the Regional Policy Development Update, where Sean goes and summarizes what’s happening in the other regions for policy.

The Advisory Council will give a readout of all the policies, all the proposals on their docket so that you have a full report. You might have submitted a proposal, want to know where it is. It’s not yet up for discussion. That will be on the On-Docket Proposals Report.

We’ll do a Policy Implementation and Experience Report, where the ARIN staff selects a few policies and talks about issues or concerns or just how well they’re running, which helps feed the process for developing new number resource policy.

We’ll have discussion of two policies on the docket: Draft Policy ARIN-2018-1 for allowing interregional ASN transfers; and Draft Policy ARIN-2017-8 to amend the community networks definition.

We’re going to have a Data Privacy Update session, and then we’ll talk about orphaned Points of Contact and organization identifier deletion.

So that’s the agenda. Pretty full day. Oh, pretty full morning. Wow. Okay. Yeah, I gotta talk fast.

So we’re going to have in the afternoon NRO Activities Report, the ASO Future Structure consultation. We’ll have two more draft policies being considered: 2017-9, Clarifying the initial block size for ISP transfers; and the other one, Clarifying ISP initial allocation and permit renumbering. These are actually related. It’s harmonizing A against B or harmonizing B against A, depending on which one you want to do.

We’ll have a discussion of the ARIN Fee Schedule Update that is being proposed. We’ll have the IETF report, giving a summary of the last two IETFs. And we’ll have a discussion of the ASO Review consultation.

There’s a Metronome Room down the hall, and it’s available for people who want to gather and discuss policy ideas. If you have an idea for a new policy or you have a question, it’s a breakout room you can use for policy discussions.

Tonight’s social is at a place called Ball & Chain, interesting, and it will be 7:00 PM to 11:00 PM, and your badge will get you in. And there are shuttles running from the front of the building on 6:45, 7:00, and 7:15. There’s dominos, cigar rolling, salsa band, Cuban style, a lot of fun.

So, at the head table, our Chair, Paul Andersen; Tina, Chair of the AC; Leif Sawyer; Bill Sandiford, our Vice Chair; and Alicia – Alicia, Alicia Trotman, who is also on the AC. Thank you.

(Applause.)

John Curran: As I said one day, I was looking at Vint Cerf and I couldn’t remember his name – to give you an idea how bad I am with my faces.

First presentation, Sean Hopkins will come up to give the Regional Policy Update.

Regional Policy Update

Sean Hopkins: Good morning. Good morning. You know what I expect.

Audience: Good morning.

Sean Hopkins: How many of you went to the PDP tutorial yesterday? Raise your hand. Excellent. How many wish you were there? There it is. Excellent.

During that, I’ll just note real quick, I asked a question where if there are places where knowledge and awareness of the PDP have not yet reached but ought to and you’re aware of one of those places, find me. Tell me what those places are. Thank you.

Okay. This report’s going to cover four regions: AFRINIC, as you can suppose covers the continent of Africa; APNIC, covering eastern Asia, Australia, New Zealand, neighboring countries; LACNIC, covering the remaining parts of the Caribbean and Latin America; and RIPE NCC, coverage Europe, Russia, Middle East, central Asia.

AFRINIC. This one was just ratified at the end of last month. Lame delegations in reverse DNS for AFRINIC. Gives a little bit of instruction for staff on how to treat these records if they’re marked as lame, if they need to be removed.

If all the name servers are lame for a given delegation, they remove the domain object entirely, et cetera. That’s pending implementation.

Some new stuff they’re talking about, Policy Development Process Bis. They’re doing a rewrite of a significant portion of their Policy Development Process, something that ARIN does not do through the PDP itself. But this is under discussion in that region. There’s a number of changes there.

Route aggregation policy is under discussion. And then of course Internet Number Resources review by AFRINIC, regular audits of members and recovery of resources are involved in that. There’s a couple others here.

We’ve got Soft Landing Bis takes a hard look at the previous soft landing policy they had in place. And they’re working on a rewrite for that. And there are several new proposals that they’ve received that are just getting discussions going. They’re going to have a couple of meetings this year just like us. So we’re going to have updates coming on those.

APNIC, a couple policies here had unique cases. At the last APNIC meeting the no-need policy and temporary transfers policy, the author was deemed unreachable. So they actually had consensus taken within the room to allow a new author to submit the same proposal and keep discussion going.

A few more on their docket. They’re going to have a modification of their last /8, their exhaustion plan, the 103 /8 transfer policies, getting another look and clarification on IPv6 sub assignments.

That one is rather new but it’s been shopped around at a couple of other Regional Internet Registries.

LACNIC, first up there’s a proposal to create a global Internet registry – that’s fairly new – an update to transfer policy for mergers and acquisitions, and then something on IP-based geolocation, where LACNIC would be posting a public file with country information on each assignment and sub assignment.

Couple more. Review and correction of a few errors in the v6 policy. It’s a little bit of cleanup in their policy manual there.

Dash 5 is registration validation of abuse contacts and then another PDP edit, simplification of the PDP. This is, again, something that ARIN does not do within the PDP itself, but they have a proposal there. They recently had another proposal that updated their PDP and shortened their last call window, and that went through.

There’s one more, clarification on IPv6 sub assignments, very similar to one you just saw. And there are a few more here. These are brand new as of the 29th of March. And as of my knowledge, there’s no English version posted just yet, and my Spanish is quite terrible. So when I have more information, I will relay it.

For RIPE NCC, there’s another abuse contact validation proposal that’s actually being discussed by a working group that is not the policy-specific working group. This one is being taken on by the anti-abuse working group in that region.

And there’s another for organization and LIR relationship clarification on v6 policy. Impact analysis I believe is still underway for that one. It may have just been completed.

For everything I didn’t say, there are a couple of links here that would be helpful for you to get involved if you want to participate in these discussions. You’ll note there was one that was actually being shopped around a few different regions. It will be interesting, at least for me, to follow that as it travels around the world.

And of course we have a comparative policy overview posted on the NRO site that gives a snapshot at maybe 100 feet, we’ll say, of how each RIR treats certain situations.

And that’s it for me. If you have any questions, I’m happy to take them. And if not, I’ll be wherever coffee is. Excellent.

(Applause.)

John Curran: Very good. Next up we’ll have Tina Morris to give the Advisory Council Docket Report.

Advisory Council Docket Report

Tina Morris: We have a pretty full docket. We have five Recommended Draft Policies. All of these Draft Policies have undergone staff and legal review at this time. And we’ll do straw polls for each to get the sense of the room.

Something to be aware of with Recommended Draft Policies, they may be sent to last call if they remain unchanged and supported at this meeting.

We have three Draft Policies that are currently works in progress and two proposals that have been assigned council shepherds, but we’re still working to clarify text with the authors, and they’re not on the ARIN 41 agenda.

In addition, there are two editorial changes in process. We have reallocation reassignment language cleanup that was out for community review that closed on March 23rd. We’ll review those with the AC on Wednesday and decide if those move forward.

And the other is correct references to our Whois, which was formerly Prop 251. That’s still open for community review, closing on April 19th.

The Recommended Draft Policies are listed here. We have 2017-3, Annual Whois POC Validation; 2017-8, Amend Community Networks; 2017-10, Repeal of Immediate Need for IPv4 Space; 2017-12, Require New POC Validation Upon Reassignment; 2017-13, Remove ARIN Review Requirements for Large IPv4 Reassignments and Reallocations.

At the meeting, our goal is to discuss policy, get community feedback. It’s critical to the Advisory Council to have this feedback from you. Please ask questions. We’ll try to engage you in questions. Please let us know if you have any concerns.

We want to leave the meeting with consensus on – especially on Draft and Recommended Draft Policies, whether they should move forward, be changed, whatever. So please speak up. The AC will meet again on Wednesday to discuss. And Recommended Draft Policies may enter last call if not substantially changed.

Draft Policy is this slide; it should have been earlier. The Draft Policies in the discussion are the clarification of initial block size for IPv4 transfers; 2018-1, Allow Interregional ASN Transfers; and 2018-2, Clarification to ISP Initial Allocation Permit Renumbering. We’ll be doing – a straw poll has been requested by the shepherds on two of these but not all three.

We have a policy breakout room, the Metronome Room, apparently to the right as you leave this room. And there will be open policy discussion throughout the meeting.

Again, I cannot emphasize enough the AC absolutely needs your feedback. Please come to the mic, please find an AC member. Please just let us know what you think about these policies.

Any questions?

(Applause.)

John Curran: Next up, John Sweeting for the Policy Implementation and Experience Report.

Policy Implementation and Experience Report

John Sweeting: Good morning, everyone. Welcome to ARIN 41 here in the lovely city of Miami. I’m John Sweeting, Senior Director of Registration Services. And as John mentioned, I’m going to give an update on the Policy Experience Report.

This report’s given at every ARIN meeting, and the purpose of the report is to provide feedback to you, the community, on the Number Resource Policy Manual policies.

We cover a variety of reasons for being included in this report – policies that may not be working as expected, discrepancies in the policies, customer feedback and ideas for potential new policies.

So some of these are my staff come to me and say: Hey, John, you know, we’re looking at these policies, and there’s a different policy under Section 4 than under Section 6, and is that what the community intended?

The only way we could figure that out was to bring it here to you and ask for your input, which is what we have to have in order to change policy is, you just saw through Sean’s briefing and what Tina and the AC do.

So what we are asking you to do on these issues that I’m going to discuss is to propose a change or removal of existing policies, propose new policy, or sometimes it’s leave the policy as is. It’s working as you intended. We just don’t understand that. So help us.

Okay. So the policies that I’m going to review today, it’s going to be 4.4, Micro-allocation, compared to 6.10.1, Micro-allocations for Critical Infrastructure; 3.2, Distributed Information Server User Requirements; and 4.1.8, Unmet Requests in the Waiting Lists. Those are the actual corresponding NRPM paragraphs, the subparagraphs.

So on the IPv4, IPv6 micro-allocations, for IPv4, the policy says the exchange point operators must provide justification for the allocation, including connection policy, location, other participants, minimum of three total, ASN, and contact information.

For IPv6, it states the same thing, but the minimum participants is two. We looked at this and we said this could be exactly what the community intended, or it might just be that those two policies were made at different times and we weren’t consistent with it. So we’re asking the community if this is a bug or a feature.

On the 3.2, Distributed Information Server Use Requirements, which is today RWhois, the main one being used, I think it might be the only one that’s being used today, from 3.2, it’s the distributed information service must be operational 24 hours a day, seven days a week, to both the general public and ARIN staff. The service is allowed reasonable down time for server maintenance according to generally accepted community standards.

So we run a cron job weekly on Wednesdays to pull the status of all the RWhois servers that are registered and supposed to be available 24 hours a day, seven days a week to the general public and to ARIN staff.

And this is the result of the last few. As you can see, we’re not really complying with the policy as the community intended it. More than 80 percent of these servers are down all the time. That’s not a generally accepted period for maintenance.

So just a little background, historically, the enforcement that ARIN had was that when every – people came back for additional IPv4 addresses, in order to validate usage, we had to see their – if they were using RWhois as their method for reporting it, we had to be able to see that.

So people were very good at keeping their RWhois servers up and operational and updated so that they would be able to get their IPv4 addresses whenever they needed them.

Well, other than that, policy does not specify any enforcement mechanism for not meeting the uptime requirement, which makes it a little bit difficult for ARIN to enforce and go out and tell people, hey, you’ve got to get your engineers on this and keep this up and keep it updated.

Several enforcement mechanisms have been proposed to my staff as well as to me as well as to other people, ranging from don’t allow, take away their reverse until they get their server back up, to take – start publishing this weekly report on our website and doing a public wall of shame and so the operators community out there can be the ones to be the enforcement mechanism and reach out to the people they know that aren’t complying and to other various proposals.

What I’m asking you here today is for your thoughts and ideas on how we can obtain or enforce that policy that says these servers have to be operational and reachable 24 hours a day, seven days a week.

The last item I wanted to talk about was the Waiting List. This is the policy on the Waiting List that appears in NRPM. If we don’t have a contiguous block, which this was written prior to free pool depletion, so some of it doesn’t quite make sense today, but we still don’t have contiguous block of addresses to fulfill requests.

So today basically you don’t come in and request IPv4; you request to be placed on the Waiting List for IPv4.

The position of the qualified request on the Waiting List is determined by the date it is approved by RSD. And each organization can only have one approved request on the waiting list at a time.

And as the address blocks become available, ARIN fulfills the blocks on a first-approved basis subject to the size of the blocks and timely revalidation of the request. Of course, some organizations have to file through and sign RSAs and pay some invoices associated with them.

There’s no partial fulfillment of a request. We have to be able to fully fill a request based on the maximum and minimum prefix that will be accepted. That is determined at the time that they’re placed on the waiting list.

Maximum cannot be changed. Minimum can be changed, and you can maintain your place on the waiting list at any time that you’re sitting there on the waiting list.

And any request that’s met through the transfer process will be considered fulfilled and will be removed from the waiting list. And on that, it’s basically no matter what you’re on the waiting list for, if you receive addresses through a transfer, you will be removed from the waiting list.

So if you’re on for a /20 and you go out and get a /22 from the transfer market, you’re still going to be removed and have to come back in and requalify for a smaller block if that’s the case.

The good news, it’s still working. At ARIN 39, the statistics I reported were 195 requests had been filled. 136 requests had been closed. Mostly due to being fulfilled on the Waiting List. And there were 291 organizations still waiting.

Today, here at ARIN 41, we have filled 568 requests. 231 have been closed. And there’s 193 still waiting on the Waiting List.

So, as you can see, it’s working as intended. It’s a good policy. Last year I gave some suggestions on things you might want to look at as far as tweaking the policy, and we received – we didn’t receive any proposals.

So we take that as the community feels that the policy is still working as intended.

And that’s it. Questions?

Kevin Blumberg: Kevin Blumberg, Toronto Internet Exchange. Could you go to the critical allocations slide, the very beginning one. You asked us a question in regards to number of participants: two versus number of participants: three at the very beginning.

It would be very useful to know over time how many of the resources in those blocks have been used. Those numbers were changed to make it – to promote what was expected to be a big uptake in IX deployments, and I think that having that information over the last – since that policy came out, I think it was two, three years ago, would definitely help inform the community and allow them to make a more educated answer.

John Sweeting: Can I hold you for a second. I was trying to go back, and I’m not able to go back. And I think, Susan, are we not – is my presentation not available any longer?

John Curran: Can we get his slide back? Thank you.

John Sweeting: Now if you would please summarize again.

Kevin Blumberg: So approximately two years ago there was a policy that would change it to a minimum of three in regards to the micro-allocations in 4.4. I think there’s an expectation of a growth of the number of IXs in the ARIN region.

Before we look at changing those to being the same, there’s a very good chance you might want to change those to be different. And the one thing to know is what the usage of the micro-allocation pool has been since the last policy came out about two years ago; that would help inform the community as to should those numbers be the same or should they be changed.

John Sweeting: That makes sense. And I’ll get that information and report it back here this morning at some point.

Kevin Blumberg: Appreciate it. Thank you.

Rob Seastrom: Rob Seastrom, Neustar. I’m going to preface this by saying I’m completely aware of how big a lift this is and that there’s some realistic issues with what I’m about to propose.

However, I think it’s time that we give retiring RWhois as a way to comply with ARIN’s requirement for publishing the information on block reassignments as a viable option.

And the reason is that this is a requirement for a legacy service that doesn’t have the modern – any requirement for modern hooks in it, no requirements for REST, no requirements for machine parsability or readability.

ARIN has expended very large amounts of money to provide a resilient Whois service that meets the level of availability that meets members’ expectations.

We should set the long-term course towards facilitating migration from RWhois into whatever we want to call SWIP today, however we get the data in there, and figure out how to incent organizations that are currently running RWhois to move in that direction.

John Sweeting: I’m going to let John respond to that, because he did recently run a consultation on this exact topic. So, John.

John Curran: Why don’t you rephrase that a little clearer? Say it again.

Rob Seastrom: RWhois is dead.

John Curran: No, the question is we think that it’s not being used. But you can see from the stats – but you have not told us it’s dead. Okay. We’re happy to stop doing it if you ask us to discontinue it. We’re happy to change the policy. But staff shouldn’t be making that arbitrarily.

Rob Seastrom: It’s unclear to me whether this is sufficiently numbers related that the Public Policy process is appropriate for it. Will it immediately get rejected as out of scope if somebody writes policy for this?

John Curran: Right, different point. I need to have consensus at a meeting like this if we’re going to discontinue it. So all someone has to do is stand at an open microphone and say: At the end of the day, I think ARIN should discontinue supporting RWhois. And that will be something that we will use to build a consensus around.

We can’t do it without you folks asking us – there’s no clear way to remove a service. It’s a very dangerous thing to do without having everyone have a chance to object.

Rob Seastrom: Understood. I’m aware this is a multiyear thing, and I’ll see you at the mic at Open Mic.

John Sweeting: Also, R.S., I’d like to point out, on the consultation, there were a few people that were dead-set against retiring RWhois.

John Curran: Right.

John Sweeting: So it really is – I think what John is saying and I’m saying, we really need the community to get together and decide on what they want to do with RWhois and give us a direction to go, and we will go in that direction.

Rob Seastrom: Understood. Thank you.

John Sweeting: Thank you. Owen.

Owen DeLong: Owen DeLong, your company name here. There was quite a debate, as I recall, in the AC when we changed 2 to 3 and 4.4. And I remember us deliberately choosing not to modify 6 because, well, we felt that it wasn’t really an exchange point if it didn’t have at least three people, it was a P&I if it only had two.

We also felt that that was more important in a situation where addresses are scarce and that perhaps more relaxed standards for v6 would somehow encourage exchange points to consider implementing v6, at least initially, if not contemplating a v6-only exchange point if they really felt the need to.

So I personally think that that is as intended and that it’s fine just the way that it is. We could look at modifying Section 6 to be 3 if we really cared. But I don’t consider there to be a scarcity of v6 resources for critical infrastructure that we need to contemplate such a thing to cover where v4 is a little bit different.

In terms of RWhois, changing topics now, the proposal would I think pretty clearly be in scope since the requirement for RWhois is in Section 3 of the NRPM, and the PDP scope covers modifications to the NRPM. So I can’t imagine it being rejected as out of scope to address that in the NRPM. Thank you.

John Sweeting: Thank you, Owen. Lousewies.

Lousewies van der Laan: Hi. Lousewies van der Laan. I’m on the ICANN Board, and I’m still following with fascination all the things that are happening around IPv4.

So I was just wondering, you hand out this precious resource for free, but there are people who are actually selling this as well. Is there any kind of punishment that if you get something for free and you sell it on, that you, I don’t know, get kicked off the waiting list? Or there is something like that? Do you blacklist people? How does that work?

John Sweeting: If you receive something through a transfer, you’re off the waiting list until you come back in and apply and get approved for it, taking into consideration the usage for the space that you had on the transfer.

There’s also we have waiting times built in of once you receive a transfer, you have to go 12 months before you can transfer it out.

So it’s not where you – that you can go out and get a whole bunch of space, transfer it in to you, only to transfer it out a week later to make a profit off of it or whatever. You have to wait that 12-month waiting period.

That’s what the community put together into the policy. Whether that’s a good thing or not, that might be something that the community would want to look at. Because as we’ve seen, maybe that 12 months was looking at a short transfer market timeline, but it looks like it might be a little bit longer. So but there are policies that do address it.

Lousewies van der Laan: Do you track it? Do you track what happens to them –

John Sweeting: Absolutely track it.

Lousewies van der Laan: – making money on it? You know who these guys are?

John Sweeting: Absolutely. We know exactly – when somebody comes in and requests space or they request a transfer, we look – we have their full records. We can look at every ticket they’ve opened up since ARIN Online has become a ticketing system.

John Curran: For integrity of the industry database, we are required to keep all the records for perpetuity, effectively, so we can establish the pedigree of our resource block.

John Sweeting: And I can say we have disapproved transfers based on the fact that the time, waiting time had not been adhered to.

John Curran: Any other questions for John?

Thank you, John.

(Applause.)

John Curran: What a wonderful thing. We find ourselves ahead of schedule at this point. I’d like to ask Susan Hamlin to come up and talk about how to communicate with ARIN.

Communication Channels

Susan Hamlin: Good morning, everyone. I like to take an opportunity once a year to check in with you all and find out from the community how we are doing communicating to you.

So I’m going to spend a minute – good? We’re doing well? Alright. One vote of confidence. Going to spend a minute talking about the information we send out to you, what’s available on demand to you, and then I have a few questions to ask you at the end.

So for organizations who have a contract with ARIN, you’re doing business with us, I have a couple of slides that are a list of the infrequent communications we send out to you.

For instance, many of you receive an annual email about validating your Points of Contact. For organizations who are members, you receive quite a few emails during the election period to notify you the call for nominations, to notify you when elections open, to ask you to please update your voting contacts, et cetera.

Twice a year, every member organization receives an invitation to the Public Policy and Members Meeting. That’s something we’re required to do by the Virginia Nonstock Corporation Act. And then throughout the year we send targeted emails when we’re bringing an outreach event to your area.

We will send emails to direct allocation, direct assignment organizations in the area, alerting you to these events, because many of you are not subscribed to the ARIN Announce mailing list, or the website is where you would otherwise find out about these events.

And then annually those of you with a contract receive invoices and sometimes reminders. And then all of our mailing lists you’re subscribed to, mailman at the beginning of the year will send you a reminder.

So in addition to that type of correspondence, we have quite a few mailing lists. I’m not going to go through them here, but they’re listed. All of our mailing lists, except ARIN Discuss, are open to anyone in the community. So at your interest, you subscribe to these lists.

And then you hear from us in other ways. A lot of you all correspond with us through ARIN Online, our customer portal. You’re opening tickets, you’re requesting resources, you have general questions about ARIN. We have an Ask ARIN message center in there. And you receive notices on your dashboard within ARIN Online.

And then we have a registration and the billing services help desk. A lot of you interact with staff, ask questions, email or on the phone to both of these groups.

And then if you’re looking for information about ARIN, we have lots of places for you to come. Obviously www.ARIN.net is our main website, corporate information, details about meetings, about our services, our technical services and then our TeamARIN website is focused more on outreach.

We stood it up years ago when we started our IPv6 campaign. It’s also the home to our blog. So hopefully lots of you tune in there.

And then we have educational information on our YouTube channel, how-to videos, things about the Policy Development Process about ARIN. And we stood up an IPv6 wiki many years ago, and many of you interact with us there.

Social media. If you follow us on Twitter, LinkedIn, on Facebook, you know we’re very active. And these are just some recent stats about our followers and how much we do put out over these channels. So, for instance, 640 tweets over the last six months.

We take our outreach events around the service region – Canada, US, throughout the Caribbean. Many of you have participated or attended a one-day ARIN on the Road event. And we’ve also expanded our outreach in the Caribbean. You’ll hear more about that from Bevil, that’s another way you interact or hear from ARIN.

And then we continue to look for speaking opportunities, and we still do some exhibiting, IPv6 primarily, POC validation. These are a list of some of the places we’ve been recently or are going to soon after.

And if there are places, groups that you all participate in, meetings you go to regionally that you think it would be good to have an ARIN presence, I would like to know about that. Send a note to me or info@arin.net.

But back to the question of how are we doing. So I have a few questions here, and I would welcome your input. We have a few minutes maybe if you want to come to the mic now or you can reach out to me or any of the CMSD team that’s here or send an email to members.

So we are obviously reaching those of you in the room and probably most of you who are registered and participating remotely, but we’d like to know who we are not reaching that you feel we should be reaching.

This goes to Sean’s question: We want to make sure everyone knows about the open Policy Development Process. We want as many people who may be touched by it to be able to engage in it. And also of all the information we send you or have available on the website or various mediums, what are we not providing you that you would like to have or would like to know, and then what’s the best way to connect with you?

Are you finding information useful that we post on the website, on ARIN Announce? Are there other platforms that we haven’t touched that you think would be helpful in receiving information from ARIN?

So I open the floor, if that’s alright, John, if anybody has any input now.

John Curran: Andrew.

Andrew Dul: Andrew Dul, CrowdStrike. Last night we were talking about the ARIN on the Road events, a couple of us around the table. And I think a number of us kind of thought perhaps that maybe that program has maybe run its course and needs some retooling in terms of where it goes, maybe the type of content that’s shared.

I wanted to publicly throw that out here, and I don’t really know what the answer is at this point other than to say perhaps it needs some retooling and refocusing.

John Curran: Could you explain when you say it needs some refocus or it’s run its course? We’re having great reviews back there, people who have gotten involved with ARIN entirely because of ARIN on the Road. Refreshed their updated contact information and they’re now involved.

I’m trying to figure out what – it’s not that old a program, and you want to kill it off. I’m trying to figure out what do you think is amiss about it.

Andrew Dul: So, I’m not suggesting killing it. What we talked about last night is that my understanding is that there have been a number of events, specifically in Canada, that were all centered in the Ontario area, and getting out of that area is hard.

And going to other outlying areas where perhaps there are fewer members and the number of people that it takes to do that is perhaps not as effective. For example, you take five people, three staff and two volunteers, to do this kind of an event. Perhaps a smaller type of event might be more appropriate, or not.

John Curran: We could look at a smaller one, but there’s no problem moving out to more – less urban areas and more remote areas. We’re doing that with the US –

Andrew Dul: I think the same thing could be said of the US events in terms of are they actually – is that the most effective way for us to reach out to people who haven’t traditionally been engaged with ARIN, and is it producing long-term results as opposed to we got someone’s contact information updated once.

John Curran: Right. The question that comes up is: What’s the purpose? So we do have a way of getting out to some of these people other ways through other associations.

We’re actually working a little more now trying to get – instead of trying to get 40 people in a room just to talk about ARIN, if you’ve got 120 people talking about IT issues in a city, ARIN can get one or two people there and get the 10 who haven’t heard about ARIN to pay attention.

So we are doing a little more with, for example, doing things with wireless ISPs and fiber ISPs. But there has to be some gathering or association that we can leverage to speak at their event.

Andrew Dul: Yeah, the other one that came to mind as you were speaking is I know a number of other RIRs have a process that they like to have a personal meeting where maybe a person may be on the phone or in person with each of their members in a two-year period. I think they call it “Registry Check” in one region.

John Curran: To call up existing registrants?

Andrew Dul: Call up existing members, and “is your information up to date?” Go through a checklist of five or six questions to help you understand what the members are and what they need from ARIN now; rather than in a larger room, a more one-on-one approach.

I mean, I don’t know what the member count is today. I think it’s around 4,000 or something.

John Curran: 5,700.

Andrew Dul: It’s not something you can do in one swath, but if you took it as a multiyear process to reach out to every member in some way and have a personal interaction with them, especially ones that aren’t coming to ARIN on a routine basis for regular services.

John Curran: We currently do that with the members. We don’t do it with our customers. We have another 10,000 customers who are end users, but the members we actually reach every year because we call them up and say: It’s election time.

Andrew Dul: I think more than just voting. It’s, you know, is your contact – all of your contact information up to date? Are you aware these are all your records?

John Curran: Got it. So you’re thinking general health check overall.

Andrew Dul: Yeah.

John Curran: Understood.

Andrew Dul: Seems to have been successful in other regions. Maybe it’s something we should learn from our colleagues.

Kevin Blumberg: Kevin Blumberg, The Wire. I think, John, because I was part of that discussion last night, a simpler way of saying it is whenever a program is done for multiple, multiple years, it’s definitely worth looking at ways of improving. And if the rate of return, the number of people, the smaller the towns, et cetera, maybe a smaller program or less volunteer involvement, there’s lots of different ways. Not canceling it but just dealing with the fact that it is now going to smaller towns and bigger cities.

John Curran: We have thought a little bit about that already because it has been so successful, we’ve expanded it, and by definition it means we’re going to smaller towns. There’s ways of tweaking the content so that it requires less people to present the same amount of material.

You don’t bring presentations 30 minutes for one person. You bring presentations that are more general that eight members of the staff can cover.

And so we have done a little bit of that. But you’re right, we can do more. We can do more – look at how to get further out there with ARIN on the Road.

Kevin Blumberg: Or do less with more.

John Curran: Do less with more.

Kevin Blumberg: The reason I wanted to come up here was not actually about that. It was about the question about reaching out via email.

And I would like to thank ARIN staff for being more restrained over the last two years since I last brought up the fact that I was getting inundated. I appreciate that.

As a second improvement to that, I would love to see a digest or basically a leave-me-alone button. I would like to see monthly updates from ARIN, a one-time digested monthly, and then I really don’t need to know operationally when things are going on or if the office is closed or if this or that is going on, even less.

I would like to be able to select, because there are a couple thousand companies that reach out to me or want to reach out to me and all feel that they’re the important company to reach out to me.

And my view is any company that is sending me more than 12 emails a year without me asking or me caring is getting off – I’m unsubscribing from them.

So I’m very involved in ARIN. I do want to see them. At the same time I look and go: But I don’t want to see it from anybody else if I was not as engaged.

John Curran: Okay, but you don’t want a digest, because getting a message monthly that says we were down, the office is closed doesn’t help when you get it at the end of the month.

Kevin Blumberg: In terms of notification of that. I mean, pooling up the really important updates – we’ve now opened this, we’re now doing that – as a newsletter once a month instead of as six different emails. And I think you’ve done a very good job going there, towards that, but I would like to see more of that.

Susan Hamlin: Just to follow up, we began ARIN Bits as a quarterly update that’s emailed. It’s part of ARIN Announce, and it’s on the blog. Are you seeing that?

Kevin Blumberg: I have no way of turning off the other things and only getting ARIN Bits. That’s what I’m talking about, a selection in ARIN Online where I can say: I would like this, I would like that; I don’t need that, I don’t need that.

John Curran: Okay, so the question that comes up is if you get ARIN Bits, and you want to be able to select off, say, ARIN Announce, we have to make sure we have 100 percent coverage in ARIN Bits of what was in Announce so you don’t miss anything. Not operational messages –

Kevin Blumberg: If I’m turning off directly things like ARIN Announce, I don’t expect to have 100 percent in ARIN Bits; that’s for staff to do. You’re moderating, you’re calling the shots. I’m saying that allow me to select the 12 areas of interest that I might have.

John Curran: Got it.

Kevin Blumberg: On or off.

Susan Hamlin: Could I ask one follow-up? Currently ARIN Bits is distributed to people subscribed to ARIN Announce. And it’s available on the blog. So would you want a subscription just to ARIN Bits if that was your choice?

Kevin Blumberg: That might be one of the choices. Like I said, checkboxes of the things I’d like.

Paul Andersen: I was going to make a suggestion, maybe echoing that, perhaps there just needs to be a stream for those that infrequently use ARIN services, just want to know the highlights from time to time, and those that are concerned when you have operational issues because they’re constantly dealing and need to know phone systems or power outages. I’ve heard that commonly from members.

John Curran: I think we should brainstorm a bit on the categories of communication and how to select them and figure out how to get ARIN Bits in there somehow as well.

Kevin Blumberg: Thank you.

Owen DeLong: Owen DeLong, your company name here. I personally think ARIN’s been doing a great job communicating.

I wasn’t part of last night’s discussion of ARIN on the Road, but I have some experience with ARIN on the Road meetings. And I’ve seen them with varying levels of attendance and corresponding different levels of success.

Interestingly, one of the least-attended ARIN on the Road meetings I’ve been to was one in the second largest city in the most populated state of the union, probably the most populated state in the ARIN region.

So, it’s a mixed bag and you never know what you’re going to get sometimes. There were a lot more people registered for that event than attended it. But even the registration was kind of oddly small for the location, which surprised me because prior events in that same city had been pretty well-attended.

But overall I actually think it’s an excellent program. I think it does get very good results. We get a number of fellowship applicants from those events. We get a number of people who do become actively engaged in the ARIN process from those events.

And it really is the only opportunity we get to get out and have face time with people in some of the cities that are less likely to have ARIN meetings.

So in that sense, I think it’s a good program, and I think we should definitely not kill it or gut it for parts or whatever proposal may come by. I think we should keep it largely intact. Thank you.

John Curran: Got it. Thank you. Any other feedback for Susan? This has been very helpful.

Thank you, Susan.

(Applause.)

John Curran: Okay. That got our juices flowing. We have now moving into our policy block. Our first policy of the morning is Draft Policy ARIN-2018. Whose very stylish glasses are these? Left at the podium.

Susan Hamlin: Those are mine.

John Curran: Thank you, Susan. Much better on you. Far less stylish on me.

Okay. Draft Policy 2018-1: Allow Inter-regional ASN Transfers. The shepherds, Alison Wood and Chris Tacit.

Alison, come on up.

Draft Policy ARIN-2018-1: Allow Inter-Regional ASN Transfers

Alison Wood: Good morning. Again, I’m Alison Wood. I’m on the Advisory Council, and this is Draft Policy 2018-1. I’m not going to read all the slides, but I am going to read the problem statement.

So 2018-1 deals with inter-RIR transfers of ASNs, and there are circumstances for the necessity of RIR transfers of ASNs with RIRs within an equivalent transfer policy.

These needs include regional RIRs that are no longer issuing 16-bit ASNs, leading to the need to purchase on the transfer market if an organization requires one, customers that transfer their IP address space to a reciprocal RIR without the ability to transfer their ASN, and the technical limitations on 32-bit ASNs.

Great. What we’d like to do is change the current text to include transfers of ASNs with the text that says that we can transfer IPv4 Number Resources.

So points of discussion. I have five points of discussion, and I’m sure there will be more at the microphone. So we’ll start with a real-world possibility.

So a company that relocates their headquarters to Europe, in the RIPE region, transferring all of their IP address space. Today, this company is required to maintain an ARIN account to house their one or however many ASNs that they have.

They don’t want to change their ASN, and they don’t want to remain an ARIN customer. But today they don’t have the option because you cannot transfer your ASN from one RIR to – or from the ARIN region to another RIR.

Alright. So the technical issues. So we have 2-byte ASNs and we have 4-byte ASNs. And RFC 1997 came out and allowed BGP communities to shape traffic or to engineer traffic.

RFC 1997 only supports 2-byte ASNs. And as the free pool of 2-byte ASNs begin to shrink, then the community decided that they needed to come up with new solutions. So we had 4-byte ASNs to utilize the BGP community attributes.

February 2017, we had RFC 8092, and that incorporated large BGP communities and that became their protocol standard for defining 4-byte ASNs.

So we have working code that exists for some equipment and software. It’s worked with 2-byte ASNs universally not always with 4-byte ASNs. So this proposal addresses the problem by allowing registrants of an unused or unwanted 2-byte ASN to transfer the registration to a network operator who needs one all within the existing and community agreed-upon framework of inter-RIR transfers, meaning that if it’s reciprocal between the ARIN region and either RIPE or APNIC, the other two regions that allow for ASN transfers.

So one question that came up is would the community prefer to limit this policy to incorporate only 2-byte ASNs?

So today, the way 2-byte ASNs were assigned is in a noncontiguous block. So 2-byte ASNs were kind of assigned all over the board. 4-byte ASNs were assigned by IANA in blocks to the different RIRs.

So hopefully that’s something that you guys could, the community could, bring forward when you come to the mics and talk about the difference that you feel between 2-byte and 4-byte ASN transfers, if any.

RPKI implications. So this policy has come up twice before in the ARIN region, and one of the reasons why it did not pass was because of RPKI implications, issues with RPKI. Those issues do not exist today. So the RPKI trust anchor contains all AS numbers, making RPKI a nonissue with Inter-RIR ASN transfers.

And the last sentence here, though, is somewhat important: However, inter-RIR transfers of AS numbers would greatly complicate any future implementation of an RPKI Global Trust Anchor if that were to ever occur.

ARIN implications. So, good news here, during the previous assessment, transfers were not fully automated within ARIN’s registry system. But that’s changed. And ARIN’s systems now conduct transfers via ARIN Online, which you guys are all familiar with. And the automated processes will need to be modified, but with an easy effort of one to two months’ work by ARIN’s staff.

Alright. So APNIC and RIPE NCC have approved inter-RIR transfers. No transfers have taken place to this point. And just to go over the different policies with APNIC, APNIC will recognize inter-RIR IPv4 address and ASN transfers only when the counterpart RIR has an inter-RIR transfer policy that permits the transfer of those resources. So reciprocal policies. So and right now it’s only APNIC.

And RIPE policy again says that IPv4 addresses and AS numbers can be transferred to and from the APNIC service region.

Alright. IANA. The RIRs and IANA are discussing how the top-level ASN registry should be updated and cleaned up so the future RIR ASN transfers are referred to the appropriate RIR and that additional redirects are done as needed.

Alright. So again to state that 2-byte ASNs then were just assigned and 4-byte ASNs were sent in contiguous blocks to the different RIRs. The NRO EC is working with IANA and the public technical identifiers to ensure that a single ASN has moved from one RIR’s administration to another and it should not have to be reflected at the IANA level.

So what they’re saying is if the community wants this to be done, technically this is possible to do. Alright. So questions?

And my question that I would like to pose to the community is would you like to see ASNs transferred from one RIR to another, knowing that technically a lot of these problems that came up in the past have now been solved.

John Curran: And Paul will moderate that.

Paul Andersen: Thank you. Don’t run away.

The microphones are open. So for those that are new to our process, if you can hear the sound of my voice, either in this room or on remote, and you have opinions, thoughts, comments, suggestions, gripes, or even just “I think this is a good idea” or “I think this is a terrible idea,” please approach a microphone, virtually or not, and be heard.

Rear microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I support the policy. And, yes, this is kind of a tall mic; forgive the chin up.

I think there was some discussion around the actual need for Internet operators to use 16-bit ASNs versus 32-bit.

It’s not just about large communities, even though large communities are an issue. The RFC is only a year old.

There is a thankfully decreasing but still substantial number of network devices on the Internet that will never support 32-bit ASNs: Hardware that isn’t getting software updates, and equipment doesn’t leave the Internet as soon as it’s irrelevant, it’s up to the operator’s budget to find hardware upgrades and whatnot.

So as such, I support mechanisms that allow needed resources to go where they need to go.

Paul Andersen: Thank you for your feedback. Next speaker.

Mike Burns: Mike Burns, IPTrading. I support the policy. I’m the author, and I’d like to thank the shepherds. Did a great job. I don’t think we should restrict this to just 2-byte ASNs. I don’t really see the point in that.

There are applications for companies who do want to keep their network blocks associated with their ASNs. Since we have a regional trading group, which is AP, RIPE, and ARIN in terms of address blocks, it seems to me only logical to facilitate transfers of ASNs as well. Thanks.

Paul Andersen: Thank you.

Sean Stuart: Sean Stuart with Verisign. I fully support this for 2-byte, 4-byte ASNs and would even like to see it extend to IPv6 at some point. Figure numbers are numbers; let them go where they’re needed.

Paul Andersen: Thank you. In favor. Front microphone.

Owen DeLong: Owen DeLong, ARIN AC. I’m still opposed to the policy. It’s 2018. The problems for 2-byte ASNs have been mostly solved at this point. They’re going to be solved relatively soon, probably, by the time this policy gets implemented on a much wider basis. And I don’t see the necessity to continue to foster the 2-byte ASN limitations. It’s time to move on.

Then again, I’ve felt that way about v6 for a long time, and look at where we are now. The pain, the pain. It continues.

Paul Andersen: There’s not a change that would make you supportive, then.

Owen DeLong: There’s not a change that would make me support it. If we’re going to do it, I don’t see any reason to do it just for 2-byte AS numbers. I certainly would not support ever expanding this under any current or foreseeable circumstances to include IPv6 numbers.

The reason we originally permitted IPv4 transfers between RIRs was the preponderance of available legacy resources that were underutilized in the ARIN region, largely for export.

That is most of what the IPv4 inter-RIR transfer policy has been used for, from my understanding of the statistics, and it doesn’t seem unreasonable to me for us to have done that. But further scope creep strikes me as a step away from goodness. Thank you.

Paul Andersen: There will not be, by the way, a poll on this question as per the AC chair. So, if you want to express a view even to say in favor or against, you need not say anything more. Please approach the microphone, because I’m rapidly running out of speakers.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written. We’ve had a policy in place since 2004 allowing it in our region. It’s kind of hard to come up here and say we don’t need it elsewhere but we need it here. The policy has been used in our region. It has had validity. So I don’t see a differentiation in that regard.

I was on the side of there is a difference between 2-byte and 4-byte – 2-byte is scarce, 4-byte is not. And I reviewed and talked with a number of people. At this point I am absolutely fine with it just saying AS numbers. It’s a complexity that does not need to be there.

And more importantly, the fact that you are able to show brand-new RFCs that are trying to still address the 2-bytes issue from a technical point of view, while modern equipment deals with this problem in many cases, it does not deal with it in all. And that is assuming that a company is running modern equipment.

In many cases they’re not. And it is not being addressed. As a Board member of an Internet exchange operator, I can say that 4-byte is a consistent problem that we see. It is just a reality. And while I would love for it to be solved, I don’t see it being solved in our lifetime.

Paul Andersen: Thank you. I am going to have to close the microphones soon, not because of time constraints but we’re running out of speakers. If you wish to speak, get to a microphone or start typing before the end of our next speaker.

Front microphone.

Cathy Aronson: Cathy Aronson. I worked on this a little bit with Alison. Super fun. The thing that I found most curious about this – I support this policy, by the way. The thing I found the most curious about this is that even if it’s an M&A transfer, so say a European company buys a US company and they move the headquarters to Europe and it’s an M&A, ARIN still won’t transfer the ASN to that company even with an M&A transfer.

And I don’t see why somebody should be forced to change their ASN or maintain a registry in a region that they don’t have a business presence anymore. So I’m really extra in favor of this once I learned that. Thanks.

Paul Andersen: Thank you very much. Last call for comments. Do we have anything from remote participation? No. Nobody’s approaching a mic.

If I don’t see someone approaching a microphone in the next three seconds we will close the microphones. Three, two, one.

Thank you. Microphones are closed. This ends this discussion. Thank you to Alison for the presentation.

(Applause.)

Paul Andersen: I will now slowly move to the –

John Curran: Very good. Excellent discussion. We’re going to have Leslie Nobile come up and give an update on POC validation statistics.

POC Validation Statistics

Leslie Nobile: Good morning, everyone. Part of my role is to look at data accuracy and data quality in ARIN’s database and look at ways to improve it. So I periodically track POC validation stats. And I also work on ways to improve them.

So I did this presentation one year ago in New Orleans. And we have some difference in the data. I’ll talk about that a little bit. The policy itself is NRPM 3.6, the annual Whois POC validation, and there’s sort of three main components to it. There’s a bit extra, but I’m only going to talk about these three points.

Email is sent annually to every registered POC in ARIN’s Whois. The POC – Point of Contact, by the way, in case somebody doesn’t know what that means – the POC has 60 days to respond with an affirmative that their contact information is correct.

If ARIN staff deems a POC to be abandoned or otherwise illegitimate, the POC record shall be marked invalid.

So, I’m going to give you some stats. Lots of numbers.

Right now we have 883,414 total Points of Contact registered in ARIN’s database. 226,000-plus are validated. “Validated” means that they’ve either responded to ARIN’s annual POC validation email or that they’ve come in separately and updated their POC record within the past 12 months. Either way that will validate the record.

So 26 percent of all Points of Contact in ARIN’s database are valid or have been validated.

656,655 are nonvalidated. That means 74 percent of all POCs in ARIN’s database are nonvalid, have not been validated or updated.

So I’ve broken the numbers down into direct and indirect POC validation stats. Direct POCs are those that are associated with organizations that have received resources directly from ARIN or from one of ARIN’s predecessor registries.

Indirect POCs are associated with organizations that have received reassignments from upstream ISPs. So total direct POCs are 51,868. 27,718 are validated, and 24,150 are nonvalidated. Of the total indirect POCs, we’ve got 831,570. So the majority of Points of Contact in ARIN’s database are reassignments put in by upstream ISPs.

202,203 are validated, and 629,000 are nonvalidated. So I have another kind of way of looking at this I think in another slide. Perhaps not. Let’s see. Yep, I do. Sorry. Got carried away with the “Miami Vice” colors.

So direct and indirect POC validation stats. This is another way of looking at the previous slide. We have 51,858 direct POCs. 47 percent of them are nonvalidated, and 53 percent of them are validated. That’s really almost 50/50 for direct POCs, people that interact directly with ARIN. It’s not a great stat.

Looking at the indirects, of the 831,000, 76 percent of them are nonvalidated, and 24 percent of them are validated. So this is another way of looking at POC validation. We actually pulled the ARIN-issued networks. We look at how many ARIN-issued networks have validated POCs and how many legacy networks have validated POCs.

We have almost 30,000 ARIN-issued networks registered in the database. There are currently – only eight percent of them that have no valid POC at all associated with the network, and 92 percent of them have at least one validated POC associated.

When you look at the legacy networks, there’s 24,758. Fifty-four percent of them have no valid POC, and 46 percent of them have at least one valid POC. So it does show that legacy networks are alive and awake and paying some attention. They are validating somewhat.

So interesting comparative data. I told you I did this a year ago, and a year ago there were 6,000 – a year ago there were 6,000 more legacy networks registered in the database. Now there’s 6,000 fewer.

When we dug into that to look at why, it appears that half of them became ARIN-issued networks as a result of an 8.3 transfer. Those are the specified market-based transfers within the ARIN region. Then the other half went to other RIRs as the result of inter-RIR transfers. They moved out of the ARIN region. So 6,000 legacy networks changed status essentially.

Another point that I don’t have on here – and actually I’m going to go back real quick because I should have said this in the beginning. Overall, 26 percent of our POCs are not validating. That is as of today. I mean are validated, I’m sorry.

One year ago, 30 percent of all POCs overall were validated. So the number has actually dropped down. Even though we’re working on ways to improve POC validation and making communications better, et cetera, et cetera, less people are validating their POCs.

So some conclusions on this: Direct POCs are validating more often than indirect POCs, but there’s definitely room for improvement. We saw that in the slides. ARIN-issued networks are far more likely than legacy networks to have at least one validated POC. You saw that in the slides.

The annual POC validation policy may not be working as intended if only 26 percent of all registered POCs are actually validating their POC data, and that number has gone down in the past year.

And it appears that the transfer policies are clearly working as intended because unused IPv4 address space is being reissued to organizations in need with half staying in the ARIN region and half going to other organizations in other regions.

And that is all that I have. Are there any questions on that?

John Curran: Any questions for Leslie?

Andrew Dul: Andrew Dul. I have a question about legacy, the legacy POCs. How many of the 50 percent which are nonvalidated are abandoned blocks?

John Curran: What do you mean by “abandoned”?

Andrew Dul: Not routed. Nobody’s ever seen them, things like that.

John Curran: We don’t have an accurate assessment of abandoned blocks to compare that with. I mean, someone can go generate one. But we have not done so. There’s actually another question, which is how many of the POCs have no resources at all associated with them, they’re just a POC.

Andrew Dul: I’m not – is that included in – that was a statistic I remember seeing last year –

John Curran: You’re going to see that in about an hour.

Leslie Nobile: I have another one.

Andrew Dul: Are you trying to set yourself up for an easy question later?

John Curran: Because those are going away.

Andrew Dul: I think it would be interesting to know, for some definition of abandoned, of that 54 percent basically they’re just really old.

John Curran: Your definition is not visible on the public network?

Andrew Dul: That would be one definition that it would be easily able to be recognized.

John Curran: Do you have any stats on networks being used and private networks that don’t tell you they’re being used?

Andrew Dul: I do not, but –

John Curran: There may be someone with those stats, but they’re creative people, if there are.

Okay. Yes, Owen.

Owen DeLong: Owen DeLong, your company name here. To Andrew’s point, it would be useful to know what percentage of the networks that are not validating their POCs are also not visible on the Internet. And it would be interesting to know if there is any way to validate that the organization in question even still exists and things like that.

I realize that’s quite a lot of work, perhaps, and that maybe there’s no there there, but if we can identify that the organization doesn’t exist and the network is not announced and, et cetera, et cetera, then perhaps we need – I realize policy language to support this, but perhaps it’s time to consider publishing in the paper of record or something like that for some period of time that if said organization does not get in contact with ARIN and update their information, we are going to presume the resources are abandoned and therefore recycle them.

John Curran: So I have good news for you. The good news is that there’s teams of people out there looking at those networks right now. As we sit here, there are people doing research on those networks.

Now, they’re actually looking for ones that aren’t announced and do have organizations as opposed to not announced with defunct organizations.

Actually, the defunct organizations work as long as there’s a legal successor of some type. Because those networks have value. Because of the transfer market now, every one of those networks can be put into a market.

And there are people who actually actively are doing this, which is why the number of networks is dropping. It dropped. As you can see, we had 6,000 networks disappear in the course of two meetings.

So there is a pressure mechanism that works now. It is true that that will only go so far and we may need to look at –

Owen DeLong: A clarification on that. All 6,000 of those networks didn’t have valid POCs?

John Curran: No, those are 6,000 total. We don’t know how many did have POCs or didn’t. But there are organizations who are actively trying to find – some of the brokers are actively trying to find the underlying organization. They’re not working off the POC list; they’re literally looking at the unannounced networks.

So there is a back pressure that applies now. We are – ARIN is happy to explore whatever you want, but the work involved is very high if we take that on as opposed to leaving it in the market. Your call.

Owen DeLong: Understood. Thank you.

John Curran: Back microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I think that the legacy scrap reclaimers are doing an excellent job of finding all those little tidbits out there, and I really don’t see a value in spending money and resources to find stuff that people are actively going out and doing, especially when we have a fee discussion later on.

My bigger concern is the 50 percent of – Leslie, if you can go back – the direct POCs. That’s the one that really worries me. Indirect is the reassignments downstream. This is a big issue. We’ve got policy to deal with that.

But I’m more concerned with the direct POCs, the ones that ARIN has a relationship, should have a relationship with. That number is, as a user, pitiful, and that would be where the attention really needs to be spent. Thank you.

John Curran: Okay. Thank you.

Okay, any other questions for Leslie?

Leslie Nobile: Thank you.

John Curran: Thank you.

(Applause.)

John Curran: Okay. I see people getting antsy because they know out there is refreshments and a break. I guess I’ll let you go to break.

We are going to break. It’s a 30-minute break. We’ll resume promptly at 11:00, where we’ll pick up on the Recommended Draft Policy 2017-8. So we’re broken for 30 minutes.

I guess we’re in recess for 30 minutes. Try not to be broken.

(Break from 10:31 AM to 11:03 AM)

Recommended Draft Policy ARIN-2017-8: Amend Community Networks

John Curran: If people will come in and be seated, we’ll get started. Welcome back. Okay. We resume the ARIN meeting. We’re now handling Public Policy matters, and first up is Recommended Draft Policy 2017-8, amend the definition for community networks.

I’ll give the staff introduction, and after that we’ll have David Farmer come up and give the AC presentation.

So the history. This Recommended Draft Policy was submitted originally as ARIN Policy Proposal 243 in August of 2017. It was advanced to Draft Policy in August 2017. Meaning it had a clear problem statement at that point. The AC knew what it was that was being proposed.

In February of 2018, it was advanced to Recommended Draft Policy. It is now in a state where the AC can recommend it to the Board of Trustees after it’s been through a Public Policy Meeting.

So it is possible that this is the last time you would see this at a meeting. That happened in February of 2018. It’s been presented at ARIN 40. Shepherds are Dave Farmer and Andrew Dul.

The staff and legal review. This Draft Policy provides a new definition for community networks. It allows them to receive an allocation size of /40 of v6 resource, but limits the holder to only performing reassignments and does not allow reallocations.

The new definition is clear and easily understood, the proposed policy. It notes that community – the staff notes that community networks may be approved for an allocation size of /40. They may choose to qualify under Section 6.5.2 if they desire and then be considered a regular LIR. This is clear as well. The policy is implementable.

There is a statement that says community networks receiving a /40 under the section only make reassignments, and it further prevents them from receiving an allocation under this policy for those receiving an allocation from making reallocations. That is also clear. The policy can be implemented as written.

So with that, there’s no material legal issues from a legal review.

Resource impact, it’s relatively small. We can implement it within three months of ratification by the Board of Trustees. Updating guidelines and internal procedures, we do staff training. There’s some engineering work required to make sure it’s implemented correctly.

Okay. The Advisory Council presentation. Come on up, Dave Farmer. It’s so good to see you in Miami. For those who don’t know, Dave had a travel adventure getting here, or two.

David Farmer: Just to add to that, you know, even in Minneapolis, 16 inches of snow in the middle of April is a lot.

Okay. So this is the problem statement. John reviewed the history. Unfortunately, this is a lot more history than even that.

This goes back a couple of years. We’ve had a couple of whacks at this. I think we’ve got it this time. There was also some discussion at ARIN 40.

This policy started out as just changing the definition, but it became clear at ARIN 40 that the community wanted more than just that. We needed to have community networks get allocations, not assignments, and there was a few other issues discussed.

Okay. So what’s changing? The definition is changing. Community networks are now basically essentially a special subclass of LIR. They receive a /40. This qualifies them for the triple-X small ISP fee category of $250. Although that’s really not a policy issue, but it’s an implication of this policy.

For larger or subsequent allocations, community networks need to become a regular LIR and follow those policies. And then community networks can only make – the community will make reassignments, just like any other LIR. They won’t make reallocations.

And that’s primarily because a /40 is already a very tiny v4 allocation in the scheme of things, and slicing and dicing that into smaller ones does not make a lot of sense to some people.

If you’re a community network and you need to make reallocations, hey, there’s an answer: Become a regular LIR, get a bigger allocation, and then you can slice and dice it.

Policy text. This is the new definition. I’m not going to read it to you. I mostly have these here in case we need to discuss them.

The highlighted text in these policy text ones, or the bolded text, is where the text is actually changing. If it’s in unbolded text, this is actually language that’s already in the NRPM.

And then this whole section I just left in for clarity, but this subsection is not changing at all. This is where we talk about allocation size and make it explicit that they can be become a regular LIR if they need to, need some other size or need subsequent allocations.

This is where we talk about the reassignments. We’ve already been through all this. Since ARIN 40, the new text seems to address everybody’s concerns. Nobody has – since this text has come out, nobody’s expressed any concerns at all.

There was some discussion about the /40 and the allocation – the reallocations and all of that, and basically there seems to be – people seem to be following in this consensus.

As John pointed out, there’s no real issues in the staff or legal assessment. I think we’re ready for the final discussion on this.

Paul Andersen: So after the sugar break, I encourage if you have comments on this Recommended Draft Policy to approach the microphone.

This policy is in a slightly different stage than the Draft Policy, and I normally can find it in two seconds, the – oh, yes. I encourage you at this point to look for those new – the PDP flow chart on page 31 of your guide. This one is – policy is deeper in the process than the last one. So we really encourage any feedback, because it’s coming close to becoming final policy.

But nothing I’ve said has encouraged anybody to come up and speak. Hopefully somebody in remoteland is typing.

Please approach a microphone. Far microphone.

Kathleen Hunter: Kathleen Hunter, Comcast, speaking for myself, as usual. I think you guys did a good job on this policy. I approve of it as written. I think a lot of thought went into all of the important things that everybody had raised.

I think that the /40 for now I think would be good to go forward. I think size could always be discussed later. But I think the way it’s written is probably the way it should go.

Paul Andersen: Thank you. Far back microphone. There is no microphone farther than you.

Kevin Blumberg: Kevin Blumberg, The Wire. I authored the first proposal, I authored the second proposal, and you guys got it right on the third proposal. Thank you.

I support the proposal as written. It’s done. Let us see it go off on its merry way, and hopefully there will be community networks that can use this policy. The other one was unusable. May this one be usable, and may I never see it again.

The one thing, David, earlier in your slides you have if a community network does use it, you said “should,” and I wanted to clarify the policy text says “must” become a regular LIR. And that to me was the correct scenario.

David Farmer: I was speaking loosely.

Paul Andersen: Others that wish to speak on this proposal? Going once, twice? Anything in remote participation? Negative. Well, have to get some more sugar for the next break. With that, we’ll close the microphones at this point.

We’ll thank David for the presentation.

(Applause.)

Paul Andersen: But we will now have audience participation time, because this is a Recommended Draft Policy, and this is our first poll. I will explain how it works.

Anybody, again, who can hear the sound of my voice – if you’re in the room, if you’re in remote – you may signify now, if you wish, whether you are in favor or against this proposal as the text has been presented.

And the results of this poll will be provided to the Advisory Council who will deliberate later this week to decide how to – whether to advance or not the policy.

So how it’s going to work: I will first ask for those in favor and then those against to raise their hands nice and high. We have actual counters in the room who will count. I’ll ask you to keep it up until they are done counting.

So please just get ready to stretch for a second. If you’re remote, please follow the instructions that are being provided to you in chat.

So with that, on the matter of ARIN 2017-8: Amend Community Networks, would all those in favor of the policy as written please raise your hand nice and high. One hand only. No hanging chads, please. Keep it nice and high. Our expert counters are quickly and heavily in the process.

And you may lower. Thank you. And would those opposed to the policy as written please raise your hand nice and high. Good.

Now we will just take a brief pause to await the tabulation as we anticipate tonight’s exciting social and the lovely heat that we’re not getting so much in my neck of the woods, Toronto, where it’s freezing rain.

I think I see the envelope on its way down. Thank you very much, Michael.

On the item of ARIN 2017-8: Amend Community Networks, participates in the room, 93; remote, nine. The result of the combined is 29 in favor, goose egg against.

This information will be provided to the AC for their consideration. Thank you.

(Applause.)

Data Privacy Update

John Curran: Moving right ahead, next up is ARIN’s Data Privacy Update. And the speaker is me. Oh, wow. Cool.

So there’s a lot of attention being put on personal data privacy globally, and it’s worthwhile activity. We’ve seen discussions taking place in many countries, but probably the most significant example would be the EU General Data Protection Regulation taking effect next month.

It’s certainly launched quite a bit of activity, particularly because of the sort of pervasive, wide-open nature of the Internet and the very clear guidance out of GDPR regarding the handling of personal data and the rights of EU residents.

So with that happening, and with the fact that we hadn’t really looked at our privacy policy in a while, we just finished undertaking a pretty serious review of our data privacy practices.

And our approach to data privacy is based on our mission, what we’re here to do, the purpose that we fulfill, and the application of relevant law and regulation to that. So I have to talk a little bit about both of those.

ARIN is the Regional Internet Registry that serves the Internet Numbers Registry System for North America. There’s a system called the Internet Numbers Registry System. It’s the collective pool of v4, v6, ASN 32 and 64 address pools, and five RIRs end up administering portions of that. We handle the North America region, as folks are aware.

And that’s our principal mission. It’s very important for us to pay attention to that. That system exists for a purpose. It’s essential to Internet operations globally.

It provides unique number resources for organizations globally, in order that they can be part of the Internet or serve customers with Internet services.

It’s used for relevant contacts for troubleshooting, abuse mitigation, law enforcement. It serves a public interest in this manner. The Internet is a wonderful benefit for all of us, but we have to keep it running, and the Internet Number Registry System is a very important part of that.

We actually have dealt with personal data privacy before. The community is not unaware of that. When we did adopt policies that would put potentially personal data and expose it, for example, when we were looking down at sub delegations and sub delegations of ISPs down to the individual broadband subscriber, we adopted a residential privacy policy to make sure that those could be omitted and left out of the registry so they wouldn’t be visible.

We have interest in supporting the public use of the data, but at the same time we have to pay attention to the privacy concerns. And we’ve shown a track record of doing this.

So now we talk about GDPR. GDPR applies to processing of personal data by businesses established in the EU. We’re not established, ARIN, in the EU. As it turns out, you would have to have offices and employees, some nexus of business there. And we just don’t meet the definition.

But GDPR actually applies to a lot more companies than just ones established. It also applies to those who process personal data that offer goods and services to individuals in the EU or monitor EU individuals.

If you hold yourself out providing services to citizens of the EU or residents of the EU, you have to be prepared to be covered by GDPR because you’re actively soliciting EU residents to engage with your business. The quid pro quo is you respect the fact that those citizens have rights and they have certain laws that cover them.

It’s not our practice, really, to offer goods or solicit services from EU residents. We don’t actively do it. It is possible for someone to make use of our services. But we don’t go looking for them. We don’t advertise there.

Our service area doesn’t overlap. We don’t engage in practices there. So someone from the EU who is making use of ARIN’s services, they’re consciously seeking us out, we’re not trying – we’re not prohibiting them, obviously. I see a number of fine EU residents in the audience. But we don’t actively solicit there.

And as such, we don’t meet the definition that the GDPR requires for a business that’s actively engaging in the delivery of goods and services to EU residents. So our general scope of activities of our operational activities do not fall within the GDPR, which is convenient.

Now, it turns out, even if it doesn’t, we’d like to have better personal privacy practices. And the personal privacy practices are just responsible because people do get harmed when their personal data gets out there and they’re unaware of it.

There are people who, for very legitimate reasons, very personal reasons, don’t want to be public. You may have someone who doesn’t like you and is trying to hunt you down. You may have a reason because you have arrangements, personal arrangements that you don’t want the public to know.

And so it shouldn’t be necessary for you to become a public persona in general in order to deal with ARIN. And we look at that very seriously. While we’re not covered by GDPR, many of the principles that are in GDPR we actually support very similar principles.

So we said let’s actually put down in writing what we do support. So these are ARIN’s Personal Data Privacy Principles.

We obtain personal data only for specific lawful purposes and by consent of the individual. We’re not looking to obtain your personal data unless we’ve got a reason to obtain it and we have your consent.

We store personal data with appropriate protections for its integrity and confidentiality. We don’t treat your personal data – your personal data, your name, your phone number, your email address – we don’t treat it capriciously or lax or with less security than we treat our own personal data.

We store it for as long as necessary for the purposes for which it was obtained. This turns out to be challenging for most of ARIN’s purposes, and we’ll talk about that.

We use reasonable efforts to process requests from individuals for correction or deletion where feasible. We actually try to do this today. We’re actually trying to create business processes to make it more available, but it is challenging because of the nature of the business we’re in.

And then we’ll direct any agents or contractors to adhere to these or equivalent privacy policies. We use a lot of third-party services. Cvent for registration for the meeting, polling software, for example, for voting, election software. When we use these services, we engage with these people to make sure they have similar privacy practices.

So we put these principles down, and then we went out and looked at the ARIN privacy statement on the website and realized that no one had looked at the ARIN privacy statement on the website for almost a decade.

And so we started over and wrote a very clear privacy policy, and it’s now on the website. It’s version 3. The old one was 2.

It describes the scope of the policy. It has these principles enshrined in it. It has the information we collect and receive. It says what we collect from you and why, how we use and share that.

It talks a little bit about how we retain data. Talks about correction and deletion. Talks about website usage and tracking, because apparently a lot of people worry about that with websites, so we had to talk a little about that.

Talks about children’s privacy rights. I won’t get into that, but we don’t hold out our services for children either. And so if you know of a young child who is putting their personal data in our systems, we’d like to know about it.

So that’s what’s in the whole policy.

Let’s talk about some specifics. Personal data. Okay. So what’s personal data? If I can use an identifier and I can figure out who you are, it’s probably personal data. If I can do it without any other information. So your given name, your postal address, your phone number, fax numbers, and email addresses.

A business address is not personal information. If you’re a business of one, I’m really sorry, you’re a business before you’re a person. You held yourself out to be a business, congratulations. So I no longer consider your personal data because you have decided to hold yourself out as a business.

We collect personal data when you supply it to our websites, our systems, or otherwise interact with us. You call us up, fill out a survey, you use the ARIN help desk. That’s personal data.

We don’t try to collect it, but sometimes we have to. Meeting registration, we have to know who you are. By definition it’s your name, it’s printed on your badge, it’s personal data. So we’re going to collect personal data from you.

A lot of ARIN’s services – this is in the policy, very clear – are public. We have a Public Policy process. The nature of that Public Policy process requires a record. The record is public.

There’s a person over here doing a transcript. When you speak at the mic and you say “I’m Owen DeLong,” they record your name – okay, yeah, they record your name. And so it’s in the transcript.

When you raise your hand for a show of hands, you’re participating in a poll that’s going to affect our policy process. There are many people who want to know who might have been in that room raising their hands, so you’re part of the attendee list, which is public.

These records are saved because they affect our policies. So we maintain a public archive of all of this, and it’s necessary for the integrity of our policy process.

So you have to decide: Am I willing to be a participant in an ARIN meeting? Am I willing to know my name will be record as a participant? If I speak, I’ll be recorded as a participant. I will be in the audio, in the video, and in the transcript.

You might not want to. You can participate remotely and not register, by the way. The video is right there. You just can’t ask questions or participate in the show of hands, but you can see the audio.

But if you actually want to participate, whether it’s on site or remotely, yes, we’re going to have your information and we’re going to record it because of the integrity of our policy process.

You have traces and you have a decision to make. If you do decide to participate, though, recognize it is ARIN’s position that this is public information that we will store and that we will keep publicly.

Organizational data. This is mostly what we get. In the normal course of business, people provide us organizational data – street address, organization name, contact information, who their business is.

And they give us the names of their employees, which is personal data. We’re not trying to collect personal data. You can put “network operations center” in there. You can put “billing department.” We have a lot of people who do that.

If you put the name of an employee in there, you need to get their consent. Now, it’s possible you have their consent. You may believe that the fact that you’re paying them a paycheck means you have their consent to use their information. I don’t know.

I actually don’t even know in what countries that’s legal or not. I actually don’t care, as it turns out, either, because you’re responsible for getting the employee’s consent if you’re providing that data.

Organizations that provide personal data of their employees, their customers, their staff to ARIN are responsible for being sure they can do that and for maintaining that. That is not our job. We have a lot of things to do. That’s not one of them.

Other organizational information, things we associate with you, is considered organizational information. It’s not personal, it’s organizational. It includes the list of resources and things like that.

Now, when we publish this registry, it’s a public registry. We believe that the list of number resources in the Internet Number Registry System is something that has to be public. It’s something that is for the integrity of the system.

And so you have to realize when you go and get someone’s consent, one of your employees or customers, to put them in Whois, you have to tell them: This is a public registry for blocks of IP addresses that are assigned to organizations.

And we have made that determination, and now people have to make the determination of whether they wish to be using the Internet Number Registry System.

That’s it. It’s actually not that hard. You can go read it on the website. Happy to take questions.

Ron da Silva: Ron da Silva, ICANN Board of Directors. Thanks, John. I appreciate the update. I realize that RIRs will share best practices. I am curious if these set of principles around privacy data has been shared with RIRs, and do you have a mash-up of who has what policies and how they differ and where that sits? Thanks.

John Curran: So, interestingly enough, if you went all the way back here – do I actually have a laser pointer? This might be the first time I use it. Oh, look at that. I have a laser pointer.

If you go all the way back here to “The Internet Number Registry System is essential to Internet operations globally,” there are other RIRs that have looked at the GDPR issue who have very similar statements.

I would not say they’re the same words, because I would never ever use someone else’s words, but they’re really similar. Each RIR is looking at this.

If we get to the point where there’s harmonization across all five, then we might do something to globally state as much.

There’s a pretty important difference here, though, because recognize that we’ve never been trying to give IP address blocks out to individuals. It’s recognized that this is for network operations for purposes of organizations. Even in a small organization, we’re giving a block of numbers for them to number multiple computers or multiple customers.

So the IP Whois has from day one not been about information that’s supposed to be associated with an individual. Always been an organization, even if we have put names in it and maintained it that way.

That’s why years ago ARIN, when we were cleaning up the database, we actually formalized the organization field, which wasn’t even actually clearly called out in the IP address records.

So the short version is we have a couple of RIRs that have made this statement. We’re not yet through all the RIRs looking at their privacy practices, but certainly we’ll try to do some sort of compare and harmonization when everyone gets through their first phase.

Yes, remote.

Alicia Trotman: Jason Schiller: Do you have a defined policy to remove data from systems once the data is no longer needed?

John Curran: Good question. So for the Public Policy process, we maintain a record of the transcripts and the polls, the whole meeting event, for the history of the policy process. So the history of the NRPM.

As long as we have an NRPM, people will be able to go back and see how it was created, and that includes these meetings, the attendees. So that has to have a very long lifetime.

For purposes of the registry – and this, actually, a lot of this is in the privacy policy called out as examples. For purposes of the Internet number registry, we have a similar circumstance. Because of the integrity of the registry, we have to keep all the data that supports the assignments and reallocations and all of the changes made. We keep it for the lifetime of the registry.

This means that, yes, we have records that go back to the very beginning. And, in fact, in ARIN’s case, our records go back pre ARIN because we were the – we inherited the Internet records which were Jon Postel’s records. We have to keep those forever.

Regarding what’s public, that’s a different question. And we will work very hard to figure out information that doesn’t have to be public. You’re going to see a presentation right after me talking about that very topic.

So the answer is yes, we will look at the duration of the business purpose, and for information that we do not need, we will delete it. However, because of the integrity of the registry and policy process, the retention of many of our records is permanent, indefinite.

Yes, Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. I appreciate you updating significantly the privacy policy for ARIN the organization.

My concern is that the community and the NRPM does not necessarily have any of these aspects in it. In fact, we want this information. We want you to put your Whois information, we want the reassignment information.

And I think that we’re stale as a community in regards to the global privacy requirements today and the expectations of individuals who – even if they’re working for a corporation, those individuals.

So as a community, I’m concerned that our NRPM needs work; that we need to make a better attempt. While I understand that we can do role accounts for reassignments instead of individuals, I would suspect that the vast majority are individuals.

And I think it’s – I don’t think it’s fair to say that there has been 100 percent consent down the road, because this is being done over many years, where it just wasn’t a requirement, John. So I think that the community needs to be very, very aware of that.

My other question is how do you deal with – that’s more of a statement than a question. But as a question, how do you deal with requests for personal information? I.e., I would like to know where my personal information is within ARIN. Is that something that is doable by ARIN?

Might be a bad example, but –

John Curran: You actually gave a great example. Just think about a different question. Let’s say you don’t ask “Where’s my data in ARIN?” Let’s say you ask “Delete my data that’s in ARIN.”

That’s a very similar request, as it turns out, because it’s hard to delete something where you don’t know where it occurred. Okay. So it turns out they’re related.

We did not in our privacy principles, in their final form – we did not commit to being able to provide you a copy of all your data. It turns out that that’s something that a lot of people want.

But it turns out to be for an organization that has 15 years of records that haven’t been built that way and records prior that haven’t been built that way, if you got an assignment in 1994, I do have it in a record somewhere, but I’m not sure I have it indexed in a way that will let me find it. So I can’t commit to giving you the data necessarily.

For the information we can delete, it’s a much smaller subset. For example, early registry records internally we’re not going to delete even if you asked us to, because we can’t. We need that record in case we need to verify the chain of custody in the future.

So we looked at both, both deleting – delete all my data and find all my data. We can’t do find all our data right now. We looked at the requirements, and literally it would require reorganizing how ARIN has done its systems over the year.

So the answer is no, we cannot provide that. We will handle a request for deletion for the stuff we know on a best effort basis – I’m sorry, as a reasonable efforts basis – where is Michael? Michael should be throwing something at me – on a reasonable efforts basis.

And we will handle requests for updating. If you have an inaccuracy you’ve seen, the best we can, we’ll do it. Both of those are part of the compliance email and the policy update.

I want to go back to an earlier point you said about the NRPM. Yes, the NRPM should spell out the community’s expectations much better with regard to when you do a reassignment, what’s expected. Or when you do an allocation, what’s expected for that matter.

And if you know someone on the ARIN AC, you might get a hold of them and talk to them, and maybe they can come up with a proposal for that.

Kevin Blumberg: Thank you.

John Curran: Okay. Microphones remain open.

Lousewies van der Laan: Hi. Lousewies van der Laan, ICANN Board. So as you probably know, there’s a big discussion within ICANN about how to comply with GDPR, and it’s a little bit more complex, because obviously there’s a lot more European data subjects involved, and this European law is going to have global reach.

To what extent is ARIN following the debate within ICANN on this and looking at the various models that have been proposed? Are there some which you have special observations about or preferences for, and is there a way in which what’s going to happen with the Whois there is going to impact your ability to do your work?

John Curran: So it’s my obligation to follow those discussions, and I have been at a level that’s probably more detailed than anyone would really want to know.

As we have discussion and example, the difference between GDPR and the police directive, which is the partner regulation to GDPR for access by law enforcement data, I’m tracking all of it because we have to. We have to know how that would apply.

We also have the potential, if someone were to tell ARIN, oh, you should hold out services to people in the UK or people in France, I would suddenly have to make all the changes to be not what looks to be similar but to actually be verbatim compliant with GDPR.

So, we have to know what the differences are at any given moment. So we are tracking it.

Regarding the particulars at ICANN and the interim model and the various proposals and the Working Group 29 commissioner’s feedback, yes, we’re tracking it. It should not impact ARIN unless someone makes the strange observation that blocks of network identifiers that are assigned to businesses for keeping the Internet running are somehow like domain names being used for branding globally.

I can understand how the name that’s used in an email, a name that’s used on a brand or billboard and is meant to be something communicated, and in many cases people use as their personal identifier, I can see how that would be considered personal data in some cases. I don’t understand how a block of IP addresses should be considered.

So I see DNS Whois and IP Whois as very different creatures. However, we’re both Internet organizations. They’re both called Whois. You cannot prevent stupidity. And so there may be some that we have to respond to entirely because people want to pace things with the same color paint.

And if so, I’ll respond. I usually don’t have a problem with a lack of words in such cases.

Okay. More questions?

Okay, please take a moment. Go read the ARIN Privacy Policy. You can find it on the web. If you go to the ARIN website on any page and go to the bottom, it’s right there. It’s called Privacy Policy.

Please let us know if you have any comments, concerns. We are open to revisions, obviously, if someone sees something that needs to be changed or something you believe is otherwise.

We’re also trying to elaborate the business processes that support this. And in the process of doing that, we may either issue more detailed information or we may end up with changes that result because it turns out it’s hard to implement in the business.

So this policy is operative, however. The new policy is operative right now. If you do send us a request to delete your data, expect it’s going to take a while because we haven’t backed that up with anything other than manual processes for now. But we’re working on it as we go forward.

That’s it. Thank you.

I’d now like to introduce our next speaker, somewhat related. I’d like to have Leslie Nobile come up and give a presentation on orphaned Point of Contact records.

Orphaned Point of Contact and Organization Identifier Deletion

Leslie Nobile: I’m going to talk about a project I’m working on to delete orphaned organizations and Points of Contact in the ARIN database. I’ll first sort of define what we mean by orphaned Orgs and POCs, because it’s a specific definition that we meant to be inclusive.

An orphaned Org is an organization that’s registered in ARIN’s database that has no registered number resources associated with it. An orphaned POC is a Point of Contact that is not associated with any number resources itself and is not associated with any organization or is associated with an organization that is orphaned.

So it’s and, and then one of the other – you know, the bottom bullet, one of either of those two, either/ors.

So these are some stats. Lots of numbers again. There’s 889,731 total organizations registered – organizations registered in ARIN’s database.

I’ve divided this into direct and indirect. As I mentioned before, directs are resources that are issued directly by ARIN or a predecessor registry, and indirects are reassignments from an upstream ISP.

So there’s 38,703 total direct organizations registered in our database, and there are 473,464 organizations that are indirect put in there by an upstream ISP due to reassignments.

The third category is the total that are currently orphaned. 377,564 organizations are orphaned, not tied to any resources in ARIN’s database. That’s 42 percent of all organizations in the database that are orphaned.

For registered POCs, we’ve got 883,414. 52,937 are direct POCs associated with organizations issued its resources directly from ARIN or predecessor. And 430,629 are indirect POCs, reassignment POCs.

Total currently orphaned, I’ve got it divided into two categories. So it’s either they have – they have no associated resources and no associated organization. There’s almost 66,000 of those, or 7.5 percent of the total POCs are orphaned due to that condition.

And then the total associated only with an orphaned organization, there’s almost 334,000 of them, or almost 38 percent are associated with an orphaned Org.

So how do Orgs and POCs become orphaned? What we see is mostly due to reassignments. It’s the reassignment condition. Typically it’s data added by an upstream ISP who either has sort of preregistered their downstream POCs and Orgs via an automated script in advance of submitting the reassignment data.

So they’ll send a boatload of POCs and Orgs in one automated script and register them in advance, and then they’ll start slowly reassigning space to those people. But a lot of times they don’t complete the SWIP. So they just register them, and they sit in the database for years potentially.

Or they do complete the reassignment, the SWIP, as we call it, they put the reassignment data in, but then when they go to reassign that block to a new customer, they don’t actually go back and delete the old POC and Org. They delete the reassignment itself, but they leave the POC and Org sitting there.

So we have hundreds of thousands of these sitting in the database.

So the other condition that is not as typical, we don’t see this as often, it could be due to people registering or preregistering POCs and Orgs in advance of requesting some type of service from ARIN, and then they don’t follow through. So that’s a much lesser degree of orphans.

So why should we be deleting them? So deleting some of – part of ARIN’s mission is to run a registry with accurate information showing which number resources have been assigned to which organization and who the Point of Contact is. You expect accurate, current information.

So that’s not – with all these orphans, that’s a lot of erroneous data sitting there, and getting rid of it can improve the accuracy and integrity of ARIN’s Whois.

It’s unnecessary information. It serves no purpose to anyone. It’s not tied to a resource, and that’s really the reason it should have been in there in the first place.

The data is often stale. It hasn’t been validated or updated for potentially years. We know this to be true in the case of orphaned POCs because we’ve actually excluded orphaned POCs from the annual POC validation. We do not send them an annual email saying update your POC, because they’re not tied to a resource. So it would be kind of a waste of time.

So we know that a lot of that data is dormant, stale, sitting there for years and not being updated.

It might actually contain personal data that a POC does not want publicly displayed. You just heard John talking about personal data. Well, a lot of these reassignments are to downstream customers. They’re made by an upstream ISP.

A lot of the times the downstream customer has no idea that they’ve been registered by an upstream. When they see their name, when they find out they’re in there, they’re calling ARIN, they’re complaining. They’re upset. They want to be out of the database immediately. We still get calls like that every day in Registration Services. They get them.

Having this erroneous data is quite inconsistent with all the increasing attention on personal data privacy. You heard John talk about it. You all read about the recent Facebook issues. There’s a lot of attention being placed on personal data privacy.

And having this data that’s useless, not serving any purpose to ARIN’s business, could be problematic at some point.

If we were to delete orphaned Orgs using a two-year criteria, just the description of an orphaned Org, and looking two years out, so we’ve got 377,564 Org IDs currently registered that are orphaned, 308,368 have been orphaned for one year or more, and 248,073 have been orphaned for two years or more.

So if we took that 248,073 right now and deleted them, using that two-year criteria, they would come out pretty much immediately. And if we looked further down the road at one to two years, another 129,491 additional orphaned Org IDs would be deleted if they were still not associated with a resource. That’s just some speculative data here.

So if we’re looking at deleting orphaned POCs using the same two-year criteria, we’ve got 65,973 that are orphaned and not tied to any organization. So that’s the top category. 62,000, almost 63,000 have been orphaned for at least one year, and 59,255 have been orphaned for two or more years.

So if we were to delete today, that 59,255 would be taken out of the database. And if we look to delete over the next year, an additional 337,000 POCs, orphaned POCs, would be deleted. And that includes those that are associated with an orphaned organization.

What would our next steps be? Ultimately, for this project, the goal is to start scheduling automated deletion of orphaned Orgs and POCs that meet the defined criteria. We want to pull out this erroneous data and get it out of there, clean up the database somewhat.

We would rerun our script, applying very specific and prudent criteria in order to obtain the current data.

And I said “prudent” in that we’re going to look at a lot of other conditions. We’ve already mapped it out. We’ve got a whole series of conditions that an Org would have to meet, or a POC, in order to be deleted. Because we want to be very safe and not pull anything out that may be useful to a company or a person.

Then we would send out a community consultation. We actually want your input. We’ll give you the current data using the applied criteria and see if anyone has anything to say, any suggestions, any ideas.

And then based on the results of the community input, we want to write a project plan – I will write up a project plan – get it prioritized, I hope, and get it added to ARIN’s operational work plan so that we can start doing this on a regular basis and cleaning up ARIN’s database.

So that is all I have. Are there any questions?

John Curran: Remote question.

Alicia Trotman: Jason Schiller, Google, ASO AC. How will you handle POCs that are not currently tied to a resource but previously were? Will that data show up in the WhoWas?

Leslie Nobile: Yes, it would show up in the WhoWas.

Tom Fantacone: Tom Fantacone, IPTrading. That was actually my question as well. In doing chain of custody research for a client that wants to engage us, we often have to look at WhoWas.

It might be helpful to be able to look at Whois on those same orphaned organizations that at one point held resources, because later they could change POCs, and might help us contact.

Leslie Nobile: Actually, and I probably failed to mention this, part of this project would be to maintain all of this data in archives. It would actually never fully disappear. So it would be available in WhoWas. That is our plan.

Alicia Trotman: Heather Schiller, Google Fiber. The suggestion to remove this orphaned data seems at odds with John’s comment that data isn’t deleted but is kept to maintain the chain of custody of assignment history.

What percentage of this data was never associated with the resource? Can you talk more about the criteria, what will be applied?

John Curran: Let me address the first part. So one of the questions is when we say “deleted,” the question is deleted from public view versus deleted from ARIN’s records.

ARIN will have a copy of all the information. We don’t – we won’t get rid of them from our historical record of the registry because we require that for our own purposes if someone comes in for integrity check or fraud or something similar.

It would be deleted from the public Whois. Right now these POCs are visible with no – associated with no resources. And so from the public Whois, we’d no longer be showing this information which has no purpose and in many cases contains personal data.

Leslie Nobile: Right. And the second part of that, so the criteria. I was actually looking at some of it before I came up here, and there’s a lot of it.

So, for example, there can’t be any open tickets associated with either the Orgs or the POCs. If there’s an open ticket, we will not delete it. It can’t be a member organization. We will not delete a member organization.

There’s so many. Heather, I’m sorry I can’t think of them all right now, but you’re going to see them when we send out the community consultation, which will be shortly after this meeting. Got it fairly prepped and ready to go. So you’ll see every single category.

If you have comments and you think other things should be included or excluded, we’d like to hear it.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I think we might need to be a little pedantic about “deleted,” and maybe you don’t want to use that word.

Leslie Nobile: We thought about that.

David Farmer: Because there’s connotations to that that are inappropriate to what we’re doing here.

Leslie Nobile: Right.

David Farmer: I got up – so clearly Whois is public information. What is the status of WhoWas? Is that public information? And if it’s not public information, what are the criteria on it?

John Curran: So WhoWas turns out to be a disaster when it comes to privacy. The short version: The short version is that we need to be able to show a business purpose for why we have – not for why we have the data that’s in WhoWas, but in this person – this registry integrity, we have no problem with ARIN having that data forever, the question is why we would allow someone outside of ARIN to access that data.

And there’s a valid reason to allow someone to access that data, even data long passed for a Internet Number Resource record, because you’re associated with it, for example.

You, if you’re the record holder, you might want to know who held it before who might claim that they’re the resource holder. I could say the converse. Someone who held it long ago might have a great interest in why they’re no longer the resource holder of record and how somehow you did. So I can see people associated with it having access to it.

The question that we face right now is WhoWas is currently available to anyone who complies to the bulk Whois AUP and for any record regardless of whether they have any association with it.

That may not be something that meets ARIN’s privacy principles. And, thus, two things that are under review as part of our processes that follow from this is bulk Whois and WhoWas data, both of which need to be carefully looked at.

Leslie Nobile: Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. John, that really helps because saying just sign this form and you have blanket access to everything that was ever, not good.

Leslie, yes, please differentiate archive versus purge or delete. There are substantial differences.

Leslie Nobile: Right. We’re using the word “delete,” but as John said, we never get rid of any registration information in the registry. That’s part of our mission.

Kevin Blumberg: That’s actually where I was going next. There’s a difference between direct and indirect. There’s no chain of custody needed, in my mind, on a reassignment. It is just a downstream annotation that was used for use cases.

And it would be really hard to say 30 years later, 20 years later, 15 years later that you need to know that I was assigned a DSL circuit, a block. You know who the owner of that block – of the main block was, the direct. Do you really need to know the indirect? Is there a business case 15 years later knowing what a detailed reassignment was to an Org or an individual that’s no longer involved?

Leslie Nobile: I can’t speak to the 15 years out, but I can speak to a year out. I know that law enforcement has used that information and that we’ve actually had to go to court and talk about what it looked like then and who it was assigned to.

Kevin Blumberg: I understand. It’s a question of how long is reasonable. And that’s for you to decide.

Leslie Nobile: Makes sense.

Another remote.

Alicia Trotman: Gary Buhrmaster: If an Org or POC is deleted, I would presume that the handle is permanently reserved, i.e., no possible reuse. Is that correct?

Leslie Nobile: That is correct. We do not plan on reusing the handles of POCs or Orgs, correct.

Alright. I think that’s it. Thanks for your attention.

John Curran: Thank you. Good presentation.

(Applause.)

John Curran: Wow. Seems like we just got here and already it’s time to break for lunch. So we’re going to break a little early. But that’s okay. We’re going to be back in here at 1:30. We will start with the NRO Activities Report.

The lunch is served – well, they’ll tell me where it’s served. Outside, around the corner. There are lunch table topics at the various tables. If you want to talk about NRPM simplification, that’s the Number Resource Policy Manual, a topic on that. LACNIC’s Global Registry Proposal has its own table. I hope that’s a big table. Justifying IPv6 requests and IPv6 implementation tips.

There’s a Women’s Network Lunch in Concerto Ballroom D, and lunch for the main is in Concerto A and B. So A and B for everyone, and if you’re joining us for the Women’s Networking Lunch, Concerto Ballroom D.

Tree testers wanted. This is not arborists. We’re busy trying to figure out which parts of ARIN’s website you use the most. If you haven’t participated in a tree test for the new ARIN website navigation, please take a try. The link is in your welcome email. That’s on the meeting application.

Tips for 6 campaign. Add your tip to the board of the foyer in the information center. If you have tips on how people should better deploy IPv6, you can fill out a Tips for 6 and put it up on the board for people to read.

Security. Take your valuables with you. This room is not locked. Things can disappear. We’re going to be back at 1:30. Please come back on time. Thank you.

(Public Policy Meeting adjourned at 12:00 PM)

Number Resource Organization Activities Report

John Curran: Welcome back. If everyone will come in and be seated. Okay. We’re going to resume our ARIN meeting, and the afternoon kicks off with the NRO Activities Report. We’ll then cover the two draft policies, 2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers, and 2018-2: Clarification of ISP Initial Allocation and Permit Renumbering, which are somewhat related. Two different ways of solving the problem of misalignment between the two things.

We then have an ARIN Fee Schedule Update. We have Cathy’s IETF Report, and we have the ASO Review Consultation.

So at the head table I have Paul, Tina, Scott – I’m sorry, see it’s really – Leif and Alison. Mr. Leibrand, if you’re out there, I miss you apparently.

(Applause.)

John Curran: Let’s get started with Paul’s presentation. Come on up, Paul.

Paul Wilson: Good afternoon, everyone. I’m Paul Wilson from APNIC. I’m here in my capacity this year as the chair of the NRO EC to give you an update about what’s been going on with the NRO for the last period of time.

If you don’t know, the purpose of the NRO is here. It’s to be the flagship and global leader for that collaborative Internet Numbers Resource Management System that John referred to earlier, which we feel is an essential element of an open, stable, and secure Internet.

It does this by coordinating the RIR system in certain RIR joint activities that we want to run in the interest of supporting that resource management system. It’s here to promote the multi-stakeholder model and the bottom-up process of policy development with respect to Internet number resources.

One of the joint RIR activities that it’s involved with also is to fulfill the role of the ICANN ASO, the Address Supporting Organization inside the ICANN structure. You can read all about the NRO at NRO.net and find out more about that.

The NRO MoU was signed back in 2003, 15 years ago, and it doesn’t create a formal structure. The NRO is an unincorporated association. But it does have a few committees.

So the executive committee is the five RIR heads working together. As I mentioned, I’m the chair of the NRO EC this year. Alan Barrett, from AFRINIC, is the Vice Chair and Secretary. Axel Pawlik from RIPE NCC, who is here, is the Treasurer this year. Oscar Robles is also here, from LACNIC. He’s also on the EC along with John Curran.

Those all rotate every year. So the list will bump up next to you with Alan as the chair.

Okay. The secretariat is run by an Executive Secretary, German Valdez, who’s hosted at APNIC. He’s got Susannah Gray working with him these days. There are three coordination groups of the NRO in communications, engineering and registration services.

So those groups are populated by the responsible staff from each RIR in each of those areas, again working together on joint activities. And they’re informal groups looking at public affairs, policy finances and legal matters that the RIRs might have in common.

The NRO has a few publications, one of them you may be hearing – seeing this one this week, I think, the Internet Number Status Report that’s a quarterly updated report with all of the global stats on IPv4 and IPv6 and AS number distribution. So that’s available on the NRO website as well.

Another important publication is a comparative policy overview. That’s a matrix-style document that gives a comparison across all five RIRs of different Internet Number Resource policy issues, which may be to do with allocations and assignments and registrations and transfers and so forth.

So if you want to understand how the RIRs, each of them, compare and how each of them deal with different policy questions, then that matrix is for you. And you’ll find that on the website.

There’s actually another comparative policy which is about the governance mechanisms of all the RIRs, so you can also find out how we all operate and compare with each other when it comes to our Board structures and memberships and fees and elections and so forth.

We also publish the ASO website at ASO.ICANN.org.

The finances of the NRO, here’s a summary of last year. We had general expenses last year of 643,000 US dollars, which included 200,000 for the IGF, but the rest is on secretariat expenses – travel, communications, meetings, et cetera.

We also made a contribution to ICANN additionally of $823,000, which is roughly – somewhere 600,000 or so of that goes directly to PTI for its provision of IANA Numbering Services to us, and the balance goes to ICANN as a voluntary contribution.

So that budget in total is divided amongst the RIRs according to an apportionment formula, and that formula is a calculation based on the respective registration services income for each RIR and IPv4 address holdings.

That formula gives us this apportionment of this responsibility for the NRO expenses. So as you see there in the last year, ARIN was responsible for 29.34 percent of the NRO expenses.

The other financial matter here is the stability fund. We’ve all made provisions and pledges to a joint fund which is around $2.1 million, which is said to be earmarked and available for support of any RIR that might need financial or operational support due to whatever circumstances they might be that threaten stability of any one RIR.

We feel that we’re all responsible to make sure that this RIR system works properly around the globe. So that fund is earmarked for exactly that purpose.

There are a few changes that came about from the IANA Stewardship Transition, as they called it, which happened over the last year. You might remember the CRISP team that put together the numbering communities’ position on the IANA stewardship transition. It designed this thing called the IANA review committee.

The review committee has started its work here. Its purpose is to support and assist the NRO EC in making sure that the IANA services are being provided to us in accordance with their service level commitments and our agreements.

And that review committee, I think we’re going to be hearing from that review committee in the course of this meeting, but it’s got 15 members, three from each region. It meets periodically, timed with the reports that come from the IANA or from PTI about its performance with the IANA Numbering Services.

And its membership – it includes, for the record, this list of people, but in the ARIN region it’s Louie Lee and Jason Schiller, who both happen to be on the Address Council as well, and Nate Davis from ARIN staff. But I think you’ll be hearing more about the review committee.

Another issue that came out of the stewardship transition and the revision to the ICANN bylaws is this thing called the Empowered Community. The point of the Empowered Community is to enforce and ensure that the community members of ICANN have got the ability to make forceful interventions in ICANN’s governance.

So there are procedures for the Empowered Community to approve and to reject actions of the ICANN Board, to remove directors of the ICANN Board and other standard practices. And so as members of the Empowered Community, the ASO has got its procedures for how we deal with our parts of those actions with respect to ICANN.

So this all sounds like a complex and bureaucratic thing, but the point of it is to share really a very well-defined power over ICANN across the community of those who are interested in ICANN’s activities or dependent on ICANN’s activities.

Now, the ASO review, something that we’ll also be hearing about here later on this, today, but under the ASO MoU, the NRO is charged with providing a periodic review of the ASO’s effectiveness. This is all part of the ICANN framework, again, that ICANN expects and requires reviews of its different components to happen periodically.

We had the first review at the ASO in 2011, and the second review happened and was concluded last year. And you can see the timeline and the announcements about the latest review there at that URL.

But the final report of the ASO review was published last August. It’s also on the website. And we’re now in the process across the RIRs and coordinated by the NRO of dealing with the ASO review report.

The NRO EC together with the ASO Address Council issued a joint response to that review report. We accepted the 18 recommendations which were made in that review report, and that response is there on that website. But of those 18, the first 17 recommendations are pretty straightforward recommendations that have got a clear beginning and end, a clear purpose, not necessarily trivial.

Some of the recommendations have got requirement for review of the – or change to the ASO MoU or to the ICANN bylaws, which may not be so easy to achieve. But at least the 17, first 17 recommendations are quite clear, and they’ve got a clear purpose and beginning and end.

The 18th recommendation, however, is more open ended and it says that the RIR should initiate community-wide consultations about the future structure of the ASO. So that’s a set of consultations which now need to go on around the RIRs.

The RIRs have agreed through the NRO that as part of that joint response that we’ll be conducting these community consultations on the future structure of the ASO. So as I say, that’s something that I understand is happening further this afternoon.

Just finally, then, a few technical projects of the NRO. We made a change to our RPKI framework over the last year with the implementation of a simpler trust anchor system where each RIR is carrying a root trust anchor carrying all the resources in the Internet Number Resource space. That’s something that was announced and is described there on the website.

We did some work on IANA/PTI reporting requirements; that is, to make sure that the reports that we’re receiving or that go to the review committee as well are in the form that we need.

We also did some work amongst the Registration Services coordination group on something called the ITHI – the Identifier Technology Health Indicators – project at ICANN.

That’s one where we were interested to ask our communities for their views on what were the appropriate measures and indicators for the health, such as it is, of the Internet of identify technologies when it comes to Internet number resources. And that’s a consultation which was beginning – which began and finished last year and has been fed into that process.

There was also a revamp of the NRO website.

And that’s all I have from NRO activities. Happy to answer any questions if there are any.

John Curran: Any questions for Paul on the NRO report?

Paul Wilson: Thank you very much.

(Applause.)

John Curran: Okay. I see we’re doing well on time. We’re going to start our Draft Policy at 2:00, which means I’m going to instead pull up a presentation from tomorrow and try to get it done now, because we don’t start policy blocks early.

So can I have the IRR consultation?

Internet Routing Registry Consultation Update

John Curran: ARIN has an open consultation out right now on our Internet Routing Registry roadmap. And you’ve all seen this on the consultation Mailing List. I also – for those of you who were at NANOG, I had a chance to present it there.

I want to tell you that the consultation remains open. Let me tell you what’s on this roadmap. If you want to come up and talk at the mics, that would be good. Or if you want to send comments to the ARIN Consult Mailing List, that would be a good idea, because we’re finalizing our roadmap very shortly.

Let’s see. ARIN’s current IRR. We’re using RIPE’s early RIR code base, and it required a lot of work to customize work with ARIN.

This has since been abandoned by RIPE. This is a dated, older code base that our current IRR is based on. We have staff who have been with ARIN far longer than this code base – sorry, the other way around. It’s based on templates and not particularly customer friendly. When you get an error, we’re kind of going through a gateway; you don’t get the real errors, and that makes supporting it challenging.

Our current Internet Routing Registry has limited information responses therefore, and it’s very problematic for updating or implementing new features.

We get requests to update our routing registry all the time. And we kind of queued those up and did a consultation in 2015 about whether or not we should do this or not.

The response was, yes, we should do an IRR update and specifically work on improving the validity of the IRR data, working with other RIRs on authorization schemes, providing appropriate proxy registration services and integrating it with the registry database.

So we actually put together a roadmap document – it’s actually out in the consultation – that says we’re going to do a refresh of our IRR with a fresh code base.

We’re going to develop IRR capabilities integrated with ARIN Online. It will not be a bolt-on implementation. It will be inherently driven out of ARIN Online. And we’ll couple, of course, obviously, the IRR data will be driven off the registration data.

We need to implement RPSL, which is the language used to do routing expressions. But at the end of the day, most of the people aren’t using the full RPSL, and full RPSL is a little more than needs to be done.

We are proposing that we’ll do a simplified framework for RPSL to a subset that covers the demand cases without creating more work than is necessary.

Collaborate with all the IRRs across IRR authentication. We’ll work with a migratory scheme for getting IRR data into the new system and work with other IRRs on standards and best practices regarding how we do these things. If there’s best practices, we’ll try to follow them.

We’d like to have your feedback. We have an open consultation. It’s running through the 25th of April. You can join the consultation list and tell us what you think there, or you can approach the microphones now.

Anyone have comments on our IRR roadmap? Yes, rear microphone.

Kevin Blumberg: Kevin Blumberg, Toronto Internet Exchange. IRR data is extremely important for Internet exchange point operators. We use it to validate routes on our route servers. They’re critical.

ARIN is the only one that can actually tell us authoritatively if that route is meant to be with that organization. So I absolutely support it. I support what you’re doing.

I reiterate, I don’t want garbage in ARIN’s IRR database. If you don’t own it, don’t deal with it. There are lots of other IRRs that will deal with garbage data. Please keep it unpolluted.

I know it’s polluted today, and I don’t have sympathy for those organizations that are putting polluted data in your database. That’s the first part to it.

The second part is I am perfectly happy to accept a simplified RPSL, especially if that will accelerate the development time to get this done. Thank you.

John Curran: One question regarding garbage data. So we’ve got this requirement that a lot of people raised, which is migrate existing IRR data into the new system. So if you have garbage data and you migrate garbage data into the new system, then suddenly it’s shiny and new and fresh data. No, that’s not true; if you migrate garbage data, you end up with a new system with garbage in it.

Along those lines, how important do you think migration is? Would you think we have to migrate automatically? Do you think we need to have a one-time migration tool for someone to run? Do you think we need to have no tool and have people put in clean data from scratch? What’s your thoughts on that?

Kevin Blumberg: I think you sunset the current IRR that you have. You give the very – at the end of the day – the small number of organizations that are using it a sunset window of 24 months at which point you yank that from providing information to the other IRRs and you only use the new one.

That’s probably a safer way than migrating and 30 percent of the routes don’t get put in, and you don’t know what’s going to or not going to get put in. There’s all sorts of cases you’re going to run into. I’d rather you just sunset it and people know not to touch it, and that’s my personal preference.

John Curran: So no automatic transfer. Would you have a way of manually looking and bringing things over?

Kevin Blumberg: Nice to have. That is something –

John Curran: Nice to have.

Kevin Blumberg: That will delay the project probably significantly. I don’t support that.

John Curran: Thank you. Front microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC.

John Curran: Speak up into the mic. You’re a big guy, and the mic is pointing at your chin.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Got it that time?

John Curran: Yep.

David Farmer: Cool. Thank you. This migration thing, I think the ability to migrate is important if you have a lot of data. If you have been relatively diligent in your data and kept it there and you’ve got a lot of it, a mechanism to migrate that data would be helpful, because you don’t want to – it would be bad to penalize the people that have been doing right by the system so far.

You should give them some cookies for have been doing that. But we don’t want to migrate the bad data.

John Curran: Okay. Do you think there’s a lot of people who have been maintaining this information? Because I guess the question is, if you’re talking about a population where 95 percent of the people haven’t been maintaining the data, then you’re making a lot of tools for the couple who are.

David Farmer: I think there’s a number of small entities that have tried to do it diligently and they’re doing it by hand, a lot of them. And so if they have to go rebuild it all by hand again in a new system, that may be a bridge too far for them, I don’t know.

John Curran: Is your organization in that circumstance?

David Farmer: Yeah.

John Curran: Okay. Got it. Okay. Helpful. Yes, remote.

Alison Wood: Jason Schiller, Google, ASO AC. I think the IRR needs to be closely coupled with the Whois data. Can we hear the community clearly supports or opposes this desire? For example, when a resource is revoked in Whois, it must be revoked in IRR. If a field exists in Whois and IRR, they must agree.

John Curran: At the present time we’re planning a tight linkage, and that means if you’re not authoritative for the resource, I don’t expect you’d be able to announce routing information.

If it turns out that we end up with – someone has another requirement in that regard, come to the microphone now. I think you’re creating a nightmare by doing so. But I would love to hear it. As it is, we’re planning a tight linkage.

Front center.

Joe Provo: Joe Provo, Google, ARIN AC. To follow on Mr. Farmer’s comment and your concern about building a complex suite of tools for the 5 percent, I would suggest thinking in terms of building an API where the people who are smart enough to plug into it would hopefully also be in that 5 percent.

And it would serve a – a migration API might actually also be useful for any sort of future IRR changes which would have to – rewind. The API might have a life beyond this one-time event because we do have a transfer market.

John Curran: Okay. When you say API, I have an old system with data. I’ve got a new system. I’ve got API into the new system – an API in general to work the new system, or an API that lets you pull data from the old one? The API is in the new system, the data is in the old one. I’m just asking what you’re speccing here.

Joe Provo: I hadn’t had a full spec when I walked up to the mic. I was merely thinking, hey, 5 percent. They should be clueful enough to not have to provide them a pretty Web face, Web interface.

John Curran: Okay, got it. Rear microphone.

Kevin Blumberg: Kevin Blumberg, Toronto Internet Exchange. John, just to clarify, there’s a couple hundred companies who are using IRR today, right?

Another suggestion that might be actually more economical, even farcical – that is, I’m not suggesting this is – a human doing IRR PT exports without writing any code is probably faster to just say, here, we’ve exported your data, here you go, email, than actually developing any system to automate the exports. It’s a small subset of people.

John Curran: Okay. Does anyone currently using ARIN’s IRR think you need a tool to help you get to the new one that will automatically migrate your dirty data over?

That’s helpful to know. A nice, clean IRR that you populate yourself, and maybe a dump of your old data if you’re an old IRR user, could suffice in this regard.

I’m closing the microphone shortly. Approach the mics.

Andrew Dul: Andrew Dul. Maybe a tool that provides you a if you have the new and the old and you do a compare, and these records are in the old but not in the new, so that you can say that that’s garbage or it’s something I need to migrate.

John Curran: Okay.

Andrew Dul: I don’t know if that’s a requirement. But that’s an idea.

John Curran: If we can get a dump, maybe we can get something to process the dump and a new IRR to let you know what you still haven’t moved.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I’ll just add to that. I think sort of some kind of DIF-like tool that lets me know, oh, this is here and not there, and you forget something, Dave.

John Curran: Okay. Not necessarily a migration tool, but a DIF roadmap. Okay. Got it.

I have people taking notes in the back. We’ll try to update the roadmap automatically.

Okay, last chance. I’ll be closing the microphones shortly. Shortly is now. The microphones are closed. I’d like to thank everyone. Wonderful feedback.

(Applause.)

John Curran: Then I come right back and I lead into the policy block.

Paul Andersen: Before we start the policy block, a little heads up. There are two policies coming up in this block, 2017-9 and 2018-2, that the AC have noted are very similar, trying to approach the same problem.

So, I just want to give the heads up what they’ve asked to do here. We’ll have the two policies presented, discussed, and then there will be the question on each. And we’re going to deal with them in isolation.

And then we’ll have a third session where we will discuss the merits of which one may be more preferred by the community.

So just to give you a heads up we’ll be first discussing them individually and then having a section where we can discuss them as which one do you potentially favor. Heads up.

John Curran: Okay. Very good. Thank you for that reminder.

Okay. The first policy is Draft Policy 2017-9: Clarification of Initial Block Size for IPv4 ISP transfers. The shepherds, David Farmer and John Springer.

Come on up, David.

Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

David Farmer: So this is the policy statement. The guts of it is at ARIN 40, just like you had earlier this morning, John Sweeting got up and talked about a few things. Well, one of the things at the last meeting he talked about was this inconsistency between 4.2.2 and 8.5.4. And it’s about the minimum transfer size. And this is causing some problems.

The policy statement is intended to try to clarify this issue. This was one option. The other policy we’re talking about will – in this same block will – it takes a different tact at it.

This is the policy text for this one. It basically says you can transfer a /24 up to a /21 for allocations. Or, in other words, ISPs. And it sets it at 24 for assignments or end users, essentially.

This is the guts of the inconsistency. These are the texts from the two sections of the current NRPM, with a couple of notes at the bottom.

And that is in 8.5.3, the minimum transfer size is a /24, and 8.5.5 allows larger blocks with documentation and attestation by the officer.

So how to fix this inconsistency: This policy, as we said, revises 8.5.4 to be consistent with 4.2.2. This is 2017-9, and it allows a /24 up to a /21 without justification for ISPs.

Just to help you contrast that, this is the other side of the slide here, the – let’s see, your right – your left – oh, never mind. I’m only confusing myself.

And basically it allows a /24 without justification, or up to a /21 when documented, when documenting its use within 24 months. So in other words, if you can show how you would use it in 24 months, then you can have more.

So questions for discussion: Should this inconsistency be fixed at all? And then are there other alternatives than the ones we’ve provided? And then what do you think of this policy? Thank you.

Paul Andersen: Thank you. Discussion. The microphones are open on the discussion of this topic, 2017-9. Please approach the microphone if you would like to discuss this policy proposal. A little lunch fatigue setting in?

I ask you to not rush the microphones or approach all at once. Please make room for others that may be – John.

John Curran: No one cares if we change the policy manual with this change? No one cares if we don’t change the policy manual with this change? If that’s the case, that’s indicative of a problem.

Paul Andersen: Front microphone.

Andrew Dul: Andrew Dul, original author of the proposal. I no longer support this proposal. I support the other method, but I don’t necessarily think that the other method is necessary either.

Paul Andersen: There will be an opportunity for that kind of discussion, but thank you. Opposed.

Front.

Owen DeLong: Owen DeLong, your organization name here.

Paul Andersen: No takers overall.

Owen DeLong: I’m mostly neutral on the – not so far – mostly neutral on this and its competitor that we will discuss next. This is a problem we created when I said we shouldn’t create it when we moved most of Section 4 to be duplicated into Section 8. And so now we get the entertainment of dealing with the consequences I predicted.

This is a perfectly fine way of addressing them. I think this way is better than the other way that is currently proposed.

On the other hand, this is v4. Do we really need to keep rearranging the deck chairs, or can we please just let the Titanic sink and move on with the v6 lifeboats? Thank you.

Paul Andersen: Okay. Rear microphone, please.

Kevin Blumberg: Kevin Blumberg, The Wire. Can you clarify, David, in Section 8.5, is there a differentiation between end users and ISPs? Is it a predominant thing? Because I really didn’t see it and here we are now –

David Farmer: This would introduce that differentiation. That’s basically what this is doing, is introducing a differentiation to resolve the problem.

Kevin Blumberg: Okay. So I wouldn’t support differentiating. I don’t see how an ISP necessarily has a different requirement than an end user. And I’ll obviously wait till the next one is up.

But the whole concept of differentiation now, especially in transfer market, makes no sense to me. If 21 is the number it needs to be, that’s fine. But I don’t agree with differentiation.

Paul Andersen: Thank you. Last call for comments on this specific proposal, please approach a microphone or start typing madly in chat so that the remote participant moderator knows you’re going to say something.

But seeing no movement and noting – Alison, I assume no – I will now close the microphones. And the microphones are now closed. I’ll thank David for the presentation. Thank you.

(Applause.)

Paul Andersen: I’ll ask my counters to get into position. Reminder, we’ll first ask on this question, then we’ll have the presentation of the next item, then there will be a third opportunity for discussion about which one you prefer. When my counters give the signal.

So I will ask the question on whether or not the community feels that this is a problem to continue working on.

Would all those in favor please raise your hand nice and high that this is a problem. Try to go as straight up as possible. Thank you. Thank you. You may lower your hand.

Would all those opposed please raise your hand nice and high. Decisive piece of data, I suppose.

If you’re remote – you may all lower your hand. Rob, if you want to start making your way up here? Rob, you’re doing the next one, right? I’m sorry, the sheet is incorrect. I apologize. They’re queued up.

The envelope is making its way. Thank you. On the matter of 2017-9, 84 in the room, 10 remote. Seven in favor. Four against. This will be provided to the AC for their consideration, and I’ll let John move into the next one.

John Curran: Next presentation, okay, Draft Policy ARIN 2018-2: Clarification to ISP Initial Allocation Policy and Permit Renumbering. Shepherds, Rob Seastrom and Kerrie Richards. Kerrie will give the AC presentation.

Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation and Permit Renumbering

Kerrie Richards: Good afternoon, everyone. Kerrie Richards here. And I’ll be presenting the Draft Policy ARIN 2018-2: Clarification to ISP Initial Allocation and Permit Renumbering.

So the problem statement is this: The criteria to qualify for an initial block of address space in 4.2.2 and 8.5.4 are at odds with each other.

Moreover, as the NRPM 2018-1 currently sits, 4.2.2 appears to state that an initial allocation of up to a /21 could be granted without any more justification than needed to qualify for a /24.

The policy text replaces the current Section 4.2.2 with 4.2.2 initial allocation to ISPs – I’m so sorry. All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN’s minimum allocation size.

All ISP organizations without direct allocations, direct assignments, reallocations or reassignments automatically qualify for a /24.

So these organizations are exempt from requirements of showing efficient utilization of previously held IPv4 space. These organizations may qualify for a larger than /24 by documenting how the requested allocation will be utilized within the request size specified in 4.2.4.3.

ISPs holding reallocations and/or reassignments must show efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.

The timetable for implementation is immediate, and the further justification is this: This is an attempt to clarify the changes that came about from 2016-4. Before my time.

It also aligns Section 4.2 with current transfer policy. It also reestablished the understanding that ISPs can renumber and return but putting the last section of 4.2.2.1.4 into the ISP additional requests section. This text is slightly modified to include returns to ARIN in addition to returns to the upstream.

That’s it.

Paul Andersen: Thanks. I will open the floor again for the discussion of this policy proposal. I would ask if you want to come and speak on this one, we’ll have another poll and we’ll allow the conversation on which one there may be a preference for.

So, again, as John says, hopefully there is some desire whether you would be okay with this change, if you would not be okay with this change. Your AC is looking for input.

Owen DeLong: Owen DeLong, your organization name here. The policy proposed here makes things more restrictive for initial allocation than current policy. If that is truly what the community prefers, so be it, but I think that the previous policy, which relaxes transfers, makes far more sense in the current environment than tightening up initial allocations that end up on a waiting list anyway.

So that’s – I guess I’m opposed as written on that basis. But let’s hear what the community has to say about it.

Paul Andersen: Thank you. Front microphone again.

Cathy Aronson: Cathy Aronson. Can you go back to the first slide of the two slides of the policy text? That one. So it says to a /21 subject to ARIN’s minimum allocation size. That’s confusing to me. So you don’t really get a /21 because the minimum allocation size is a /24?

Paul Andersen: I believe so. I see nodding from – or, Leif, did you want to comment? Or did I catch you nodding at the wrong time?

Cathy Aronson: He was nodding off instead of – I guess I just find that to be –

Paul Andersen: John is going to comment.

John Curran: Generally we’d leave this to the AC to comment because they’re the ones who work on it. So, I’m looking for a member of the AC to comment on the proposal.

Kerrie Richards: From my understanding, it may be limited. But it’s my understanding that it would be a /24, that’s what would be allocated.

Cathy Aronson: Okay. So you get a /21 – it just doesn’t make sense to me if your initial allocation is up to a /21, but you have to meet the minimum – anyway, go ahead.

Owen DeLong: It’s setting opposite bounds. Owen DeLong, ARIN AC. It’s setting opposite bounds. The minimum you can get is ARIN’s minimum allocation size which is currently set at /24 in other parts of the policy manual. And the maximum you can get under this policy is a /21.

Paul Andersen: I think that if I understand the intent, it is – a 24 would be the low end, a /21 would be the high end, from a size perspective. But I guess your point, Cathy, is there could be some text improvement, tweaking there.

Cathy Aronson: Yes.

Paul Andersen: Let’s take that as a text tweak. Are you in favor or against the policy subject to the tweaks? She’s unsure, for those remote. Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. This double “without,” is that a typo? It should be all organizations with direct assignments can get up to a /21 and “organizations without direct.” So then you’re using “without” twice. There’s no reason to do it this way, and it’s extremely confusing.

I actually don’t support any changes to this section. If 99 percent of the stuff is being done in Section 8, leave it there. If we’ve got an issue with the sizes, leave it there, do that there.

We didn’t try to couple Section 4 to Section 8 and vice versa. Section 8 is intentionally easier on things, and this is unbelievably confusing.

Paul Andersen: Don’t run away.

Kevin Blumberg: I’m not.

Paul Andersen: I wanted to say you disagree with the problem statement in principle –

Kevin Blumberg: In principle, yes.

Paul Andersen: – but if it was a policy that goes forward, you also have concerns with that wording?

Kevin Blumberg: The wording is very troubling, but I have problems overall with reorging –

Paul Andersen: I see our Director of Registration Services.

John Sweeting: John Sweeting, Senior Director of Registration Services. I just wanted to point out that the wording that’s there in the first sentence is exactly out of the text. It’s in the NRPM today. And we interpret it. They can get up to a /21, and the least they can get is – if they ask for /25, they won’t get it; they have to get at least a /24.

Paul Andersen: Thank you. Appreciate the clarification. Any remote participant?

I would ask, since we’re rapidly running out of speakers, if you wish to speak on this topic, for or against, please approach a microphone. I will be closing the microphones at the end of this speaker.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I would ask that people not get too hung up on the text. We’re in the draft stage. It’s good feedback that this text isn’t very clear.

What the AC needs to know is where do we want to go with this. Do you like one of these two proposals – do you like one of these two proposals better than the other –

Paul Andersen: We’re going to have that discussion next –

David Farmer: Or which direction? Should it be /24? Should it be /21? What do we want to see? Don’t get quite too hung up on the text, because we can change that. What we need to know is where do we go with it.

Paul Andersen: Okay. No remote. Okay. The microphones will be closed after this last speaker has injected, unless of course he causes a flurry of people running to microphones.

John Curran: Just for clarity, it’s worth reading the present text of 4.2.2 and then reading the replacement text. The present text is in your Discussion Guide.

And the present text, by reading the present text, you can see that there’s confusion in the present text that the proposal would clarify. Whether or not it’s a good clarification or not is a different question.

But in terms of what it accomplishes, it’s true that there’s – the current text is more confusing by far than the proposed text.

Paul Andersen: Okay. Alright. The microphones are closed. I’d like to thank Kerrie for the presentation. Let’s all give her a big hand.

(Applause.)

So now I’m going to go to our poll on this proposal. And then we’ll go immediately into a discussion on the next, on both of the proposals that we just talked about at the same time and if there’s a preference.

So on the matter of 2018-2, I’ll ask the question of those who are in favor of the AC continuing to work on this policy proposal, I ask all those in favor to raise your hand nice and high, and let’s see if we can get a little more audience participation going here.

There’s a prize for the number of times, whoever votes the most number of times, don’t you know? I just made it up, but … thank you.

All those opposed please raise your hand nice and high. Thank you. While we wait for that, I will enter into the discussion, reopen the microphones right now.

The idea is to allow for discussion on a question that – and I’ll ask Tina for a little bit – the question we’d like to ask is, which of the two options would you prefer the AC to continue to work on, of the two proposals.

So we first – because this is a matter of process, if there’s a question to be asked, we give opportunity. So I’d ask if you’d like to comment on one versus the other, make an argument; please feel free to approach a microphone.

Owen and David are deciding whether they’re going to – the microphones are open. The microphones will close when I get the ballot from the – we have someone. Rear microphone, please.

Kevin Blumberg: Kevin Blumberg, The Wire. You asked us to look at 4.2.2. And it’s really the second sentence that you’re referring to, which is the hanging chad: ISP renumbering is not possible in the NRPM anymore.

So instead of just getting rid of this whole text, which is ISP renumbering, which in this day and age I don’t understand why anybody would renumber and return versus transfer it out or keep it to use it or whatever the case may be.

And so instead of just getting rid of renumbering, we’re creating all these complexities to, again, question mark, question mark, do what? I would love to understand that. I’d love to understand the problem we’re really trying to solve.

If this is a difference between Section 4 and Section 8, I’m happy with the differences between these two sections; they’re not the same.

That’s from my perspective. I’m trying to understand and love to understand it from other people.

Paul Andersen: Thank you. Further discussion on 2017-9 versus 2018-2, we have a remote participant. So we’ll go there next please.

Alison Wood: Jason Schiller, Google, ASOAC. It seems unfair to me that an ISP holding an underutilized /24 needs to justify getting a additional /24, but a new organization holding nothing can get a /21 with no questions asked.

Owen DeLong: Owen DeLong. I’m not in overly favor of either proposal, but if we are going to continue to work on one, I think the first one makes most sentence.

Paul Andersen: 2017-9?

Owen DeLong: Yeah. Alternatively we can look at just deleting everything we can from Section 4 and moving on since it’s really no longer relevant. v4 is mostly dead; let’s finish killing it. Thank you.

Alyssa Moore: Alyssa Moore, Cybera and ARIN AC. Again, I don’t know that there’s an actual problem here to be addressed. But if the community does feel we’re going to work on something, I prefer the second one with a little bit of language cleanup, removing that subject to ARIN’s minimum, which disagrees with each other, the /21 to /24, and having it a /21.

Paul Andersen: Okay. So preference for 2018-2. Please approach a microphone if you would like to speak on this, and we’ll go to our poll. And then we’ll be a bit ahead John, I think. Microphones will be closed at the end of this comment.

David Farmer: David Farmer, University of Minnesota, ARIN AC.

I want to channel John Sweeting’s presentation at the last meeting that this is a problem. It may not be a problem for the people in this room. We may all understand it just fine.

However, the people that call registration services and want to get resources and do this, this creates confusion. So I have a problem with people saying there isn’t a problem, because there’s a confusion that’s being created. And I think we as a community need to do something about that.

I don’t have a stake in which way we go. I could care less almost. But the fact that there’s confusion, and the fact it creates confusion for the people that aren’t in this room is a big problem for me.

Paul Andersen: With that, the microphones are closed. So the question that will be asked, Tina, if you wish to continue with it, would be which of these two proposals would you prefer the AC to choose working on if they were to choose one. And the two options being ARIN-2017-9, I’ll call for first, and ARIN-2018-2 second.

And I stress that this is very important data to the AC, so please try if you do have a view to put your hand up for one of them. Counters, I see in position. I will then ask all those that would support continuing with ARIN-2017-9 to raise your hand nice and high.

Okay, you may lower them. Those that will prefer ARIN-2018-2 raise your hand nice and high. And of course remote, participate. There’s instructions there I’m told.

They will be meeting later this week to try and take all the data gained from this and decide how proceed. So I know they always appreciate your data so – just wait for the envelope. And of course you can grab your local AC member at tonight’s social.

John Curran: I might need to buy them a calculator.

Paul Andersen: Alright. The envelope is coming. It says an envelope, but it’s really just cardboard, paper. Thank you, Michael.

We lost somebody in the room, so went to 85 in the room, 12 remote.

For 2017-9, 10; for 2018-2, 14.

We’ll provide it to the AC chair for their input, and that ends this draft policy block. John, what’s next?

John Curran: We’re ahead of schedule, so we’ll move right into the proposed ARIN fee schedule increase.

ARIN Fee Schedule Update

John Curran: So as people know, we have a proposed increase to the fee schedule. That’s out on the ARIN Consult Mailing List. I’d like to introduce why the Board’s considering this, and then I’m sure we’ll get a comment or two before break. I wouldn’t hold cookies between you and this consultation, so we’ll go quick.

In December, the Board adopted a budget which included the outline of a fee increase. I’ll talk about why they did that.

The particular proposal was developed over the last few months from an outline into an actual hard recommendation. This went to the Fin Com, and then from the Fin Com – Financial Committee of the Board — they recommended it to the Board. The Board recommended it to initiate the community consultation to raise the fees. RSA agreements and LRSA agreements call for communication consultation process before changing the fees. This is that.

So we’re engaging in community consultation. Timing: March recommendation; April Board initiation of community consultation. We would be moving ahead in May depending on the outcome of the discussion in the community. And so let’s talk about it.

So a proposed fee changes a few things. It changes the facilitator fee from $100 to $1,000 a year. Sounds like a lot, a thousand percent increase. Yeah. It’s a thousand percent increase, now that I think about it.

And the reason it is is because the facilitator program is something we put in place so that people who helped accomplish transfers would have referrals from ARIN. People would know how to get ahold of them, people would want to list resources or say they wanted to list resources would be able to make use of the program.

The problem with the facilitator fee is that we have a lot of people that put ARIN facilitator on their website. In fact, we have more people who put ARIN facilitator on their website than there are ARIN facilitators. And this turns out to be a problem.

Some people are using the mark without actually being an ARIN facilitator, which causes us to spin up letters and telling them to cease and desist and not use our mark, because we have to protect them. We have to make sure someone who is an ARIN facilitator only uses the mark if they really are valid.

That actually entails costs, and the costs include legal costs, as it turns out. This program that was supposed to be an easy nice-to-have actually does run actual costs more than just the staff support, more than expected.

We don’t have many facilitators, so it’s not a huge amount of revenue generated. It’s really about being fair. If we have a program that has tens of thousands of support costs and preventing people from misusing the mark, it’s only fair that we recover that from that group of people.

So that’s the facilitator fee increase.

Maintenance fees. Going from $100 to $150 per object per year. This is will be applied to end users. And they’re applied to IPv4 blocks, IPv6 blocks and ASNs. It’s very simple. We currently charge $100 per object, per year. We’re proposing increasing that to $150. That’s a $50 increase, but it’s a large percentage increase.

You don’t pay maintenance fees if you’re on a registration services plan. All of our ISPs are members, are on our registration service plan, and their registration services are based on total size of the resources held, IPv4 or v6. And they don’t pay registration services fee – maintenance fees for v4, v6 or for ASNs for that matter.

They’re generally ISPs. So we’re talking about an increase to the end users, not to the ISPs. Very use early LRSAs – if you were one of the first 300 LRSAs, there’s a cap on total fees that ARIN can charge you of $100 per year.

We propose increasing this cap from $100 to $200 per organization. And so that’s a – just something that you need to know if you’re holding one of those very early LRSAs, versions 1 and 2.

Net effect on revenue. Facilitator fee, $3,400 annual. End-user maintenance fee, $1.4 million annual. Very early LRSA, about $200k annual. The total revenue increase, about $1.6 million.

So we have a change that helps address a budget situation. The budget situation that’s addressed is that we brought on quite a bit of engineering staff to catch up with the backlog. We’ve had very good results.

You’ve seen customer consultation. If you look at where we’re going trend-wise, though, we’re currently significantly higher expenses over revenue.

Not a big problem. But it means we’re draining the reserves. I can remember many years we stood up here and we had people line up at the microphone saying: ARIN is not spending its reserves. They’re growing too fast.

Well, we don’t have that problem now. We have the other problem. We have brought on, 2015-16, we brought on additional staff. And we’re now running negative.

Now, we are planning on adjusting some of the staff. The staff was intentionally brought on on surge. And currently the plan of record has us correcting some of that and adjusting at year end 2018.

But even after the adjustment, we’ll be operating net to reserves of about $1.4 million per year. And that means that the reserve balance over time on a base case will go slowly down. You see it going from $24.9 in 2019 to – oops, sorry, to – let me get the laser pointer – going down over time slowly down to about $20 million in the base outlook.

With the fee increase, we won’t have that decline in reserve balance. With the fee increase, we’ll be level on reserves – this is after a staff reduction at the end of 2009 and basically stable throughout.

So that’s what we’re looking at. And microphones are open for questions. Yes, Owen.

Owen DeLong: Owen DeLong speaking for myself strictly in this context. ARIN conducted a survey in 2017 of its members and possibly other community members, I’m not sure, people receiving services from ARIN.

And 75 percent said they want the same fees and services. You have publicly stated that these costs over revenue are largely related to continuing to expand services and engineering efforts related thereto.

That flies in the face of the expressed wishes of 75 percent. So I would advocate that we instead consider cutting those expenses and not raising fees.

If we are going to raise fees, it seems rather odd to me that the two constituencies that are attached to this increase are the two constituencies that pay ARIN fees but do not have a voice in electing the Board or the AC. You do not attach the fee increase to the people that actually have a vote in the organization.

I would rather see the fee increase spread more evenly on a proportional basis, not dollar figure basis, as you proposed in the email, across all of the people that are paying ARIN fees, if we are going to preserve that. Thank you.

Paul Andersen: John, can I comment on one thing?

John Curran: Go ahead.

Paul Andersen: So I guess just one thing I’d point out is that I believe it was just under two years ago that we did do on the ISP side a significant – we actually added some much higher level and some much lower levels to spread out. So there were some significant fee changes both ways.

Owen DeLong: Also, multiplied end-user fees, too.

Paul Andersen: Well, the same. We’ve been constantly looking at that on some of those fees at that time. I believe the last LRSA one was, I’m sorry, end user one was about five years for the one you’re talking.

John Curran: But the structure of the end-user fees did change at the same time we changed the ISP fees.

So it is true. We otherwise haven’t changed them. But when you change the structure to fund some people, it’s effectively an increase.

Owen DeLong: You changed the structure in the way that tripled, quadrupled, quintupled or more the vast majority of end users I suspect.

John Curran: So three responses to think about. First, for some reason, even though 75 percent of the members said they want the same fees and the same service, the 25 percent who want new services have been extremely active.

We have lots of suggestions for new services. Even today, over the last six hours, we’ve had people standing up saying more things ARIN should do.

Owen DeLong: Point of clarification. That’s not 25 percent. It’s 12 percent, because 13 percent actually said they wanted less service and lower fees.

John Curran: Okay. So of the 13 percent who say they want more, they seem to be very active. And even this community keeps suggesting that we do things and update existing systems. We add more capabilities. The same community said make the website navigation easier. The same community said refresh the IRR.

So we have to worry about the fact that those 12 percent or the 12 percent who said they want same fees or more fees and more services are actively suggesting them and they’re well supported by the community.

We haven’t heard anyone say stop doing these services. In fact, every time we propose trying to stop new services we get told pretty much no.

Owen DeLong: Slow down the rate at which you’re doing new services, so it falls in line with the budget. There, now you’ve heard it.

John Curran: We’ll be doing some of the slow-down because that’s already in the plan. But it’s a midpoint. Something else to consider regarding fees: Parties who have multiple resources, there is the option of going to a registration services plan and paying like an ISP, and you’ll pay based on your total address size of whatever your largest category is, IPv4 or IPv6. You won’t pay for your ASNs anymore, maintenance fees, because those are included. And you’ll be a member.

So for some people whose resource holdings don’t add up to a lot of resources, they actually could move to a registration services plan and suddenly be paying less. Something also to think about. No one will end up paying a lot more unless they actually have very large address blocks.

Microphone at the back.

Kevin Blumberg: Kevin Blumberg, The Wire. I don’t have access to the budgeting and the Fin Com and all that you have. And I’m sure this is coming from a lot of data, not just this. The one thing I do notice is that your expenses don’t equal cost of living increases as a minimum.

I don’t see a 2 to 5 percent per year. I see a decrease in ‘20, ‘21, very similar numbers. So I can – you’re not asking for more in the numbers here. So that’s the first thing that I do see.

As a small org, I took a big hit two, three years ago with the fee changes. Just the way things worked out, a lot of us did.

I was joking with somebody last night about the fact that I’m paying $750 more a year, and they said I’m paying $200,000 more a year, ha-ha. The ISPs took a big hit on this. I understand that it was painful, but people agreed with it because we wanted this work done.

The one thing that was said was: We’re not going to raise end users three years ago. We’re going to give it time, but we’re going to slowly do stuff to bring them closer. And this seems to be that attempt.

So I actually agree with what you’re doing here. I understand you can be on the registration services plan for $250 if you have the very smallest of the groups.

And correct me if I’m wrong, John, at $250 you would be a member?

John Curran: You would be a member.

Kevin Blumberg: Which is less than you’re paying –

John Curran: Well, it might be less. Yes, you would be less if you had an ASN and IPv4 block, you’d be paying $50 less.

Kevin Blumberg: So I think my only concern that I’m seeing here and what I’ve seen on the Mailing List is regarding the legacy space holders and the legacy concerns. I don’t know how many people that affects. I don’t know how many people take it out. I don’t care. It’s such – whatever you need to do to not have that issue there, it’s a minor part of it in my mind.

The people who have end users need to start over time to get up as they become less and less differences, and there’s going to be less and less legacy resources over time. It’s going to become less and less of an issue.

John Curran: That’s truly one way to look at it. We have 500 organizations under legacy agreements. And we have 15,000 organizations with legacy resources that aren’t under legacy agreement.

When ARIN – in 1997 when ARIN was formed, it was formed so that the community could have a voice in how these resources were administered. And at that time, the question came up: Should the existing resource holders, all of them, be told to pay, or should they be grandfathered in and be given services?

The Board said: No, we’re going to waive fees for the legacy holders, all of them, all 15,000, but we’re going to encourage them to come in with an LRSA and support ARIN.

We had 500 who came in and supported ARIN. We have thousands who don’t, but less because it’s dropping as the market mines that.

We don’t really want to charge legacy holders any more than we’re charging end users. We want everyone to pay the same fee schedule and have the same options.

So it is true, compared to not paying at all, or paying the old fees, legacy holders will be paying more. But they won’t be paying more than any other legacy holder. They won’t be paying more than any other end user.

And the real question is how do we get the rest of the legacy holders in, because if we did, all these fees would be a lot lower.

Kevin Blumberg: I believe Leslie Nobile’s number this morning was 6,000 legacy. Is that holders or blocks?

John Curran: That’s blocks. But there’s generally not quite one-to-one, but very close to one-to-one.

Kevin Blumberg: So 6,000 have been dealt with. Maybe over the next two years another 6,000. It’s a diminishing return. The one thing that does ring true – it has nothing to do with me, but it does ring true – is those that signed the LRSA, don’t penalize them for having signed it.

And, again, from what I’m seeing there, it’s a very small amount in what you’re talking about.

John Curran: Point noted. Microphones remain open. Remote participant.

Alison Wood: Jason Schiller, Google, ASO AC. He has three points to make. One, please do not have a variable fee schedule.

Two, he’s happy for the large or the larger organizations to pay more, especially if it means we get more IT development.

And three, please do not raise fees on the very small, much less a 50 percent increase.

John Curran: Okay.

Joe Provo: Joe Provo, Google, ARIN AC, and speaking as one of those 500 LRSA in an individual capacity.

I can eat that, but I don’t know if others can. And I do want to echo the points made that penalizing people not getting the services is just not cool.

John Curran: Okay. Front and center.

Rob Seastrom: Rob Seastrom, Legacy RSA signatory. I don’t think of this in terms of a 50 percent increase. I think of this in terms of a 200 percent lift over what I signed 10 years ago in the same period of time that the CPI-U has gone up 20 percent.

John Curran: Okay.

Rob Seastrom: Thank you.

John Curran: Microphones remain open. Closing the microphones soon. How long should be always the same amount except we’re going into break with coffee and cookies.

Paul Andersen: Did nobody have any view on the facilitator fee? I don’t think we got any feedback on that.

John Curran: Okay. Hold. And Owen will be our last speaker.

Owen DeLong: Owen DeLong. I’ll ask one question on the facilitator fee, since Paul elicited it. Does $34,000 a year actually cover the legal costs incurred in protecting the mark?

John Curran: Yeah, we spent a little bit of time making sure we have the process down and the minimum amount of legal work to do it. It generally – if we had five or ten people all show up and all need cease and desist letters, it might be more.

But at the current rate, it’s covered. It’s not if we had a surge in people suddenly claiming falsely to be ARIN facilitators. I can’t predict the future.

Owen DeLong: I’m also confused as to how 43,000 works out to be a multiple of 900, but it’s neither here nor there.

John Curran: A thousand – it’s because they’re already paying 100, but I’ve rounded the numbers for adding them up.

Okay. Last shot. Closing the microphones. The microphones are closed. Thank you very much.

Okay. We are now hopefully moving into the break. And I will put up – do we have break slides? No break slides, wonderful.

Okay, break is right outside. And we’re going to resume promptly at 3:30. Is that correct? Someone double-check my schedule because I don’t have it up here.

Everyone enjoy your break. I’ll see you back here at 3:30.

(Break from 2:47 PM to 3:32 PM)

Internet Engineering Task Force Report

John Curran: Welcome back. If everyone would get seated, we will start in on the afternoon activities. This includes the IETF Report with Cathy Aronson.

We send Cathy off to the IETF so she can track all this, come back, and report it to you. I have to say it’s a thankless job, but we’ll thank her afterwards. And just very happy to have her here and her insight into all the goings-on at IETF, because it’s quite a lot of information.

Cathy, over to you. Take as long as you like.

Cathy Aronson: You don’t want me to take as long as I’d like.

So I try every month of the year to do night photography, and this was in March in London, but it was at night. So I think it counts.

But in December and January and February in Jackson, it’s a little bit colder. Just saying.

Okay. So a couple of things about my report. This covers two IETFs. So it covers the November IETF and the March IETF. So if you’re looking up something, because there’s a lot of exercise for the reader in here, just know that it might be from the Singapore IETF 100 or it might be from IETF 101.

This is sort of the helicopter view of the IETF. So the slides are very dense. There’s some slides I probably won’t talk about, but you might be interested to look that group up if it impacts your daily life or whatever.

So I’m not a DNSSEC expert by any stretch of the imagination. And there’s a ton of DNSSEC and RPKI in here. Yes, that’s that.

So, I learned a valuable lesson. I don’t know how many here know Allison Mankin, but she’s somebody I’ve looked up to my entire networking career. And if you spend a lot of time around her, you get volunteered for things. You get nominated for things. It’s pretty cool.

But I was in the Advanced Network Research Prize selection committee, which was great. I read all these really interesting papers. They’re all published before they’re submitted, so it’s a little bit different kind of selection process than, like, if you were selecting it for publication.

But these two didn’t win, but they’re both published papers and they both affect this community. The first one is talking about geolocation and using the databases available to see where addresses are. And it references ARIN, and the quote from the document is “The worst-city level accuracy for all the databases is observed for ARIN addresses.”

So this touches upon our whole validation of the database, all that sort of stuff. And they saw that in their research. So it’s a pretty interesting paper.

The other one is about – they’re analyzing the IP address markets, and they’re trying to predict and look at the data and see if they can determine whether that address was transferred or not.

And they have some concept of transfers in the wild, and those would be the ones that maybe the address was transferred but it doesn’t show up in an IRR database. And I sort of debate whether if it didn’t get logged in the database did it really happen.

Anyway, it’s a pretty interesting paper. And since it impacts this community, I felt I should at least point it out. And I sent these both to the AC at one point or another.

So the other thing that’s happening at the IETF is the v6 working groups, which, of course, I need to go to for this presentation. They’ve decided that it’s super fun to turn on v4 during the v6 working groups, which is super frustrating if you’re trying to get anything that you need to get done, done.

But we did find some bugs. And I was going to give a big shoutout to Lee Howard, because I think it was his idea, but he’s not here. I’ll talk some more about the problems that we found when they did that in a bit.

So IEPG is the operations group that meets on the Sunday before the IETF, and the IETF continues to seem to have limited knowledge that it exists, but it’s been meeting for about 20 years.

And this is the website where the slides and stuff are. And there’s a Mailing List.

Let’s see. So this is a survey. They’re doing a survey of control plane security mechanisms and talking about different ways to secure the network. Let’s see.

So this is a study that they’re doing of domain name server latency and how to make the latency less, and whether a bigger Anycast is better or smaller Anycast or maybe it needs to be bigger, but it needs to be the right size and the right distribution.

And there’s some more things I’ll talk about. There’s a lot of DNS stuff that happens at the IETF these days.

There was actually an IPv6 DOS attack. IPv6 has arrived apparently. And there’s a bunch of documentation about the open resolvers that were used to amplify the attack. I’ve heard there have been attacks before, but this was the first really observed, documented attack using IPv6.

So the main takeaway from that is that we need to make v6 at least as hardened in the DNS as v4. Otherwise this will probably continue. And there’s some links to news articles about it. Let’s see.

So Geoff Huston always gives these really great presentations. And this one’s really all about IP fragmentation. And as we do v6 and we do DNSSEC and we do all these things that make the packets bigger, we still have a 1500-byte MTU on Ethernet. So we’re limited in the network by the size of the packet that before it gets fragmented.

And a lot of failures are happening because the packets are getting fragmented and firewalls and all sorts of things filter the fragments. So there’s a lot of folks looking at how do you tell the DNS, in this case, how do you tell the DNS to start using TCP and not wait for these failures.

So like I said, I’m always amazed that the Internet even works because this stuff is so broken, yet we all use it and it seems to work when we use it.

So let’s see. What’s next? So the RIPE Atlas folks, they have those – sorry, I didn’t mean to be really loud – they have those probes that are in everybody’s places – like, I have one in my house in Wyoming. I think I might be the only one of two in Wyoming. And now they’re starting to look at client-to-client traffic as opposed to client-to-server traffic.

And does, like, traffic within a country go between – go to an Internet exchange point into another country and back, and that sort of thing. So performance from client to client, because there’s so many of these probes now that they can actually look at that.

Let’s see. So, yeah, and this is – there’s a whole lot of stuff that they’re talking about because we didn’t roll over the key signing key in the DNSSEC in October and they’re planning it for October again.

So there’s a lot of talks at this IETF and a lot of work being done, trying to determine are we ready, what’s going to break if we’re not, and all that sort of stuff.

So this is one of those presentations. So like I said, we didn’t roll the key as planned. And there’s a lot of people – I think I have another slide of Geoff’s presentation about trying to determine if we’re ready to roll the key.

And I don’t know if anybody in this meeting is going to talk about that that knows more than I do, but there’s a lot of work being done.

So ROA, when you’re validating BGP routes, you use the ROA. And they’re looking at which countries have the most foreign ROAs. So in Colombia, they’re Colombian routes that they’re being routed via other ISPs, so the Autonomous System Number in the ROA is from another country.

And so some of this is malicious intent and some of it is just how the network is connected together. And so that’s what this talk was about.

So this was a talk about raw time versus real time. So when you use NTP or you need to know that it’s 12:42 AM, but maybe you only really need to know that it’s two seconds after the other thing happened, which would be raw time.

So this woman was looking at a whole thing of which protocols really need NTP and which protocols could just be it happens in 15 seconds. And then they need to fix NTP to work with all the things that require it.

Let’s see. And then the DNS infrastructure, there’s a lot of work being done like I said about the speed about the DNS. And the thing about this I love is that there’s nine top-level demands using the same AS.

So they don’t have any redundancy service provider-wise. They don’t have any redundancy geographically; they’re using the same ISP, basically. And that doesn’t bode well for attacks or diversity or any of that sort of thing.

Let’s see. So I went to a technical plenary that had three awesome presentations about community networks. Like, they do exist, and we just have a proposal to help them.

I think the most – my favorite of these three talks was the third guy who talked about all the different kinds of satellite networks that are being used to glue all these little teeny places together and the difference, tradeoffs between latency and cloud cover, because some of them are really affected by cloud cover and some of them are really affected by other things.

And it was just really great. And I think that the one really great quote from this was that we care more about connecting refrigerators than we do people, poor people, which is really kind of sad, but kind of – actually kind of a little bit true.

So if you want to check it out, these guys are actually – maybe somehow we could get community networks to participate, I don’t know. Anyway, it was a whole hour of community networks.

So DNS operations, this is all about obviously the operations of the DNS and how we keep it all running. There’s some really interesting talks.

Let’s see. So this is a draft by Joe Abley? John? I can’t think of his first name. I’m channelling John Curran right now. Joe Abley. And they’re looking at how you can get a trust anchor if you – gracefully if there isn’t one available, how you can do a key rollover in the absence of the infrastructure.

So it took me – sometimes I guess I’m a little dense, but it took me a while to get the DNS Camel. But basically this is about how many DNS RFCs we can have before we break the DNS, break the camel’s back.

So there’s 185 DNS RFCs. That’s almost like 3,000 pages. And it’s getting harder and harder to write an implementation because there’s more and more and more and more standards that affect how you write an implementation to do the DNS.

So I do know for a fact that there’s one DNS RFC that didn’t happen, and that was validating BGP routes with the DNS that was proposed in the ’90s. And that didn’t happen.

But I think pretty much everything else has. So it’s something to keep an eye on. And I like the three in NSEC3 is the number of people who understand it.

Let’s see, here’s a few more drafts. There’s a terminology draft that’s being worked on. Let’s see. And, again, Geoff talked some more about the key signing key rollover and what happened and what we need to do going forward. There’s a lot of work being done on that.

Here’s some other drafts that we’re not going to be talking about. But if you’re interested, you could check them out.

So the datacenter routing BoF. There’s a lot of really interesting pathologies that happen, especially with linked state protocols when you have all that density of networking all in one room, all connected together on the same virtual LAN and stuff that I never really thought about until I saw these hybrid – well, I’m jumping ahead.

So most of this work is done in other groups, but I think they’re really trying to get together like a cohesive vision of what datacenter routing should look like and try to solve some of the really big problems of broadcast storms and those sort of things that are happening.

So there’s this whole new string of, like, distance vector and linked state hybrid routing protocols to try to solve this problem. And yikes is my response to this. Like, it’s BGP, but it’s OSPF. But it’s BGP, but it’s OSPF.

Anyway. And the RIFT is another proposed routing protocol to sell some of these problems. So if you’re in the datacenter space, you might want to follow this because it’s going to hopefully make life better. I’m not really sure yet.

These are some of the other stuff that’s going on in that working group. Let’s see. So v6 ops. So the other thing I did with this presentation is I highlighted some of the things I didn’t want to forget because every time I get up here there’s at least one slide that I look at and think why in the world is that in here, I don’t remember what I was going to say. So the bold stuff is just mostly for me.

So let’s see. These guys, these mythic beast guys, they started this IPv6-only datacenter, only hosting service basically. So it’s all on v6, and they’re coming across a number of different issues.

They found that spam is filtered on a /64 boundary. So if your whole datacenter is in a /64, you’re pretty much hosed if you have a spammer in there. So, they’re starting to do the prefix for customers just like the standards are now saying.

So, again, there’s been a bunch of talks about fragmentation at both of the IETFs because, like I said before, the MTU is – we’re still limited by Ethernet. And there’s some intention from perhaps somebody from the IETF to try to work on that with the IEEE, but I’m not really privy to that.

So the fragmentation causes a lot of problems. So there was a v6 hack-a-thon. There’s a number of hack-a-thons at the IETF now. And there were a number of problems that went away as soon as they upgraded the software.

And they’re starting to define – there’s a couple things that happened at this IETF that kind of surprised me. And I’ll talk about another one later. But this kind of surprised me.

So what is IPv6-only? That’s a really good question. Like I thought, well, it’s just IPv6. That’s all you have is IPv6. That must be what IPv6 only is. But does it have a translation between v6 and v4? What kind of translation are you using?

I mean, there’s all these – it’s sort of like a bunch of people trying to figure out, with blindfolds on, trying to figure out what an elephant is. So we’ll see how that comes along.

So there was a talk at the v6-only deployment at Cisco. They did it in a whole building. And these are some of the things that they found when they did that. Storage devices aren’t using v6 yet.

Let’s see. Let’s see. So there’s more NAT 64 deployment guidelines and v6 for P2P links, we’re still debating whether we should use the /128 or /64 or whatever for our P2P links.

So Homenet, my favorite, my very, very favorite working group. So they’re starting to talk about security in the Homenet. Again, something I thought maybe we should start with, but hasn’t actually started that way. So they’re starting to talk about security for the Homenet and how do you bootstrap the security for the Homenet.

There’s different kinds of security, routing protocol security, perimeter security, all that sort of stuff.

And the working group charter. So when the working group was formed, so that was at least seven years ago, they were supposed to write a security document, but that hasn’t happened yet. And I think Ted – yeah, Ted volunteered to write it. So we’ll see how it turns out.

Let’s see. And they finally decided, because you know we had Homenet.net or home.net was the domain for Homenet, Homenet.net. And then they didn’t do all the proper work on the IETF side to actually make home.net be the network for Homenet.

So the IETF has complete control over DARPA. So they decided it would be home.ARPA. So now the official default home network for your home will be home.ARPA. And these are some more drafts that are going on in Homenet. Some laughter from that one.

So this is another one of those things, like how do we define a Homenet? Again, I thought maybe we would have done that already. But I guess we didn’t.

But the good news is, I don’t know if you know Jordi, Jordi Palet, but he’s actually really grappling with defining these things and writing documents to define them. And it’s a thankless job, but he’s giving it a shot.

Let’s see. Okay. So the IASA group. I’ll just touch on it really quickly. Just like what NANOG did when they decided to leave Merit and become their own organization.

The IETF is defined as an activity of the Internet Society, and it makes it difficult sometimes because the management, the leadership of the IETF can’t sign a contract or they can’t approve certain things. And they need to have somebody at the Internet Society do that.

So they’re looking at do we form our own organization, do we – do we remain a subsidiary of ISOC. So there’s a bunch of work being done in that, who do we want to be, how are we going to do this.

They’re still going to be really intertwined with the Internet Society. Because I’m not sure that it will ever be completely self-sufficient. But it would be nice for the leadership to be able to do some of the things that leadership should be able to do.

And I love this quote: You’ll never find so much money with so few strings anywhere else.

But IPv6 maintenance. V6ops is all about v6 and v4 interoperating and being able to go between. And 6man is all about maintaining the v6 protocol itself. So that’s the distinction between the two groups. So this is more of a protocol upkeep.

And now we know that IPv6 is an official Internet standard as of the end of last year, which is super cool. This is the group that works on that.

So they’re working a lot on segment routing. And I know that you guys have heard me up here over and over again talking about how segment – the headers, the extension headers are filtered a lot, yet we’re still making protocols that use them.

So something has to give. We have to stop filtering them or we have to stop making protocols that use them. But there’s a segment routing header where they’re looking at using the header to route the packets through the network.

Let’s see. This is all about address usage and what – you might want to have multiple addresses for a device for multiple different functions, like a security address and a privacy address. And since v6 has so much address space, they’re looking at all these ways you can use address space on devices.

Let’s see. So this is – I talked about this on my first slide. So they decided that they would turn off v4 in our meeting room. You could kind of get one of the access points if you tried really hard and you were sitting near the door, not that I did that.

But they found this really interesting AP behavior where you lose your default route and then you couldn’t get it back.

And there was some – they changed some timeouts, because basically it would work just fine for like 12 minutes and then all of a sudden you couldn’t ever, ever get connected again. And everybody was really annoyed.

But it was good to find the bug. And although I know that at the IETF last month, they didn’t turn off v4 in the v6 working group. So somebody, I don’t know.

It’s a tradeoff we have at all these meetings. People still have to get their work done at their day job. And if you muck around with the network or – like I always wanted at these meetings for us to turn the network off during the meeting because I thought it would be super cool if everybody was listening. But that didn’t go over very well.

So and dual-stack hosts with Happy Eyeballs just switched to v4, and everybody was fine. But if you couldn’t get to the access point, you were pretty much hosed.

And there’s some – this is a link at the bottom here to – there’s a bunch of multivendor interoperability testing done in this. And there’s some results from the segment header routing stuff, so if you want to check that out.

This is just some more stuff that’s going on in 6man.

So operations area. So, when I don’t have a working group that I feel that I have to go to, I go to these umbrella groups, because these are where all the things that don’t have a working group yet or don’t fit into a working group or maybe some day they’ll form a working group, end up in operations area and routing area, and so I try to go to those because it gives me a little bit of an overview of other things that might be coming along, work that might be happening.

And I talked last time about Transport Layer Security and how the new version, 1.3, is going to make it harder, actually it makes it impossible to actually look in the packets.

And there’s a lot of people that are really not comfortable with that because there’s banking regulations, there’s all sorts of debugging. There’s any number of reasons why you might want to be able to decrypt a packet.

And TLS 1.3 makes that – in essence, you can look at the header, but you can’t really look at the payload anymore.

So there’s a lot of documentation, a lot of work being done to try to figure out where we go from here. I mean, there’s the hardcore people that just want to do it. You don’t ever get to look in there – tough luck – and then there’s the people, well, I’d really like to be able to have the key so I could look in there. So we’ll see how that goes.

So network slicing, there’s a lot of work being done on network slicing. I’m not going to talk about it because I’m not sure it’s really super useful.

So here’s some more stuff that’s going on. There’s a lot of YANG models, which I think in our day they were called MIVs. But anyway, there’s some more stuff being done there.

Okay. So the routing area working group is again another one of these umbrella groups that’s all the routing stuff that isn’t in a working group. And usually all the talks are by one guy. There’s a lot of talks by one guy.

Okay. So this has been – I’ve talked about this at probably four or five of these talks now, this is the new multi-homing, v6 multi-homing draft. And it’s going to last call.

If you’re interested in how they think this is going to work and whether it cures the multi-homing issues, you should check it out because it’s almost a thing. Although, what was the other one? SHIM6 was a thing, but it never became a thing. So we’ll see.

This is, again, more about datacenters and their – this is about datacenters and hybrid networks. So maybe your datacenter, some of it is physically in the room, some of it is on the cloud and different things like that, and then how do you make it a cohesive datacenter?

It was kind of an interesting talk. Although they give you, like, four minutes for an hour-long talk. I’m not familiar with that at all. And so she got cut off.

So this guy, this is all about connecting air traffic with v6. And it was a fairly interesting talk. It’s a separate BGP overlay that they’re working on, and the planes will use it. And they’re not sure if it will connect to the global network or not. And the sub network you’re on depends on where the plane is. So that’s kind of interesting.

Let’s see. This is all about – so BCP 38 is the best practices document that says you should filter your customers’ routes because that helps with denial of service.

And BCP 84 is the best practices document that says this is what you do with that if you’re multi-homed, because just filtering at the edge if you’re multi-homed is not good.

So this is talking about how you do BCP 84 with the intent of making your routes asymmetric because of various policy reasons.

And that’s basically – I didn’t put the diagrams in because that would have been like 120 slides.

Okay. So network telemetry. This is basically the IETF sort of putting together all the documentation of what it’s doing in this space. These are some more things, linked state over Ethernet.

This is really funny. This woman, it was awesome, she got up, and there’s this whole presentation about linked state over Ethernet, she said why don’t you just use – what was it? – OSPF discovery, router discovery or something? And they all were like: Oh, maybe we could do that. I’m not sure if this draft is going to go anywhere, because, like, it’s already solved.

So, SIDR operations. So, in the beginning there was the SIDR working group, which was basically working on protocol. And now SIDR operations is, like, how do we deploy the protocol and how do we get it out there.

This was not popular. This is basically using a route server to do route validation. There was a big, big, long line at the microphone of Internet service providers saying, yeah, no.

Let’s see. Some of the Internet exchange providers are actually filtering invalid routes using the secure BGP now. And this is some stats on that, which is cool. It’s progress. Let’s see. And we don’t really want to have ROAs with multiple prefixes. They’ve written that down over and over again.

So this is another one of the things that I thought maybe we should have solved this already, but, okay, so you’ve got this BGP and you’ve got BGPsec and you’ve got the signed routes and you’ve got a more specific and you have an aggregate and maybe the more specific ones’s valid and ones’s not valid, how do you decide which route to choose.

I guess in my mind I thought this was already solved, but apparently it hasn’t been. So there’s a lot of discussion about what if the more specific makes the other one – I mean, what if one makes the other invalid, which what do you do? Do you just punt?

Like if the covering route is valid – or the more specific is valid and the covering route isn’t, then – anyway, I – it needs to be documented what you do in the cases with all the different failures with the signed routes.

Let’s see. So this, I thought I might have been losing my mind, but Andy Newton affirmed my belief. There was a big discussion in Singapore in this working group, and people were like yelling because the RIRs all have their own route to the RPKI, and it should be ICANN, and the RIRs apparently didn’t tell anybody.

It was like this really weird – but of course the RIRs have given presentations and documentation and there’s a reason why everybody has their own route to the tree.

But it was this huge argument about how bad we all are and how we didn’t tell anyone. So that was fun. I thought it was jet lag. Then I went and talked to Andy, and he said, “No, no, you’re right.” So go figure.

So this is about BGP origin validation in Colombia and what they’re doing and how many signature routes they have and that sort of thing. Pretty cool.

The ILA BoF. I was asked to go to this because it sounded like it pertained to addressing. I guess it kind of does.

Are you familiar with LISP? LISP was a protocol that you separate the location from the ID. It was a way to kind of fix destination-based routing, basically.

So the ILA protocol is basically LISP but it doesn’t use encapsulation, it just uses translation. But it has all the same problems. You have to have a database. Have to be able to map.

So I don’t know. But it really didn’t have much to do with addressing. So I watched it, and it’s the same guy who presented – he presents this – he made a new version of GRE, which is a tunneling protocol called GUE, G-U-E.

And it’s like why do we need another one? I don’t know. I was sitting in front of the guy who started and wrote the code for the first LISP stuff, and we had a good time.

Let’s see. INT Area is another one of these overarching group for the Internet area and maybe drafts that are not ready for a working group yet.

This is NAT – carrier-grade NAT and law enforcement, and this is all about what they need from – a lot of information gets hidden with the NAT, and so this is a document – this is a presentation all about how do you get law enforcement what they need when it’s behind a NAT.

And I was just complaining about the guy who wrote GUE and all these varying tunneling protocols. There are like 1500 RFCs that have tunnels in them.

And you get to the point where if you have that many standards, if you have that many standards that do the same thing, then you don’t really have a standard, because I could implement A and you could implement B and he could implement C, and you’re all implementing a standard, but they don’t interoperate.

So the IETF is constantly trying to figure out – it’s just like with all the DNS, all the things we’re putting in the DNS, how much more can you put in there, how many more tunneling protocols can you have?

I don’t know if it’s a solvable problem because people need to do what they need to do, but it makes it harder and harder to run a network.

Let’s see. And there’s some more drafts.

Okay. Operational Security is another working group I went to I think in London. So this document is security considerations for v6 networks. And it’s going to go to last call, so you might want to check that out.

And I just knew it, blockchain can really fix everything. So this was a talk about doing the whole RPKI and all that DNS stuff with blockchain, which I thought made me really happy somehow.

So pretty interesting exercise, but probably not going to happen at this point.

Let’s see. And, again, the TLS 1.3 and ability to be able to look into the packets spans multiple groups, so you hear about it multiple times.

Let’s see. Okay. Okay. So I went to the IRTF. So there’s the IETF, the Internet Engineering Task Force, and there’s the IRTF, the Internet Research Task Force.

And they’re parallel organizations, but the IRTF works on things that maybe aren’t ready to be an Internet standard yet, but forward thinking they write RFCs, but they’re informational; that that will hopefully become an Internet standard at some point or a protocol that we use on the network.

They’re talking about the Quantum Internet Research Group. And I’m having a hard time with the whole quantum Internet thing; maybe it’s because I’m not a physicist or whatever.

But I did find this quote. There’s no real definition of what it means. So we’ll see what comes out of the Quantum Internet Research Group, or maybe someone here can enlighten me. I don’t know.

So, again, I was on the committee that helped pick the winners for the Applied Network Research Prize. So the very first two papers that mentioned us were in the pool of probably 100 papers that were submitted, published papers that were submitted.

And these are two – every IETF there are a couple presentations of the winners, and these were two of the winners.

So the first one was all – she talked all about she did a whole bunch of research on video streaming and whether throughput is a bigger issue than latency.

A lot of really in-depth information using a number of different video services. And the Vroom one is all about speeding up the Web on your phone. And about every other thing he said, said, Well, and then that didn’t work. But he did have some things that worked. So pretty cool.

I was going to put this – I wasn’t even going to talk about this, but then I remembered. Okay, so I’ve talked about the human rights group a bunch. It’s all about human rights and Internet protocols, which was hard for me to get my brain around in the beginning.

But there’s a woman at the – this was Singapore, so in November. She took all the RFCs from the beginning of time until now and she looked them against the International Declaration of Human Rights. It was really interesting, like where does it mention human rights, how does she think they affect human rights.

She’s not an IETF person or anybody who would be in this room. So it was a really interesting take on where we are and where we need to go.

Her link is right there. And these are some of the other discussions that are going on in that group.

So I knew it wouldn’t be complete without footwear of the IETF. And I surreptitiously took these photos. And as he stands on the shoes, they change colors. So I had to time it just right to get all three colors while he was standing three feet away from me at the microphone. I just want you to know I did that just for you. I did.

(Applause.)

Cathy Aronson: He’s, I would say, probably in his 40s, and he has light-up shoes. But we won’t mention any names. And he’s a professor. So there you have it.

So these last groups I put as a complete exercise for the reader. And there’s some slides at the end because I went to these.

The first one is basically Industrial Internet of Things over v6. SecDispatch takes all the security stuff and figures out what to do with it that doesn’t have a working group. Another one of those umbrellas, and the other ones are, too.

So these are where you can get all of the different slides and tools and research and all that stuff. And if you’re looking something up and you can’t find it and you don’t know which IETF it was, just let me know. I’ve had that happen, and I’ve pointed, oh, that was in Singapore, that was in London.

If you’re going to your first IETF, talk to me. But also there’s a video that has someone that looks eerily like me in it. But it’s like a cartoon about how you should read stuff and not be offended when people are mean to you.

And there’s IETF Systers, which is a group of women who meet at the IETF. And if you go to NANOG or RIPE or any of the NOGs, there’s the netgrrls, if you’re a woman and you want to hook up with some women to get involved in the group, the society.

So that’s what I’ve got. Any questions?

John Curran: Any questions for Cathy?

Cathy Aronson: Thoughts or something you were there and you want to add more?

John Curran: No questions for Cathy. Excellent report. Thank you very much.

(Applause.)

John Curran: Several years back I said before we go do our own trust anchors, we should write it up as an Internet Draft and put it through the process, because they’ll forget that they told us it was okay. Turns out to be useful.

I think we’re going to have Richard come up – Richard? – and give the Customer Satisfaction Survey results.

Customer Satisfaction Survey Update

Richard Jimmerson: Thank you, John. Some of you may have seen earlier today, we actually released the Customer Satisfaction Survey results that we took in the fourth quarter of last year, in 2017.

We finished that up with our consultant, Rockbridge Associates, earlier this year. And I want to present to you some of the results that we found at least in a summary fashion here.

Alright. About the survey. Conducted in Q4 of 2017 by an independent contractor named Rockbridge Associates, the same organization that conducted the Customer Satisfaction Survey on your behalf back in 2014.

The objectives of the survey were to determine the members’ expectations and needs from ARIN, assess current satisfaction with ARIN’s services and operations, to determine any unmet needs members have, to identify and prioritize areas for improvement, and to understand how ARIN’s current performance compares to that indicated by the previous survey completed in 2014.

Now, if you want to look at the full report by Rockbridge Associates, that’s now available on ARIN.net. And you can browse there by going to About Us and look under the Corporate Documents title, and you’ll find the Customer Satisfaction Surveys there.

Now, one of the ways that Rockbridge Associates conducts their surveys is they create performance to expectation measurements. Rockbridge believes there are some survey takers that would not define perfect on a 1 to 10 scale as a 10.

So what they like to do is they like to ask the survey taker: What is a perfect score? What is excellent services to you? Is that an 8? Is that a 9? Is that a 10? And then alongside that ask the question: Okay, if you tell us a 9 is what we should be shooting for, how did we do? How do you rate us out of that 9? And that’s basically how they build the surveys.

Now, the survey takers will then grade ARIN’s performance against their own standard expectation markers using that method.

Now, what they advised to us back in 2014 and again at the beginning of this year, after the end of this survey, is they advised the following for performance to expectation gaps.

So if you tell us you expect a 9 but you tell us we’re performing at a 7, we’ve got a gap there. And so but really what it is, they mark it as a 90, and you mark us as a 70, and there’s a 20-point gap.

Now, what they’ve told us is in their rating system – and you’ll see a slide that follows this that explains it better, but anything where there’s more than a 10-point gap, they advise us that there’s a concentrated effort needed to remediate inside that space; anything that’s fewer than a 10-point gap they say is good for an organization like ARIN’s; and anything fewer than a 5-point gap they consider to be excellent in meeting expectations.

Now, when we took this, when we did this survey back in 2013, 2014, we had several major markers where we were more than 10 points away from expectation, and we’ve done a lot of work over the last couple of years to remediate that.

So this is what the scorecard looks like. What you’ll find as you go through the full survey is that the dotted-line area is actually what the community collectively said their expectation is. This is what our expectation is of the organization. And the colored line that goes with that that’s filled in by a color, that is where you actually rated us collectively as a community.

You can actually see going through this year’s survey result that they show you the comparison to 2014 in every marked area. So this is how we scored this time compared to 2014. And these major areas, you can see our points from expectation that we’re 10 points or more in nearly every area where we were graded by the community. And we’ve actually reduced or closed that gap in almost all of the areas – in all of the areas, actually, when it comes this the overall performance.

But when you actually dig into each of these areas in the full survey, you’ll find in some areas perhaps the gap grew a little bit, but in the overall performance we made some significant improvements over the last couple of years. But we still have a lot of work to do inside the organization to close those gaps even more.

At the beginning of this survey, they asked some general questions. They want to know how satisfied in general you are with the organization meeting your needs. They’d like to know if you’re satisfied with the fees or not that you pay to the organization for the services that you receive.

And they get asked – the survey takers get asked the question: If you’re able to choose another registry services provider, how likely would you be to stay with ARIN or go to another registry services provider.

You can see those markers changed a little bit, too, over the last couple of years. In 2014 over a general satisfaction, about 93 percent of the organizations were satisfied with ARIN, and this time that number grew a little bit in the highly satisfied area. But when it comes to the dissatisfied customers, that stayed steady at about 7 percent for the survey takers.

For the fees, you can see there was a similar type change, but not as much. And with likelihood to continue using ARIN’s services, we actually improved in that area from where there were 13 percent last time that were not likely, and this time there were 9 percent that would not be likely to continue using ARIN’s services if they had a choice.

Now, what we’re going to do in our future survey – we plan to do this survey again – and we’re going to make some changes next time. So we got some feedback this time in the survey. We’re going to look to conduct a similar survey in approximately two years. But we’re going to provide two options for the survey next time.

Feedback was the survey is too long. We were trying our best to make sure for benchmarking purposes that the survey was – is near exact the same as it was last time so we can see how we improved or didn’t improve over the period of the last three years.

But the next time we do this survey, you’re going to be given the option at the beginning of the survey to either take a short survey that will be five minutes or less, or if you’re interested in providing more detail, you could take a longer survey that would be approximately 15 minutes. And they will be able to give us results based on those two different types of surveys that people might take.

Between the larger surveys, we will continue to conduct transaction surveys and collect feedback through our regular channels. We have the feedback button. We’ve got customer contacts over the telephone, via email and inside of our tickets, in the ARIN portal, and et cetera. We’ll continue to measure that and do those markers between the surveys.

And we do want you to know that you have our continued commitment to make improvements in those areas. In the ARIN organization, as staff, you are the number one priority for us, and we’re constantly working and striving to find better ways to improve our services.

We value your feedback as the customers of ARIN. It is a key element to our decision-making process, and we can’t function properly as a registry without receiving that feedback.

Every week where we sit down and we have meetings about decisions on how we’re going to move forward with certain areas of work, we always consider the feedback that’s being received from the customers, in these surveys, in the telephone calls, inside the tickets. And it guides us. It helps drive decisions on how we’re going to make improvements or do the job better for you.

Please continue to provide that. And we’ll use this survey result and other feedback, like I said, to continue making improvements over the next few years.

So thank you, and I’m happy to answer any questions you might have.

John Curran: Any questions for Richard? Thank you, Richard.

(Applause.)

John Curran: Okay, we’ve got one more presentation for today, and it’s regarding one of our open consultations. I’ll be doing the presentation. It’s the Address Supporting Organization Review Consultation.

Address Supporting Organization Review Consultation

John Curran: So let me introduce this. The most recent ASO Review concluded with 18 recommendations. ASO Review. So the ASO Review is the ASO, Address Supporting Organization, within ICANN per agreement with ICANN.

The Address Supporting Organization conducts its own periodic review of how it’s performing: Does it serve a role within the ICANN structure, and how efficiently does it handle that role.

Our last review was in 2013. So it’s timely. We just completed a review this year. And it very much is a review focused on the NRO number registry as the ASO within ICANN. And so it deals with how we interact with other organizations.

The review was done throughout the course of this year. There were surveys done at ARIN meetings and all the other RIRs. The review report was put out.

When the final report came down, it had 18 recommendations, 17 of which were very straightforward, talking about predominantly cleaning up how we communicate, how we operate, procedural issues. And all of those were things that the NRO, the NRO Number Council and the NRO EC, could accept and move ahead with, which we did.

The 18th recommendation is the NRO should initiate a public consultation involving the five RIR communities to determine the future structure of the ASO.

This one’s a little more complicated. We did decide to accept the recommendation, and we did launch at the NRO level a consultation on the issues identified in the ASO Review report. You can get a copy of the review report at this URL.

So each RIR has got its own process for doing its portion of this consultation. Overall, we all have the same scope.

It includes the structural implications of the issues in the ASO Review, and here are some of the issues that came up: Any updates or adjustments identified as required for ASO Review documents. Some cases the documents haven’t been updated. Some cases they may have processes that aren’t efficient.

Reported confusion of roles between the ASO and the NRO. As people may be aware, the NRO, the five RIRs working together is referred to as the ASO in the ICANN context. Perceived complexity of the relationships among NRO, ASO and ICANN.

Relevance and cost to the RIRs of varies ICANN engagement activities. When we send people and participate in activities, there’s a cost. That cost ultimately is borne by the NRO which allocates it, as Paul said earlier, among the five RIRs, which means it’s a cost to you. As long as it’s a good cost and it’s valuable for what we get, that’s useful.

So ARIN, the NRO EC, looking at the list of scope, posed some questions: What adjustments should be made in order to address the issues highlighted above? Should adjustments be limited to the NRO MoU, the ASO MoU, and/or the ICANN bylaws? Over what timeframe should these adjustments be developed or implemented? And what strategic aspects should we pay attention when considering these adjustments?

ARIN issued a community consultation on the structural issues identified in the ASO Review report. Our consultation is online there. It closes on the 30th of April, which means you’ve got another two weeks.

Presently there’s only two comments made on our consultation, both to the effect that the ASO is unnecessary as the primary role of the ASO forwarding global policy proposals for ratification to the ICANN Board is an extremely rare occurrence. We don’t have any other feedback.

So that’s what we need to address, because all five RIRs need to do consultation with their community. We’re going to need to figure out how to come up with an overall plan in order to have the RIR community move forward with one voice on how to deal with the ASO.

Additional input would be helpful. You can join in the consultation list. We take all these matters that aren’t policy matters and we run them as suggestions or consultations on the consultation list.

It’s open to anyone. You don’t have to be an ARIN member. So feel free to join in and tell us what you think. Or approach the microphones now. Microphones are now open.

Yes.

Owen DeLong: Owen DeLong, concerned Internet citizen. I admit I’m not an expert on the post transition structures. And if anybody else understands them, good for you. Please explain them to me.

But my limited understanding is that there’s this organization, the NRO, which is essentially the five RIRs acting in concert, which contracts with this organization called ICANN, which is the legacy domain name management organization that also likes having a contract to do number things, which then spun off a subsidiary called Public Technical Identifiers, or Post-Transition IANA, depending on who you ask, that they subcontract all the things that we pay ICANN as the NRO to do on behalf of the NRO to PTI.

Why not cut out the middleman, get out of ICANN and just have the NRO contract with PTI, sever PTI from ICANN and move on?

John Curran: So I’m going to answer your question, and I’m going to do it first by explaining a very important detail.

So a few years ago we did the IANA Stewardship Transition. And in the process of doing the IANA Stewardship Transition, instead of having US government NTIA contract with ICANN for ICANN to be the IANA Numbering Services operator, the operator of the IANA central numbering registries, we, the RIRs, collectively now contract for that service with ICANN.

Okay. Now, that was the transition of the operational function of keeping track of the central unallocated registries. And the reason we contracted with ICANN is because NTIA originally contracted with ICANN.

At the last minute – not the last minute – when the names community got around to doing its plan, it wanted ICANN to contract with the party administering these registries. Because ICANN was also the party administering these registries, it created an affiliate to make sure that the names community could have ICANN contracting with ICANN.

Now, we are still contracting with ICANN. The affiliate is called PTI. We didn’t bother to contract with PTI because PTI has no money, PTI has no skin in the game if it fails to deliver. PTI could be dissolved tomorrow and no one could sue it for failing to deliver.

ICANN has people, staff, operations, financial reserves. It’s a more proven organization than the shell that is PTI. Because PTI, if it failed to deliver, there’s nothing there other than what ICANN put into that model.

We could transfer our contract directly to PTI. However, none of that is what the ASO consultation is about.

So the ASO Review was talking about the structure by which the five RIRs come together, and our Number Council, which is called the ASO AC in ICANN land, works within ICANN to work on global policy and occasionally send them to the ICANN Board for ratification – there hasn’t been one in five years, I don’t think – and participate in all the other ICANN activities like appointing two directors to the ICANN Board and participating in the consultations and working groups within ICANN that are available to all the supporting organizations and advisory groups.

So it’s just this structure that we have for harmonization of global policy and its role with ICANN that the consultation about. None of this affects the SLA operator. We could continue to use ICANN with our Service Level Agreement for the IANA. We could contract to another party when that’s up for renewal, contract – none of that would change the relationship we have, the ASO relationship, with ICANN, which is about global policy development and ICANN ratification of same.

So that relationship, just talking about global policy and the ASO working at ICANN to do global policy development and participating in the other ICANN activities like appointment of the ICANN Board, all the things Paul had in the NRO report, that’s what we’re talking about on the consultation.

Help?

Owen DeLong: Yes and no.

John Curran: Without having M.C. Escher here to, like, draw it on a chart with three dimensions and lines, it’s the best I can do.

Owen DeLong: And it is quite Escher-esque. Which way are the geese flying?

So what I’m getting at is the existence of the ASO as an organization within ICANN is necessitated by the fact that we’re contracting with ICANN to contract with this, quote/unquote, shell.

John Curran: Different relations. Completely separate relations. If we’re having this conversation five years from now, we could have – we could have – could have KC Claffy in CAIDA doing the IANA number operator. We’d still have an ASO with ICANN. We’d still be having this discussion.

The operator of the number registries is not what we’re talking about. We’re talking about the fact that we have an ASO, a supporting organization in ICANN, which serves to work on global policy and appoint ICANN Board members.

Owen DeLong: Right. And that doesn’t move to the operator of the number –

John Curran: Not at all. The operator uses whatever global policies there are. For us, they use whatever IETF RFCs there are. IETF, for example, has no relationship with ICANN for global policy development, but it still has global registries that the IANA operates.

Owen DeLong: Understood.

John Curran: We use ICANN to do the review and ratification of our global Policy Development Process, and we use ICANN where we, through the ASO, participate in all the other activities and where we appoint two board members to the ICANN Board.

Owen DeLong: All of which to me seems like it’s necessary because they’re operating the numbers registry.

John Curran: Completely independent fact. We could move the numbers registry contracts when it comes up for renewal, could be moved if that’s what the community wanted, could be renewed with them if that’s what they wanted, could be switched to PTI, their subsidiary, if that’s what the community wanted.

Owen DeLong: Okay. Am I the only one in the room that thinks this makes no sense; that these things are completely separate and that if we moved the number registry off into this other organization, it would continue to be governed by what the ICANN Board ratifies?

John Curran: The number registry was being done not by us, but being done under contract with NTIA, okay, to ICANN. So they could have contracted it to someone else as well, and we wouldn’t have had any control over that either.

Owen DeLong: Understood.

John Curran: So what do you want your ASO relationship is the question on the consultation.

Owen DeLong: I think having the ASO continue to appoint ICANN Board members and continue dealing with global policy, such as it is. I think the last one was the last five /8s.

John Curran: We might have done a residual after that, remember? Take them all together –

Owen DeLong: The distribution of the IANA –

John Curran: – make Spam, slice it up, give it back.

Owen DeLong: The dribbling out of what stuck in the IANA registry –

John Curran: Actually, that’s really scrapple, is what they made. It wasn’t Spam.

Owen DeLong: Yeah, the IPv4 scrapple policy was the last one. You are correct.

John Curran: Okay. So your thoughts on where we should go with the ASO.

Owen DeLong: My thoughts are we should definitely avoid the ASO getting involved in mission creep and expanding its tentacles further into miscellaneous ICANN processes, most of which don’t affect us.

We should shy away from ICANN paying additional attention to what we’re doing as ICANN looks for further mission creep to spend money on, since they have too much, and just try and avoid that, becoming any more complex than it already is.

Kevin Blumberg: Kevin Blumberg as – affiliation of this is myself as a volunteer. I will declare I am one of the vice chairs of the ASO AC, to help everybody there.

There’s 17 other recommendations which basically say make things easier for the communities to understand. Stop with the mission creep. Clean things up. Take 20-year-old documents and revise them.

There’s a lot of good, solid work there that will make it easier for, A, the community to understand and, B, for the volunteers to not get dragged into things that they don’t need to be and they shouldn’t be.

The majority of the policy work for ICANN – all of the work at ICANN is domain policy, all related around domains. We’re numbers. We do our policy work here. We don’t need to be diving into that. We don’t need to be creeped into those types of things.

I think my personal view is when we talk about timelines and you talk about that list you had there, John, I would like to see an effective cleanup of the responsibilities.

I would like to see it done over time. I don’t want to see us torpedo out, out of frustration, a relationship that we’ve had for many years. I want to see us doing more consistent, simplified workloads that are related to the numbers community.

Which is just saying unfortunately no to a lot of the requests which they’re asking out of commitment and out of nicety but that I don’t have time as a volunteer in the given years to deal with.

But I believe it’s an important relationship. I think that there’s an important credibility between, and it’s good to be part of the ecosystem. How attached we are to the ecosystem is a different issue in this to me.

But I think I don’t want to, like I said, throw out – because I’ve seen some of those things, I don’t want to throw out the relationship, go somewhere completely different out of frustration, when we’ve got a pack of 17 things to clean up. That’s my high-level view of this.

John Curran: Maintain and clean up the existing relationship.

Kevin Blumberg: At the next review, which is going to be in four and a quarter years now, if there hasn’t been that cleanup and it hasn’t happened, then we know going into it that that’s going to be the expectation.

John Curran: Excellent. Front microphone? I was looking for a remote or –

Alison Wood: Remote. Jason Schiller, ASO AC. The ICANN Board of Directors ratifying global policy necessitates the ASO AC shepherding global policy. Interfacing with the ICANN Board of Directors would ratify a global WRT ratification of global policy and oversight of the ICANN board of directors WRT ratification of global policy.

As such, this needs to be completed with the ICANN system which results in a lot of ICANN work, which is not germane to the numbers community because ICANN treats the ASO like any other supporting organization.

To do what Owen suggests, continued participation with ICANN and no mission creep, requires ICANN to recognize that we are not a regular supporting organization; that policy development, transparency diversity, et cetera, happens in the RIR system.

John Curran: Very good. Front microphone.

David Farmer: David Farmer, University of Minnesota. So this is about the structure. So my comments on the structure is that the ASO/NRO structure makes no sense to laymen and only confuses people and, heck, even confuses people that kind of know what’s going on.

So from a structure perspective, I’d like to see that simplified.

John Curran: Okay. At a high level, if every time we say ASO we say NRO, and every time we say ASO AC we say NRO Number Council, then everything sounds a little simpler but nobody has changed roles.

The NRO participates in ICANN, the NRO Number Council as the ASO AC currently works on global policy ratification, appoints Board members, and gets invited to many other ICANN things because it’s a supporting organization.

David Farmer: And I think we’re just getting wrapped around the axel with names of things. But it proves that names are important.

John Curran: Earlier speaker said they’d maintain the relationship but go to simplify. Is that what you’re saying, but also make sure you simplify the names?

David Farmer: I think so. Because the two names or the interchangeable names just adds to the confusion and the complexity and makes it seem harder than it is, actually, I think.

John Curran: The fact you’re worried about the names used in the relationship means you want to keep the relationship or you wouldn’t be worried about them.

David Farmer: I believe so.

John Curran: Very good. That’s what I’m checking, trying to make sure I understand what you’re saying.

David Farmer: Let’s put it this way. To me simplifying it is the important thing. I don’t particularly want to eliminate any of the relationships. But if the only way to simplify it was to eliminate some of the relationships, then abandon some of the relationships.

John Curran: Got it. Okay. Very good. Microphones remain open. This is the structure of the RIRs interacting with ICANN as the ASO. It affects all of us and, I’ve only seen a few people at the microphone. I see someone approaching.

Alyssa Moore: Alyssa Moore with Cybera, ARIN AC. I don’t think it needs to be eliminated entirely, but it needs to be cleaned up. And volunteers don’t need to be dragged into all the Address Supporting Organization work that they are currently dragged into because it does not apply to us.

Whether that means that we just call it the NRO NC and they exist in some new capacity with a relationship with ICANN, I don’t know if we need to appoint Board seats, if that’s something that this community still wants.

But those are my thoughts on it. And they’re on the consultation list.

John Curran: Thank you. Any other comments? Remote comments. Up front. Yes, microphone.

Owen DeLong: Owen DeLong. I’ll take one more crack at – Jason refers to normal supporting organizations versus the ASO. Correct me if I’m wrong, the other two supporting organizations are the global name supporting organization and the country code name supporting organization, and that’s it.

John Curran: Correct.

Owen DeLong: So referring to the other two as, quote, normal supporting organizations versus us as the Address Supporting Organization strikes me as a little bit odd. They’re all three odd ducks in their own respect in each case.

John Curran: Let me elaborate. So the SOs are also referred to commonly in the phrase SO/AC, as in Supporting Organization, slash, Advisory Council.

And there’s a bunch of ACs. ALAC, the At-Large Community. Just you can find – the GAC is another one.

And so when you take those collectively, ICANN has many what they refer to as constituencies, and many of the ICANN processes are cross-community in nature that involve all the constituencies, because you would not hold an engagement on some topic and leave one out. They would be: You left me out. I’m slighted. How horrible.

So when there’s a discussion about international character sets and domain names and there’s a cross-community working group on it, all the SO ACs get invited. When there’s a discussion about ICANN staff accountability, all – and it’s cross-community working group on that, all the SOs and ACs get invited.

This means that while we may be one of three SOs and ACs, we are also the only – the only – maybe one of three SOs, we are also the only party in the list of all the SOs in ACs that work on number policy, not name policy. And in that way we are sort of the odd duck out, how everyone considers an SO or AC.

I’m just giving you the perspective from within ICANN. And you can read the review report and get more color on that.

Owen DeLong: I have read the review report, believe it or not. And one would potentially argue that the GAC may have some interest in numbers policy since they’ve certainly expressed opinions on Whois in multiple forms as it relates to numbers.

We’ve got the Public Safety Working Group of the GAC telling us more Whois, more Whois, and we’ve got the EU wackos in GDPR land saying less Whois, less Whois. It’s always so wonderful to get such clear direction from the GAC.

John Curran: Just to clarify one little thing. We actually do a lot with ICANN. For example, we do occasionally present in front of the GAC. We do work occasionally with, you know, like the Internet Health Identifier Initiative that Paul talked about where they’re trying to measure how current and accurate are the registries. As RIRs, we’re all participating in that.

We don’t need to be an SO or AC to participate or engage with ICANN. The IETF participates in many of those same activities as well, and it’s participating as, quote, the IETF, quote. They don’t have an alternate name in ICANN land.

So this is a question of what should our relationship be with ICANN. Should we be doing anything with them, all these things. How should the ASO evolve to cover that.

And it’s not necessarily the case, one way or another, that changing the ASO means less or more engagement. If you’re proposing changing the ASO structure and you specifically mean do less with ICANN, you need to say that because we still do a lot of things with ICANN.

Owen DeLong: I’m not sure I want to curtail any of the things we’re doing with ICANN as long as this odd three-way structure remains in place necessarily. I could see wanting to eventually render ICANN an irrelevant party in that and having it become a two-way structure.

And at that point it becomes questionable whether there is a need to maintain that involvement in ICANN, but that’s obviously not directly related at this time.

But for now I think we need to continue the current level of engagement with ICANN. I think we need to avoid scope creep.

The three things I’m most concerned that we continue to involve ourselves in with ICANN is we should, through the ASO, continue to pay attention to how ICANN spends money, since we contribute some fraction of the ICANN budget. I realize not a significant fraction from ICANN’s perspective, but certainly significant from the RIR perspective in terms of where it falls on our balance sheet.

We should continue to engage on global policy as applies to number resources, and we should continue to appoint Board members because, well, that’s one of our primary ways to try and twist screws on ICANN both absorbing large quantities of money they don’t know what to do with and then coming up with creative ways to foul up what they then do with that money.

John Curran: Can I ask a question about your first? The second two are perfectly understandable. The first one, which is pay attention to how ICANN spends money, it’s interesting. We’ve been contributing the same amount to ICANN since inception. The total amount is $823,000.

Two years ago, with the IANA Stewardship Transition, we specifically identified $675,000 and said: This is for the IANA, this is for the SLA operations, SLA, Service Level Agreement, for the IANA Numbering Services. The rest is our ASO contribution. So instead of contributing $823,000 per year, we’re contributing just 140 some-odd per year, and 675 is for the IANA.

We don’t pay a lot of attention to how ICANN spends money, because ICANN has many, many people paying attention to it, many, many meetings paying attention to it that go on for many, many months. There’s a whole process that’s multi-year on ICANN priorities and budget that’s done with the community.

We would have to spend money to staff that process of monitoring that. And I guess I’m wondering is that what you want us to do. Because historically ARIN has said no, we should not pay attention to how ICANN spends money, we just shouldn’t let them have more.

Owen DeLong: That works.

John Curran: I want to be clear. If that’s not what we should be doing, you need to be very clear.

Owen DeLong: I think for now that works. I think it might be nice to pay some attention, for example, to what they’re doing with the gTLD “make money fast” slush fund, because there’s some very creative and destructive proposals in that.

John Curran: And I want to be clear: We can do that. But when ARIN’s there, when we have representatives like Kevin and Louie Lee and Jason, they don’t have a portfolio from this community on what to say in that discussion.

We have not had an ARIN community process for them to have a voice to say the ARIN community believes this about the gTLD slush fund activities.

So we actually tell them don’t speak, because we don’t know who you’re speaking on behalf of. It’s not this community, because I haven’t done an engagement. Are you saying they should be?

Owen DeLong: I’m saying we should perhaps –

John Curran: We should hold consultations on –

Owen DeLong: – attempt to get some engagement on that, yes.

John Curran: This community should have meetings to discuss our positions on ICANN DNS matters.

Owen DeLong: I don’t know it needs to be meetings so much as we have the ARIN consult list and: This is going on at ICANN. If you have an opinion, you may wish to provide guidance to the ASO AC who represents you at ICANN for this purpose.

John Curran: Got it. I just want to – perspective, Owen. ICANN has at any given moment several dozen consultations open. We would need to add staff to engage the ARIN consult list to get your positions to engage with the other RIRs to take a view which represents the community to ICANN.

Are you willing to fund the additional staff?

Owen DeLong: I’m not necessarily in favor of adding staff for this purpose.

John Curran: Well, it’s a lot of staff. I want to be clear. You’re talking about engaging with an organization –

Owen DeLong: You’re assuming an “all or nothing” on this –

John Curran: That’s what I’m asking. How do we know –

Owen DeLong: – and I’m saying that I believe that the ARIN staff that’s currently engaged in ICANN processes is perfectly capable of knowing which consultations may be of interest to this community above the normal threshold of “let the community figure it out for themselves” and perfectly capable of bringing those I would estimate one to three per year to the ARIN-consult Mailing List, without adding additional staff.

John Curran: Got it. Back microphone.

Kevin Blumberg: Kevin Blumberg. That doesn’t represent the community when I’m at an ICANN, because I don’t speak. I haven’t been given that ability. And I’m fine with that.

I am there in this case appointed by the ARIN Board with a very specific purpose. Global policy comes along, do what I’m supposed to do in the procedures list. Don’t have the right procedures? Make sure the procedures exist. Board members, we’ve got two of them to appoint. Take care of that.

I’m not there as a representative of the ARIN community, because there’s 20,000 community members, and I haven’t been given any speaking ability in that regard, and I wouldn’t want it.

What I can say is, Owen, that doing nothing is a lot of work in the ICANN community. You’re asking for a little bit of something, which is a huge amount of work.

And this is my own feedback. I am unbelievably – I have no idea the amount of work that goes in, in the planning. I realize that being part of a global organization has more to it. But expanding in any way, shape, or form the scope doesn’t creep a little bit; it is a downhill luge of work.

So when I say “clean up,” it’s focus on the numbers. We are going there for the numbers community, and that’s all I want to be dealing with.

John Curran: Just for clarity. So I have authority to speak on behalf of all of you. You didn’t realize that. Scary. Very scary.

And I do on occasion. But only to the extent that what ICANN is doing may endanger our mission. Okay? I’ll speak at any organization that’s doing something that interferes with our mission as an Internet Number Registry System participant. But that’s it. And that generally doesn’t go into consultations about names, name policy, fees, you know, new gTLDs or anything like that.

So I just want to let you know: If you think I’m there representing what Owen thinks about name policy, I’m very sorry. I am there making sure that nothing they do would impact our ability to carry our mission. If that helps clarify.

Back microphone.

Dmitry Burkov: John, thank you. Dmitry Burkov, just from the net. I don’t want to estimate all this review and so on. I want to remind you that we began this game with this organization that’s known as ICANN. From different point of view, we decided to support our friends. Some of our friends who were protocol support organization decided to go ICANN around their own way. And I think they were right.

Unfortunately, we are still involved in this game. We created (indiscernible) structure. Sorry, people, it’s – this structure became more stronger through the years, just a reminder, our Number Council and Address Council.

What I expect from this review, because it was a moment when we can change and to minimize our relationship, don’t be involved in this new game, this new bureaucracy, with new lawyers, with new expenses, because we will be involved, we will support any step.

And practically, practically, especially after discussion with the meeting, I began to think that why we have so much Number Council.

John Curran: Okay.

Dmitry Burkov: It looks – it should be pretty covered, because it looks for representative, for context for ICANN, for us it will be now five here who are eliminated by Boards and five Number Councils who elected by community.

I think it’s enough.

John Curran: Understood.

Dmitry Burkov: That’s my vision.

John Curran: Thank you.

I’m going to start closing the mics on this. So last chance. Remote participants? Local people? Last chance, last call.

Microphones are now closed. I’d like to thank everyone for participation.

I am going to do two things. I’m going to attempt to write up this discussion, the high points, and I will post it to ARIN-consult, but I’m going to get it wrong. So I’m going to tell you now: I’m going to get it wrong.

And if you have strong views, you should take the opportunity to express them directly on ARIN-consult, because I almost certainly won’t get them reflected when I try to do a summary of the room.

Please, you have two more weeks, and then we’re going to have to explain to the other RIRs what our position is. The ARIN Board will – I’ll write something, the ARIN Board will look it over help me edit it, and then that will be the numbers community position from the ARIN region.

Eventually we’re going to have to try to get all five RIR communities on the same page, and that will be an exciting process. We need to figure out how that will happen.

But it first starts with us forming one here. So I will write a summary of today’s discussion. I also expect anyone who has strong views to make those views individually known so that they’re not omitted when we try to summarize the whole thing.

Okay. That concludes the consultation.

David Farmer: David Farmer, University of Minnesota. The consultations going on in the other RIRs, is there – I could – it would be helpful for me to know what they’re talking about, just thinking about it.

John Curran: Sure. So in a perfect world, with unicorns and rainbows, this would all be happening at the same time and we would all end up pointing at the same direction.

It’s apparent that’s not happening coming out of the gate. So there will be a chance to take the results of each of the RIRs when each RIR has results, and we will cross-pollinate.

But we have to wait because APNIC started before us, they’re a little ahead for what their community was talking about. RIPE is going to be starting this and moving – it’s a work in progress.

Right now I wouldn’t want to try to summarize what’s going on in other communities because we don’t know where they’re going to end up.

David Farmer: I think more what I was trying to get at is it would be unfortunate for the end of the process to be we’ve all done our separate things and we haven’t done anything to mush them together.

John Curran: No, no. So we were hoping that maybe everyone would converge on initial – like strawman. That’s not happening. So we’re going to go to initial positions, and that will be the start of a process.

It might be the start of a process where the five RIRs and the NRO EC can sit down and say this is the sweet spot. It may be a process where we’re so far away we go, okay, we’ve got a community effort, like we did with the CRISP team, to draft one. We don’t know because we don’t know where the five – but those five will be initial positions of a potentially lengthy process.

They may be closer than – who knows, they could be close –

David Farmer: One could hope they’ll be close –

John Curran: One could hope. But we wanted to have them hopefully all come out of the gate looking the same way, and the communities are in significantly different places. Okay?

Yes. Owen.

Owen DeLong: I apologize for coming up after, but it’s a response to what you just said. If we’re going to spin up something like the CRISP team, can we try and find a way to pay for it out of one of the various IANA slush funds instead of the RIR budget this time?

John Curran: Interesting thought. Okay. I will take that back to the other RIRs. We can always give them less. The contribution for the ASO is a voluntary contribution. It’s been the same since the very beginning, minus what we just changed for IANA operations. The remainder is the same.

It is a little harsh to say this year we’re giving you less because we’re thinking about our long-term relationship with you. You might want to think about the messaging of that. But that’s effectively what you’d be saying.

I would not expect to be able to give them the same amount and have them pay for it out of one of their funds because they have a multi-year budget process. We would have had to start two years ago to have that come out the other side.

Okay? Does that make any sense? Okay.

Alright. The consultation is closed, and we’ve come to the end of the day. I will now wrap up.

Public Policy Meeting, Day 1 - Closing Announcements and Adjournment

John Curran: First, thanks to our sponsors, Webpass from Google Fiber, and Google.

(Applause.)

John Curran: We have a social tonight. So it’s at Ball & Chain Miami, and it’s 7 to 11. Your badge, your social badge will get you in. There’s shuttles at the front of the hotel, 6:45 and 7:00 and 7:15, and returns will be beginning at 8:30 coming back.

There’s going to be a whole bunch of stuff. It’s a wonderful bar/lounge. Dominos, cigar rolling, salsa band, Cuban food, DJ. Should be a blast.

Reminders. Tomorrow, breakfast, 8 AM. Public Policy and Members Meeting opens at 9:00. You have all the materials.

Take everything with you. This room is going to be unlocked. Look forward to seeing you all tonight or tomorrow. Thank you.

(Meeting adjourned at 5:03 PM)

Network Sponsor

Webcast Sponsor