ARIN 39 Public Policy Meeting, Day 1 Transcript - Monday, 3 April 2017 [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.

For an executive summary of Day 1 of the meeting, read the daily digest on the TeamARIN website.

Public Policy Meeting, Day 1 - Opening Announcements

John Curran: Welcome to New Orleans. I’m John Curran, President and CEO of ARIN. I’d like to welcome you to the ARIN 39 Public Policy and Members Meeting.

Okay. This is where we spend a couple of days talking about policy and then a day talking about how the organization’s running.

Up here this morning I have a number of people I’ll introduce, but let me first say who is here overall.

We have our Board of Trustees here: Chair Paul Andersen; myself; Tim Denton, somewhere in the room.

Patrick Gilmore is coming. Aaron Hughes. Wow. Merike, I said it 20 times last night. Merike, where are you? I apologize, I blank on names. Bill and Bill – Bill Sandiford and Bill Woodcock.

Okay. Our Advisory Council is here, led by Dan Alexander, the Chair. We have Owen, Andrew, Dave Farmer, Dave Huberman, Alyssa, Tina, Amy, Joe, Leif, R.S., John Springer, Chris, oh, not Leif, Leif. Thank you. I saw you rise afterwards. I’m going to do that for five years, too.

Alison and Chris. So all are here. From the NRO Number Council – the NRO Number Council works on global policy issues – Kevin Blumberg, Louis Lee, and Jason Schiller. It’s Louie Lee, by the way. I’ve said that a hundred times.

I’d actually do great if I didn’t look at the slides and just did it from memory. From AFRINIC, we have our colleagues, Alan, Ernest, Arthur, and Bope.

APNIC, Geoff Huston I saw. Craig, I saw earlier. And Rajesh, yes, very nice.

LACNIC, I’m never going to get this one. Gianina. And Oscar’s here. Thank you, Oscar.

From RIPE. Dmitry, Andrew, Hans, Nick, Richard, Axel, and Marco. Very good.

The ARIN management team is here, obviously, myself. The person who does all the work, Nate Davis, over there.

Cathy Handley, who handles our government affairs, Richard Jimmerson, our CIO. Erin Alligood, the wonderful HR and administration person who keeps us straight.

Susan Hamlin. Where’s Susan? Susan is the one who runs the meeting, owns the meeting, makes it a success. Susan Hamlin.

Mark Kosters, our CTO. Yes, Mark. Leslie Nobile, who’s Director of Global Registry Knowledge, working for me. We’ll actually see some reports from her later.

John Sweeting, our latest addition, Senior Director of Registration Services, running the RSD team.

And Val Winkelman, very important, Director of Financial Services.

We have an ARIN Fellowship Program, and we have a number of Fellows who are here, and that’s from each of the subsectors within the ARIN region.

From Canada, we have Nancy Carter. Where are you, Nancy? There we go, very nice. Andre Dalle. Andre? Yes. Yes. In back.

Patrick Lalonde. Yes. Patrick. Very good. Thank you. And Michael Lerer. Very nice.

In the Caribbean, from the Caribbean sector, we have Jason, where is Jason? I’ve seen you. Yes.

Roxanne John from the Ministry at Saint Vincent. Brent McIntosh. And Kerrie-Ann Richards. Hello, very nice.

And from the U.S.A., we have Jose. Where are you, Jose? Yes, very good. Susannah Gray from the Internet Society SF. Hello, Susannah. Austin. Austin, yes. Joseph Olivieri. Joseph. He’s here. Alfredo, I saw you yesterday. Yes. Craig Thompson and Kelvin Watkins.

Our Fellows come to learn about what’s going on, bring information back to their communities. We consider it a very successful program within ARIN. We also have here a number of people, some of them in meetings, some are here from ICANN’s North American region at large, NARALO.

And we have an MoU with NARALO, which allows us to work together on Internet number resource policy development. Basically, we inform them when we have policy development matters going on. They let their community know, and they bring more people into the ARIN participation, people who are interested.

If you’re interested in number policy, you might hear about it through NARALO. Come give views on number resource policy changes.

They’re holding their general assembly this week on Wednesday. And, Glenn, are you here? Glenn is the Chair of NARALO. Yes. And they will – they’ll be in and out throughout the day. So if you see someone with an NARALO badge, please welcome them.

Newcomer, we had newcomer orientation yesterday where people met with the ARIN staff, got an overview of the organization, got to meet some of the other newcomers in the room. They learned about ARIN.

We always do a prize drawing for the people who show up for the newcomer orientation. For those people who filled out the survey, we will now draw from all the surveys and give out a gift certificate for people who filled them out, for someone who filled it out.

I need someone to reach in here and grab one. Owen, come on up here. I always grab someone at random to come up. Not saying it’s a good random function, but it is random. I guess I should switch it up someday, otherwise someone will eventually learn that Owen’s the picker and he’ll have free drinks and hot dogs.

Okay. The winner, Allan Skuce. Did I say – Skuce. Very nice. Allan, we’re going to mail you a gift certificate. We thank the people filling out the surveys, the newcomer orientation survey. It helps us focus it, and we will send you a gift certificate. Thank you for filling that out.

I also have one other little thing. I guess yesterday – we’re going to give out another prize. This is a Dell power supply. If you have a Dell laptop and you were in the newcomer orientation and you don’t have a power supply anymore, you can come up now or come up later and pick it up. I have it here.

Paul Andersen: It will be on eBay by 5:00 PM.

John Curran: Exactly. Okay. So we also have remote participants. So we webcast the entire proceedings so everyone can see what’s going on here. We also have a live transcript. We also have downloadable meeting materials, so people have the same materials as your handout. They have chat rooms where they can raise their virtual hand, ask questions and have as full of participation as possible as if they were here.

We do have people who participate in the ARIN process entirely remotely, have never been to a meeting. So if you can’t make it here, feel free to participate remotely and help shape the policy.

Attendance. So our attendance stats: From Canada, 29; United States, 110; remote participants, 21; Caribbean, nine; and 23 from outside the ARIN region.

Emergency procedures. Wow. Well, there’s an exit over there. And if there’s a problem, you go out the exit and apparently you go to the corner of Freeman Street and Fountain Place. I imagine, this being New Orleans, there’s a bar on the corner of Freeman Street and Fountain Place. But I haven’t checked, so you’re on your own.

We’d like to thank our sponsors. So, first, the network connectivity. Network connectivity is very important. We need to thank our sponsor. So let’s give a big round of applause for Cox.

(Applause.)

The webcast from Google. And this afternoon, when we’re at break, the refreshments are provided by Avenue4. I’d like to give a round of applause for them.

(Applause.)

John Curran: Okay. So we have a meetings app. If you want the agenda – speaker information, you know, information that’s online, but you want it on your phone all the time – go download the application from the App Store or Google Play, put it on your phone, and you’re goint to have the whole agenda in your hand.

Okay. If you have badges, you have a little ticket in your badge. Your ticket can be turned in at the afternoon break to get our stylish ARIN 39 t-shirts. Don’t forget that.

So let’s see. We’re actually here to do work. Even if we are in New Orleans, we’re actually here to do work. And it’s pretty important work. The work is developing the policies by which we run the registry, and so there’s some important courtesies here.

The Board of Trustees Chair, when we’re in the discussion of policies, will moderate the discussion so that everyone has a chance to speak and everyone gets a chance to be heard. What that means is if you have something to say, yes, go up to a microphone. Don’t hesitate.

But once you’ve said your share, wait for other people to speak. Don’t run to the back of the line until you know that everyone has had a chance to speak. Because if everyone were to speak multiple times in line, we could have a situation where people who haven’t made it won’t get a chance.

So let everyone have a chance to speak before you go back and add more comments in.

State your name and affiliation when you’re recognized at the mic. It’s for identification. There could be 25 Bill Smiths, and we’re not sure which one you are. You state your name and affiliation, and that way we know who you are if you have an affiliation you’d like to state.

Some people are pretty clear about their affiliations. Other people are less clear. But it’s a proper courtesy, just so we know what everyone is speaking from.

Please comply with the rules and courtesies in your program. In here, in your Discussion Guide, you’ll see a copy of the rules.

They are – at the beginning? At the end? Where were they? Maybe they’re not in here anymore. Do we have a copy of the rules in here? Susan? I thought we had it. I don’t see it this year.

Okay. Yes, page 4. I’m just going to say this is pretty important to start, this rules of discussion. They’re also the standards of participation on the ARIN website. They apply to our ARIN meeting. And that includes this discussion.

And it talks about courtesy. We’re focused on working on policy. We’re not busy talking about people, talking about their background, their race, their religion. Those aren’t really relevant. What I mean by that is we’re here to work on a particular topic, respect the topic, focus on the topic. Keep the discussion professional, not personal.

This is how we get the job done. This is a very important function we do for the Internet. And so we need people to give it the right level of decorum so it accomplishes correctly.

Okay. So today’s agenda. We’re going to have the AC, Advisory Council, On-Docket Report. And they’ll talk about everything that’s on their docket. Things that will be discussed today, things that they’re still working on that they’re not bringing to the discussion. They’ll talk about sort of what’s the full work queue.

We’ll have a presentation. That will be given by Dan Alexander. We’ll have a Regional PDP Update. Sean Hopkins, who supports ARIN staff, who supports the Advisory Council in their job, also provides a summary of sort of ongoing activities in the other RIRs. That will be a high-level overview, so people can understand what we’re doing and how it relates to some of the other things going on out there.

I have Leslie Nobile giving an update on Whois accuracy. We’ve been doing some analysis of the data in the Whois registry and would like to provide some statistics regarding how timely that data is, which might be found interesting.

We’re then going to at 10:00 go into our first policy. Our first policy is a Recommended Draft Policy. Because it’s a Recommended Draft Policy, it is possible this policy will be recommended to the Board of Trustees after this meeting, sometime in the months that follow by the Advisory Council.

If you folks find it favorable and there’s no flaws found, they could send it to the Board. So this might be the last chance you have to comment on Recommended Draft Policy ARIN 2013– 16– 3.

We’ll then have a refreshment break. We have a panel coming up after the refreshment break. We have a panel on IPv6. It should be very interesting. Aaron Hughes, Vice Chair, will moderate it. And we will go from talking about a number of interesting perspectives of people who have deployed IPv6.

We’re going to have lunch after that. And then after the lunch, Jeff Finkelstein will come up, from Cox. He’s the sponsor of our connectivity, so you guys all love him, and he’ll give a little speech talking about what they’re doing.

We’ll do Policy and Implementation Experience Report, which is where staff look at the policies, and we usually choose one and talk about how it’s been implemented, any lessons learned, any things that might be going right or wrong with it, again, for the community to discuss where the policy changes are necessary.

We do have two policies we need to discuss in the afternoon. We’ll start at 1:50. Draft Policy ARIN 2017-3: Update to NRPM 3.6 on Annual Whois POC Validation, and Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement, will both start this afternoon’s block at 1:50.

We’ll have the IETF Report given by our IETF Reporter, Cathy. And we’ll have an NRO Activities Report.

There’s going to be – I’m going to give an update on something called the Internet Technologies Health Indicators, which is an initiative going on at ICANN that affects the numbers community. I’ll give an update on that.

We’ll close, and then there’s something going on tonight. A social. Yes, we’ll have a social this evening.

So let’s see. Policy Discussion Room. The Bienville room will be open throughout the meetings. If you have a group of people that want to break out and talk in more detail about a policy, you can go over there, grab that room, and sit down and work out issues.

If there’s something that you want to work on but you don’t want to do it in the back of the room because we’re busy talking about the next policy, feel free to make yourself available. It’s an open breakout room for having policy discussions.

Tonight’s activity: We’re in New Orleans. It’s Mardi Gras World. So at 7:00 tonight, we’ll have our social. We’re going to have shuttles leave here from 6:45 on, every 15 minutes. Go on over. There will be food, floats, music. It will be quite an event. You have to wear your social badges. You have a social badge. So wear your social badge, the sticky you put on. That will get you in. Very important.

And then we have return shuttles coming back from Mardi Gras World starting at 8:30. Grab your shuttle back so that you can be here tomorrow. That’s pretty important too.

Okay. With that, I’m now going to introduce the people at the head table. Our Chair, Paul Andersen; Vice Chair, Aaron Hughes; Chair of the Advisory Council, Dan Alexander. This is horrible. Our Vice Chair, Tina Morris. Unbelievable.

(Applause.)

John Curran: And Chris, who is our Jabber scribe at the end.

Someone’s going to figure out what’s in the brain that does that, because it’s a problem.

Okay. So let me move right in. First policy proposal is – the first policy proposal, the first presentation is Dan Alexander. He’s giving our AC On-Docket Proposals Report.

Advisory Council On-Docket Proposals Report

Dan Alexander: Good morning, everyone. Give you a quick summary of what the AC is currently working on. When a proposal comes into the AC, one of the first things we do is we assign a pair of shepherds, two AC members, to each proposal, and they work on reviewing to make sure that the problem statement is clear, what the proposal is trying to accomplish is clear.

And they work with the author to clear up any questions or possibly revise the proposals. When it’s in that state, it’s not actually a draft proposal. It’s kind of in the queue that we’re developing with the author.

There’s two such proposals that are currently in that state – prop-235 and prop-236. One is – basically it’s some cleanup work in the policy manual to clarify some wording. The other one is looking at the possibility of removing the reciprocity requirements for inter-RIR transfers.

These two aren’t actually being discussed today, because they’re in this initial state. But they may be showing up on future – at future meetings.

There are four proposals that are in a draft state. So once these shepherds do the initial review and the AC actually accepts them as draft policies, now they’re in this initial state of actually working on the language, getting feedback from the community, getting feedback from the Public Policy Mailing List, and actually presenting here to find out if there’s ways to improve the language, if there’s unforeseen problems with any of the suggested proposals.

These four will be discussed in the next couple days. One thing to note about when it’s in a draft state, it cannot be just adopted after that.

There’s an additional step in the Policy Development Process where once we have these draft policies to a point where we think they’re ready to go, we advance them to what’s called a recommended state. And after a policy goes to a meeting in a recommended state, then we’re actually able to forward it to the Board for adoption.

So these four, while we’ll be discussing in the next couple of days, will actually have to go – if we want to continue working on them – will have to go to the next meeting in the fall.

There are two being discussed that are actually in a recommended state. One is the 2016-3: Alternative Simplified Criteria for Justifying Small v4 Transfers, and Streamline Merger & Acquisition Transfers.

These are clarification, slight modification policies to adjust how transfers operate, try and make them a little simpler, a little reduced overhead from ARIN staff, make them a little easier to deal with. Both of these, based on the feedback in the room, both of these are eligible to go to last call after this meeting.

There’s also some tables you’ll see at the lunch for the next couple of days where we have these tables designated for particular topics. We’re always looking for – the AC is always looking for additional information from the community. And some of the topics we chose this time were finding people who are interested in the Advisory Council, what’s involved with getting involved with the AC, or running for the AC.

There’s also – we’re always very interested in ideas for increasing the participation in ARIN. We’ve got the Mailing List, we’ve got these meetings, but we’re always interested in other avenues to increase that participation.

The third topic for the lunch tables is Whois and RDAP. How are people using these? What do they find useful? How can we improve this setup? Because the two proposals that are being discussed this morning regarding Whois, we really need to clean this data up. So it’s really a focus on the Advisory Council, of the Advisory Council.

There’s also, we have available policy breakout rooms. If people want to get a group together or get some AC members together to just sit down and have a talk, of course we’re always available at breaks, in the hallway, during the socials. But if you want a quieter room to step away and ask some questions or have some conversations about policy, you can reach out to any of us.

The AC members have a little black banner on their badge. You can find any of us, and we can set up a side conversation. That’s it. Thanks.

John Curran: I was going to ask if there’s any questions for Dan, but he’s escaped the podium already. It’s okay. Almost everything he’s talking about will come up on the agenda in the coming day and tomorrow.

Alright. I’m going to move up and have Sean Hopkins give the Regional PDP Update, giving a summary of the activities of the other RIRs.

Regional PDP Report

Sean Hopkins: Thank you, John. Good morning. Very nice. My name is Sean Hopkins. I’m ARIN’s Policy Analyst. I try to make sure the AC and staff have everything they need to help facilitate the Policy Development Process that Dan just spoke to just now.

Part of that role is kind of keeping an eye on some proposals and discussions that are happening outside our region for whatever benefit they might have for the AC and for you folks.

This presentation gives you a bit of an insight into these discussions, and later in the meeting we’ll have some of our colleagues from the other RIRs come up and give presentations that are a little more comprehensive of what’s going on in their respective regions.

We’re also blessed – and if I could have them raise their hands – to have policy officers from other RIRs here: Gianina, Marco, Ernest. They’ll be happy to get wonky with you if you have a few more granular questions. With that, let’s get started.

Alright, RIPE NCC. So 2015-4 and 2016-5 have actually recently been accepted and are currently being implemented by staff.

2016-4 is still under discussion. If it’s accepted, it results in provider-independent of v6 requests, still being able to go through if they’ve got sub-assignments that are less than a /64. A lot of folks that have requests in for them have /28s or other smaller prefixes in their addressing plans.

LACNIC. Press hard. Alright. You’ll notice two of these proposals here have the same title. 2016-5 actually creates new v6 allocation policy for LIRs that aren’t strictly ISPs, like governments, universities, et cetera. 2016-7, on the other hand, just modifies initial policy.

They’re also dealing with a one-way inter-RIR transfer proposal in their region. Currently the reciprocity requirement that Dan just spoke to excludes ARIN from that at this time.

APNIC. There’s a couple of props here dealing with proper management of the last /8 pool. Prop-116 keeps ORGs from transferring space that they initially got out of that pool. And 117 ensures any return space that originated from that pool finds its way back in.

AFRINIC. They’re also actually heavily discussing an inbound transfer policy that, because of the reciprocity requirement, excludes ARIN at this time. But they’re also dealing with the fact that they’ve triggered phase one of their exhaustion and they need to figure out soft landing, and they’re looking at modifications made to some older soft-landing policies.

Just a few other points to touch on. APNIC is looking to a proposal that’s revising their SIG chair election procedures. AFRINIC is in a whirlwind of discussion about amendments to their older soft landing policies. And RIPE has got a few withdrawn proposals, one of which deals with banning final /8 space transfers. And LACNIC actually triggered their final phase of exhaustion a couple months back.

There’s some references, if you guys want to dig a little deeper. And feel free to find our other RIR colleagues. If you have global questions and if you have any for me, you can find me wherever there’s caffeine. Any questions? Lovely.

(Applause.)

Whois Accuracy

John Curran: Okay. Next up, as I said, I’ve had Leslie Nobile, who is our – responsible for doing Global Registry Knowledge – that’s looking at the whole number registry system – I’ve had her doing some work on Whois accuracy. I’d like her to present some of those findings you might find of interest to the community here. Come on up, Leslie.

Leslie Nobile: Good morning, everyone. So I’m going to talk about Whois accuracy, the importance of Whois accuracy, what we mean by accurate Whois – we actually have a definition in here – and then talk about some of the things that ARIN is doing to obtain and maintain accurate Whois data.

I also have several slides with data talking about our POCs and our ORGs, the state of our database. And actually some of the information here will inform later policy discussions from this afternoon. So I’m very happy that I’m speaking before those policy discussions, because they may be useful this afternoon.

So what is accurate Whois data? This is the definition, we’ve sort of bandied about, me and some of my colleagues, and we think it is comprehensive, correct, and current.

Comprehensive data means that all the data that is required is registered and complete. All fields are filled in, everything you expect to see in the record is there.

By “correct” we mean that the data has actually been verified by staff as being correct. In the ARIN region, we do vetting of all organizations that get entered into the database. So we’re looking to make sure that the information they’re giving us is actually accurate. They’re actually registered companies. They’re giving us valid emails and mailing addresses.

And then the data is current. And by that we mean it’s been confirmed to be up to date or it has been recently updated. So when we’re looking at old legacy records that may not have been updated, the last updated date in Whois shows 1996, that is not current. So we sort of doubt the validity of the data. It could be accurate, but there’s no way for us to know.

So why is accurate Whois data important? What does it mean to all of you as part of the Internet community? Well, it’s extremely important for Internet operability and stability. It helps network operators identify other network operators to resolve technical and/or abuse issues. This was one of its original purposes. The registry is to hold unique identifiers, but it is also so that network operators can find other network operators.

It is very important from a public safety perspective. It is used by law enforcement globally quite honestly, in law enforcement investigations and to identify the responsible party to serve process. So that would be – in the US, it would be court orders and subpoenas.

So they’re looking for someone who has access to that customer – somebody they can serve process to, to get more information about.

Quite honestly, it is really important from the perspective of protecting number resources from hijackings. We have found in the ARIN region that the stale records, the old records, the ones that don’t get updated, are the first ones that are targeted by the hijackers. That’s where they start. They look for the last updated date and they go for it. And then they start checking routing, et cetera, et cetera. They’re always targeting the stale or inaccurate data.

From an RIR perspective, this is one of the key responsibilities of the RIRs. This is written into RFC 7020, which is the successor RFC to 2050, which is one of the original ones we used at the time of establishing ARIN. And it says a core requirement of the Internet numbers registry system is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. So for us, this is bible. This is stuff that we should be doing.

And then from a contractual perspective, contractual requirement perspective, ARIN’s Registration Services Agreement has a couple of sections in there that talk about accurate data.

And it is required. If you sign ARIN’s RSA, you are required to keep your data accurate and current. So these are just some of the main reasons that it is important.

So I just sort of threw this in there. Could IPv4 depletion affect data accuracy? I would say yes, and these are kind of the reasons.

Under current policy, ISPs are required to register their reassignments in Whois. And that’s a /29 and larger for IPv4 reassignments and a /48 and larger IPv6 reassignments.

So there’s no longer any other IPv4 address space in the free pool. And we don’t see many ISPs or customers coming to us for IPv4 address space. And it’s likely that they’re not as motivated to continue to register and/or maintain their customer data.

One of the ways, one of our hammers, essentially, was when an ISP came for additional space, we would verify that all of their reassignments were in the database. And now that they’re not coming to us, we have no way of knowing whether they’re in there or not because we’re not proactively looking for them. We don’t have the resources to do that.

On the flip side, with IPv6, once an ISP gets a block, they may never have to come back to ARIN for more space because those blocks are so large. And so they’re not coming, and therefore staff is not checking the reassignments. So they, again, may feel less motivated to register and/or maintain their v6 customer assignments. That’s a big chunk of data that might not be getting in there or might not be maintained by the upstream ISP.

So we think that new ideas and approaches might be needed to keep the data from degrading over time, and that’s something that I’m working on for John, as he mentioned. This is one of my prime reasons for being.

So what is ARIN currently doing to obtain and maintain accurate data? So I looked at it from three different perspectives: from a policy perspective, what policies tell us we have to do that; from a business practice perspective, what does ARIN do on their own as business practice to ensure accurate data; and then from a contractual perspective, what does the RSA say?

From a policy perspective, we have two policies that address accurate data. We have the annual POC validation in which ARIN staff sends out an email to every single registered POC in the database asking them to validate their data. So they just have an option to just hit validate, or they can go in through their ARIN Online account and update their data.

The second policy that we have was the one I just mentioned, the reassignment information, and it’s in two different sections – one for IPv4 and one for IPv6. And that one required ISPs to put all their customer reassignment information into the database.

So those really are the only two policies that talk about accurate data or putting data into the database.

From a business practice perspective – so we made some changes early on when we were being hijacked right and left by people. They were hijacking legacy space, and we sort of caught on and said, oh, we can’t let this happen.

So we started putting all kinds of security measures in to prevent some of that. So one of the things we did was we found a lot of people just registering organizations, fake organizations. So we said, okay, all our organizations have to be legally registered entities in our region in order to receive resources, to actually get into the database and receive resources.

That was one of our ways of obtaining accurate data right in the front, first step basically.

Organizations that are requesting services and resources have to be vetted every 12 months. So we actually do that. We mark it in our database. And if we see an Org come in within 12 months, they don’t have to be revetted. But if they come in after that 12-month mark, we will revet them.

And then service requests are only accepted from the registered Points of Contact, so we know who we’re dealing with.

As far as the contract goes, the Registration Services Agreement, there’s a couple of sections that mention accurate data in one way or the other.

1.c talks about the organizations receiving service having to comply with all policies. So if there’s a policy about accurate Whois, they would have to comply with that. The more obvious one would be 3.b, and it says: Organizations receiving services must provide and maintain accurate registration information in Whois for themselves and for their customers.

So it is a contractual requirement. The problem is not everyone in the ARIN database has signed the contract because we have a slew of legacy users from way back when.

I’m going to do a couple of slides with some statistics. So these are just our overall general Point of Contact stats. We have almost 744,000 total Points of Contact registered in ARIN’s database. 177,000+ are validated, what we call validated. In other words, they responded to the validation email that we sent them, or they updated their Point of Contact record within the past 12 months and that validates them as well. So there’s two ways to validate.

243,000+ are non-validated. And then we have 323,000 Points of Contact in our database that are orphaned. And an orphaned POC is not associated with any number resource. And we have a lot of them. And what we found is that most of these are reassignments. They were set up by an ISP for a customer, and in order to put a customer in the database, you set up their Org, you set up their POC.

So we have ISPs using automated scripts sending in thousands of customer POC templates, if you will, and they’re registering POCs. And then either they never assign them resources, they just leave them in the database, or they assign them resources and then when they’re no longer their customer and they give their resources to another organization, they leave the old POC in the database and never clean it up. So we have a big problem with orphaned POCs. There’s a lot.

So I want to talk a little bit about orphaned POCs and ORGs, because this is actually going to be one of our projects hopefully this year. So the POC, I told you about the POCs. So 43 percent of all the points of contact in ARIN’s database are orphaned. They’re not tied to any resource.

Looking at the Org IDs, we’ve got 754,000+ Org IDs. Now, I say customer records are not included. Customer records are simple reassignments, and they typically use their upstream ISP’s data. We didn’t include these – they don’t get their own Org ID. It’s just a customer record. 305,000 of our Org IDs are orphaned. So 40 percent of all Org IDs registered in the database are orphaned, not tied to any resource.

So I think that deleting some of this erroneous data could improve the quality and integrity of ARIN’s database, get rid of the cruft and leave us with some better data in the database. So we’re planning on doing a community consultation where we are going to present to you some criteria.

We’re going to be very careful. For example, we’re going to do a two-year window. If you’ve been orphaned for two years, we’ll start looking at you, and then we have another set of criteria. But we would be very careful before we would delete any POC or Org.

But we’re going to write the consultation, send it out for community input, probably in the next couple of months. So stay tuned and please participate. We want your opinions.

So this is actually looking at direct and indirect POC validation stats. This is part of that annual POC validation – who is actually validating, who is not. And this looks at it from a direct and indirect perspective. So direct POCs have received resources from ARIN directly, or from an ARIN predecessor registry.

And indirect POCs are customer reassignments. So, in purple, we have almost 51,000 total direct POCs in ARIN’s database. And when you look at how many of them have been validated or unvalidated, remain unvalidated, 56 percent of them are validated, and 44 percent of them are unvalidated.

And for organizations who have a direct relationship with ARIN, that number isn’t very encouraging, really. I would have expected more.

So when you look down at the total indirect POCs, we’ve divided that into three different categories, and there’s 693,000 total indirect POCs. These are the customer reassignments.

About 149,000 of them, or 22 percent of them, have been validated. 221,000 basically are unvalidated, or 32 percent of them are unvalidated.

And then 46 percent of them are orphaned. And just so that you know, orphaned POCs do not receive the annual POC validation message, because they aren’t tied to a resource. No one should need to contact them. We left them out. It would just have been a mess with them.

So we leave them out of the annual POC validation. So really the numbers to look at are the validated/unvalidated, 22 percent and 32 percent.

So that’s POC validation. And then I tried to pull in some legacy data to see whether legacy networks are actually updating their Points of Contact.

And this is actually an encouraging slide. I always say that when I do this.

In purple, we’ve got almost 28,000 total ARIN-issued v4 networks. Over 25,000 of them, or 93 percent, have at least one validated POC associated with their resource. And that’s really good.

And only 7 percent, or just about 2,000, have no validated POC at all on their resource. But that’s sort of to be expected, I think. That’s not shocking.

But when you look down at the bottom, there’s almost 25,000 total legacy networks. Almost 50 percent of the networks registered in ARIN’s database are legacy.

Almost 12,000 of them have at least one validated Point of Contact. That’s 47 percent. For a legacy network, that’s pretty high.

And then we’ve got 13,000, or 53 percent, that have no validated Point of Contact. So legacy records are updating their Points of Contact. It’s very obvious from looking at this. I find that encouraging.

So what else can ARIN do to obtain or maintain accurate data? I told you about what we are doing currently. These are some things I put into my paper, recommendations I made to John, just a few of them. There’s more. But just food for thought in this one.

So possible staff actions. And this one, actually, this first one is a good one and probably one that we will be doing soon. I’ve been working with FSD and RSD.

Anytime our staff is working with a customer directly via the phone or in a face-to-face, like at the ARIN help desk or NANOG help desk, I would like them to add one step toward the end to just say, can we take a look at your POC and Org information? Let’s just walk through it, I will help you. I’m here on the phone. I can help you update it in two minutes or less.

So I just think that would be a good way to just start getting people to realize what they need to be doing. And we’ll help them. So that’s good.

As part of the annual POC validation policy, ARIN is to produce a report called Resources With No Validated POCs. And the report is available to people who are willing to sign the bulk Whois – comply with the bulk Whois policy and basically have to sign a Terms of Service to get access to the data.

So this report lists the resources that have no validated POC. And I thought, if we’re going to start auditing or if we’re going to start being proactive, maybe this is the place to start with, because we know that these resources have no validated POC. So let’s try to track them down and see what we can find, see if we can get this updated. So this would be sort of a mini auditing procedure, a proactive step.

One of the things we’re definitely doing, been talking to Susan and our whole team about providing more training to the community, and I’d like to add in, I mean, we already train on IPv6 and how to use ARIN services and DNSSEC and all those things, but I want to add data accuracy requirements in there. I want to tell people why it’s important.

I did a presentation at NANOG about a year and a half ago, and I talked about why it’s important and about hijackings and how it works and what people need to do.

And people were extremely interested, particularly those with legacy space, because they don’t really understand that they could be hijacked and they don’t understand how easy it is to come into ARIN and update their records.

So we’re going to go and do some outreach in that area. And we’re going to do webinars, blogs, direct outreach, website enhancements, documentation, short videos and visuals, publications, et cetera. So we’re definitely going to make a push in that area to talk about Whois accuracy.

And the last one is kind of the hard one, because that would require resources. We could develop sort of a proactive auditing procedure that targets all – sorry – organizations with direct resources from ARIN. And staff could sort of start conducting ongoing outreach to direct customers to do the verification. That’s the hard one, though. We definitely need some additional resources for that.

So those are all possible staff actions. But what else might be done to obtain or maintain accurate Whois data that’s outside of staff’s purview?

Well, one thing that could happen is we could, someone could, strengthen the terms and conditions of the Registration Services Agreement.

Right now it’s pretty – there’s not – it says you need to have accurate data, but it doesn’t have any kind of repercussion for not doing so.

And so ARIN staff doesn’t, you know – doesn’t have a lot to go by with this. So we could clearly highlight the requirements for accurate data at all times and add repercussions for not maintaining that accurate data.

That’s just one thing I thought about. We could create – you could create new policy and require Whois data to be updated and accurate at all times.

We’ll be discussing a couple of Whois accuracy policies this afternoon. So maybe we’re heading in that direction.

The more extreme one is to introduce a new federal law. If it goes outside of our Internet community, bottom-up process, it could go right to the government and a new law could be created that requires ISPs to provide and maintain updated and accurate contact information at all times for themselves and their customers.

And that would be a very different way of doing business for all of us. If we start having government policies, there may be more. So that is definitely the extreme measure.

So, in summary, just want to highlight a couple of things I talked about, sort of the takeaways.

Accurate Whois data is vital to the operation of the Internet for many reasons. We do know that some amount of it is inaccurate today, and it could get worse going forward.

Inaccurate data, we know this, can affect a network operator’s ability to quickly fix operational and/or abuse issues, and accurate data contributes to the overall safety and stability of the Internet.

So staff continues to work on ways to improve data accuracy and integrity, but we would actually like to hear feedback from the community on other ways we can attack this problem.

We have an ARIN Consultation and Suggestion Process. You could use that if you have some good ideas. We would love to review them as a team.

If you want to just informally have an idea, you could send it to me and I could – we could talk about it with our management team.

But there are ways to get your ideas and feedback to us, and we are very interested in hearing it.

So that is all I have. That’s my last slide. I didn’t do a questions or thank you slide. But I do thank you.

(Applause.)

John Curran: Any questions for Leslie?

Owen DeLong: Owen DeLong, Akamai, ARIN AC. On your slide showing the number of POCs that were validated, unvalidated, and orphaned, are there no direct orphaned POCs or –

Leslie Nobile: It’s negligible. I didn’t include it in there. I just put it in one basket. 99.9 percent are –

Owen DeLong: – are indirect?

Leslie Nobile: Yes.

Owen DeLong: Thank you.

Andrew Dul: Andrew Dul, CrowdStrike, ARIN AC. The slides where you had legacy, you had one valid POC in an organization, I’m trying to remember on the direct resources, did you have the same statistic for that? Or did you have a different statistic?

Leslie Nobile: It was the same, I think. I gotta go back.

Andrew Dul: That’s at least one validated POC at the bottom, right? And then for direct resources, is that the same metric?

Leslie Nobile: Yes, it’s the same metric.

Andrew Dul: Can you go back one slide? So that’s the same metric; is that true or not true?

Leslie Nobile: No, we were looking at different things. This is just total number of validated POCs that are direct/indirect.

Andrew Dul: I’d like to know what number of ORGs have at least one validated POC, direct or –

Leslie Nobile: In other words, this slide but for all networks, not just legacy networks.

Andrew Dul: For direct.

Leslie Nobile: Direct.

Andrew Dul: As in there is at least one validated POC for the Org.

Leslie Nobile: Okay. Okay. We’ll look at that for sure.

Alain Durand: Alain Durand. First off, I would like to congratulate you for doing this work. I think data accuracy is really important. I have one question and two comments. So maybe I will start with a question: Have transfers improved accuracy?

Leslie Nobile: I would have to say that it does because a lot of work is being done to vet those transfers. I think it has. And I’m sure the RSD department would agree.

John Curran: Sort of by definition, the resource at the end of the transfer has valid contacts. And that’s not the case at the beginning. So I would say, yes, it generates more accuracy.

Alain Durand: Thank you. So my two suggestions, then, comments, suggestions. First one I think I made previous meeting, is one of the tools that you have at your disposition that I would like to bring forward is to say whenever there’s a new policy being discussed, to have a section in it to say, does it improve the accuracy of the data or not, and some favor policies that actually do improve quality of the registration. So that’s my suggestion number one.

Suggestion number two is you were talking about maybe deleting some of the old orphaned POCs. I would suggest if you do that, you archive them, so if we want to do some research later on, they will be available.

Leslie Nobile: We would do that absolutely. We archive. Yep.

Up to the front mic.

Craig Thompson: Craig Thompson with Caldwell Global. I have three questions. Are you aware of any push among legislators in the United States, in the ARIN region, Canada, Caribbean, to require and pass laws? Are you aware of anything that is a rumbling, headed that direction?

Secondly, are you aware of any of the other regions, like RIPE, that also are trying to pass legislation forcing this type of registry accuracy? Those are the first two questions, and I’ll let you answer that.

John Curran: Those are actually my questions. So as it turns out, ARIN does pay a lot of attention to legislative efforts anywhere regarding the Internet Number Registry System. We have people who pay attention to that, including myself.

Right now, we don’t see any such efforts because the governments are working together in forums, like within ICANN there’s a government working group which has a public safety working group, the GAC, Government Advisory Council, is a public safety working group which is busy talking about the implications of registry accuracy on public safety.

Right now they seem to be working within the processes available in the Internet community. On the other hand, that’s – how long that continues to work will obviously be based on success rate.

So there’s no way to forecast – there’s certainly a lot of interest in the topic. We’ve seen in the last two years a remarkable amount of discussion among governments about registry accuracy. But right now, per se, no legislative activities I can see.

Craig Thompson: The last question is, is the goal of getting accurate data something that could be crowdsourced with certain types of bounties even and use a larger Internet community to try to find who these people are who own this?

John Curran: So, we’re the staff here. We do what you tell us to do, including if you tell us set up a crowdsource method and give bounties, we will set that up. But it’s certainly an interesting possibility. At the end of the day, it’s what you guys want to direct us to do.

Craig Thompson: Okay.

Kevin Blumberg: Kevin Blumberg, The Wire. Thank you, Leslie, for this data. It’s refreshing to see it. Two things: One, if you go back to the – what is it? 93 percent have been validated of resources are under RSA, correct?

Leslie Nobile: Yes.

Kevin Blumberg: A suggestion on that one is: We don’t take your money if you’re not validated and you go from 93 to 100 percent, because everybody there is paying something every single year. To not be validated means that you’re taking money from somebody who you have no idea who they are. So just to – you can do with it what you want; it’s just a suggestion.

And I just wanted to confirm, with the orphans, that data is still relevant to the WhoWas because without it you wouldn’t be able to. So it’s not that it’s orphaned and not useful, it’s orphaned and historically relevant data.

Leslie Nobile: And would be archived if we deleted it.

Kevin Blumberg: So my question statistically is how much of the current RSA, so the 93 percent, do you see changing year over year? And is that then a benchmark to say if we see 20 percent of the ORGs or the POCs are changing year in and year out, that over a ten-year period data will become more stale, more stale, more stale.

In the regular Whitepages phonebook that they used to have, the rule of thumb was 15 percent a year would change. The entire book would change 15 percent.

What sort of numbers are you seeing year over year in terms of the percentage of change?

Leslie Nobile: Yeah, it’s really the first year we’ve measured. But it’s a good thing to keep as a metric, and we’ll regard that one and look at it for sure.

Kevin Blumberg: Thank you.

Rob Seastrom: Rob Seastrom, Neustar and ARIN AC. Speaking of metrics, I suspect the vast majority of the validated POCs come from clicking on links in email that we have sent out to people. So that means we have a 47 percent success rate with that campaign.

Are we collecting information if we are contacted out of band, some other way, on what campaign led people to validate their POC? It would be very interesting, since you have different ideas for outreach, to figure out which ones are actually getting results versus which ones – I mean, for instance, I’m going to pick on this just because it’s something that popped into my mind.

We have no idea how many people registered IPv6 space or updated a POC or whatever based on the comic books we did several years ago. We don’t know what the results from that are. And it would be interesting to collect that data so that we could –

John Curran: At present, we don’t distinguish why or the exact method how. And it’s a little complicated, because, for example, clicking on email links, we actually just really enabled recently in the way that makes it as usable as possible. In the past, it was a reminder for you to go in and use ARIN Online to update your POC.

So there’s: how did you update? Well, someone updated a POC with ARIN Online. Which isn’t the same as –

Rob Seastrom: And you don’t know why.

John Curran: – as why did they update. They literally may have updated in the past because they got an email but it’s completely disassociated.

So there’s the method that they used to do the update and then there’s the driver. I’m not sure we can tease out the former. It may not be possible.

Rob Seastrom: I suspect it’s not possible to get complete data on that. But any data that you might be able to get could inform where we put future resources. Thank you.

Leslie Nobile: Thanks, Rob. Back mic.

Roxanne John: Good morning. This is Roxanne John here, Government. My question is regarding the registry accuracy. How would government know that there’s some issues with regards to the maintenance of the accuracy of the data and what support is there for the government to be able to enact policies to maintain such accuracy?

John Curran: So we actually do have some governments who come to us and ask about the registration records in their region. And they’re all public. You can go to the Whois database. But we also are pretty good at pulling subsets. If you want a subset of records for a particular country, in your government, we’re happy to generate those, and we can show you which ones have been updated and which ones haven’t. All you need to do is ask.

Cathy Handley handles our Government Affairs group. She’s capable of being the liaison for all those efforts. So if you need information about the registrations in a particular country, you’re the government minister there, please reach out to us. We can provide you a list of them and a summary about what their status is. What you do with that is sort of your decision.

Follow-up?

Roxanne John: Yes, I have a follow-up, because I’m wondering how proactive can the approach be, because sometimes the government may not see the need until there’s some hacking or some major disaster. You may want to avoid it. You may want to have some system in place where they will be informed and they can take action before there are disasters.

John Curran: That’s something that this community should discuss. We can engage, when you talk about the possible options to improve things, one option is to go to the governments and say: Here’s the registrations in your region and here’s the accuracy of them, and what do you think about that? We’re happy to do that. But, as you know, ARIN wouldn’t initiate something like that unless you asked us to. And that’s pretty important.

Because we don’t want to – we don’t want to initiate directions that the community hasn’t told us to initiate. But we have the capability, and we certainly have the information.

Any other comments or questions for Leslie?

Leslie Nobile: Thank you very much for your time.

(Applause.)

John Curran: Okay. Having gotten done with the easy stuff, we’ll now move into policy development. It is 10:00 on the dot.

RDP ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers

John Curran: The first policy up is Recommended Draft Policy ARIN-2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers.

I will do the staff introduction, and then have David Huberman, who is the ARIN Advisory Council shepherd for the policy, come up and give the AC presentation.

This policy was proposed in April 2016. Proposed policies get published on the mailing list. This was ARIN Proposal 228. The AC shepherds David Huberman and Owen DeLong were assigned to it. They’re the ones who helped work it through the process of policy development with the community.

It was presented at ARIN 38, our last meeting in Dallas. It was advanced in February to Recommended Draft Policy status, which means the Advisory Council was of the opinion that it meets the criteria necessary, it has community support, it’s technically sound, and it enables fair and equitable number resource management.

The text is in your Discussion Guide and online. Discussion Guide. In your Discussion Guide, 2016-3.

Staff does a staff and legal review. We actually – when asked by the Advisory Council, we look at the proposed policy, and we take a look and see how would we implement this and what would it mean, how would it end up in the manual.

We go back, and we give that back to the Advisory Council. It’s published online so that people can see that our interpretation of the policy matches what they intended the policy to do. Amazingly, the two don’t line up all the time. We point out places of ambiguity and similar.

So staff understanding of Draft Policy 2016-3, it allows organizations to double the size of their current IPv4 address space holdings up to and including a /16 through an 8.3 or 8.4 specified transfer without a needs assessment being conducted by ARIN staff as long as they can demonstrate 80 percent utilization of their current holdings.

Organizations would still be able to qualify under the current policy by showing 24-month need, which is the current practice.

Policy staff can implement it as written. There’s no ambiguities. The legal assessment, there’s no material legal issues. It’s a policy for administering number resources. You are the folks that set that. If you change it, we operate according to the new policy.

Resource impact. When we go, if you – if this ends up being adopted, then we’ll have to implement it. The implementation will take about three months from when the ARIN Board of Trustees ratifies the policy.

We update the staff guidelines. We update our internal procedures for processing these requests. We’ll have to update our staff training material.

And now I’ll turn it over to David Huberman of the ARIN Advisory Council to give the presentation.

Good morning, sir.

David Huberman: Hi, good morning, everyone. David Huberman from the ARIN Advisory Council.

So in October at the ARIN meeting in Dallas and following that, we, as a community, implemented a new transfer policy. We called it at the time 2016-5.

And what this policy does is adds – it rearranges Section 8 and adds new qualifying criteria for when you wish to receive IPv4 number resources into your account, you now qualify by demonstrating to the ARIN staff in a ticket that you will use 50 percent of the address space that you’re requesting within two years.

So from a certain perspective, that means you can request probably up to a four-year supply of IP addresses. This was a pretty big change, and this went into effect in the NRPM at the end of February.

Now we are looking at making slight adjustments to that. We are looking to add a new section to this new NRPM 8.5, which adds an alternative set of criteria which applies only to some organizations.

It boils down to if an organization is using 80 percent of all existing address holdings in an account, you can double your holdings up to a /16 without a needs assessment.

This means that, if you have a /20 worth of IP addresses today that you’re using, you’re using 80 percent of them, and you wish to go out to the market and add more number resources to your account, you can double – you can go out and get up to a /20 worth of addresses, go to ARIN and say, hey, I’d like to move these into my account, and there will be no needs evaluation.

We have time-boxed this a little bit. There is a hard cap on this of a /16. So you may not request more than a /16 of addresses to be moved into your account under this process. Any time – only once over a six-month period, and it’s a rolling six-month period.

So on the mailing list when this was discussed, there was a little bit of resistance from one of the co-authors of the original policy proposal on this time boxing, as the author felt it didn’t account for the long-term growth of an organization.

However, after much discussion, that author has submitted a new policy proposal, which will be discussed I believe tomorrow, which is in a draft state, to address this.

I’ve put an important bullet point here. When we look at the history of 8.3 and 8.4 transfers, since their inception, approximately 97 percent of them are potentially eligible to qualify under this new criteria. That doesn’t take into account the time boxing, and there will be some exceptions here and there.

But what’s interesting about this is this was meant as incremental change. This was an idea of let’s ease up the needs evaluation just a little bit, and let’s help the little guys. Let’s help some of the folks who are doing small transfers move in a small amount of space into their account without a needs evaluation. But what winds up being interesting is it affects almost everybody.

So that’s where 2016-3 is today. In Dallas, when it was presented, there was a very strong consensus in the room that you wanted the AC to continue working on it. We’ve worked on it. The text is as-is in your Discussion Guide, and the floor is now open.

Paul Andersen: Thank you, David. John, we’ll have to have you move over a bit. There’s only one United Economy seat of space here.

Good morning. So just – this is our first policy, before we get speaking. Lots of new faces, which is great to see.

If you have not ever looked before, I urge you to look at the great flowchart on page 24 of your guide, which gives you the beautiful life of a policy. And in this case, we’re dealing with a Recommended Draft Policy. So we’re all the way down here at step 5.

The important part that I’ll note about that is that this is the last time you possibly could see this policy at a meeting. So this is a very important time for you to give input.

So at this point, all the microphones are open. I’d ask you to approach a microphone, state your name, organization, whether you are in support or against this policy, and then you can make any comment you wish against that – towards that.

With that, I’ll go to the far microphone.

Dani Roisman: Good morning. This is Dani Roisman from SoftLayer, IBM. First of all, thank you, David and Owen, for shepherding this policy proposal through.

I agree. I think this should happen. I think we’re not going far enough. As you know, I’m a huge proponent of eliminating all needs-based justification for transfers.

I do accept this as a good incremental step. I think we should definitely put it in place. I’m hoping that once the community in general becomes comfortable with this, we can take the next necessary step, which is simplifying it even further and eliminating all needs based justification for 8.3 and 8.4 transfers.

Paul Andersen: Thank you very much. Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. Question for you, John. You mentioned there was a legal concern about the word “small” that was not brought up on the notes. I wanted to confirm that’s an editorial change because it’s just in the title. It’s not actually substantive?

John Curran: “Small” is a judgment word. And so the point is if you put small in the title, some people may say: I read the title, I saw the word; I wasn’t sure whether that applied or not. I didn’t think that was small. I would have got more involved if I had known you were talking a /16. That’s huge, sir, huge. How dare you mislabel this proposal.

Something like that. So we prefer not to have judgment words where they can be avoided.

Kevin Blumberg: Thank you, but my question was because of the title, that would be considered an editorial change?

John Curran: That’s correct.

Kevin Blumberg: I support the policy as written. My biggest thing to all of this is this is not going to change the requirement for an organization to show the space that they’re using. There’s still a lot of work that an organization is going to have to do to prove to ARIN that they’re at 80 percent. But to me what it’s really saving is having to jump through hoops to explain to ARIN how I’m going to use that space over the next two years.

Showing how I’m using my space is easy. I have to do that because I need to justify it to myself. The jumping through hoops of trying to prove to everybody, prove to staff, how I’m going to use this space is a complete waste of time. And I think setting it at a /16, getting it for 97 percent of the people or whatever the number might be, is the absolute right way to go.

Paul Andersen: Thank you. So we are lacking people at an in-person microphone. We hopefully may also have some people remotely. We have our scribe at the end. No one on the tubes, Chris?

It’s very important that you approach and give comments. And it’s fine also to approach and say I’m in favor or against, just leave it at that. But this is very important information for the AC because they will need to decide at their next meeting whether or not this policy should continue into the process and become a final policy or not.

So we’ll make – yes. We will also have a vote at the end. But I’m just trying to encourage a little bit of input. I know many of you probably were woken up at 4:55 AM for tornado warnings, but let’s try and – we will close the microphones in a few seconds, give any people on the tubes the last chance to type.

As the music starts to blare loudly – we are in New Orleans. It’s probably a parade. The microphones are closed. We’ll thank David for the presentation.

(Applause.)

Paul Andersen: Again, a little bit of explanation for the first time – this is the first time for some of you – that we will now ask a question. The question will be: Are you in favor of the Advisory Council advancing this proposal?

I will first ask for, in the room, to hold your hand up high if you’re in support. Put it down, and then for those against. We have our expert counters in the back, and we also have our online counting as well.

So, all those in favor of advancing this – actually, sorry. I did not check. Are the counters ready? Good. I’d hate to do that.

So if you are in the room and can hear the sound of my voice, even online, if you are in favor of this policy advancing, please raise your hand nice and high, one hand. Please keep it up until I ask you to lower it.

We are counting away. If you are online, please indicate now, and you will be also counted. Also give a little bit of time for the online because there’s that little bit of delay. Not as much as it used to be; used to be the whole half minute.

We are good. You may lower your hand. And if you’re opposed to this policy advancing, please raise your hand nice and high. Thank you very much, you can lower. We will just need one moment while the tabulation occurs, including online. And then it looks like, are we going to get an extended break, or are we going to try to do something – extended break. Whew. More caffeine. I hope this isn’t an encouragement not to comment. We might have to start sticking extra policies in.

On the matter of 2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers, the results of our poll: 50 in favor; one against; with 144 people in the room and online.

Thank you very much for your participation. This will be provided to the Advisory Council. And I will turn it back to John for the break.

John Curran: Thank you, Paul. Okay. Wow. I wish all policies went like this. Okay. So we are actually ahead of schedule, just a bit. But I am told that the refreshments are ready. So at this time we’re going to take a refreshment break. We’re going to come back and kick off the IPv6 panel.

You should be back here in your seats ready to go at 11 AM, so you have approximately a 40-minute break. Go forth, enjoy.

(Break.)

Aaron Hughes: Welcome back. If everybody could please take their seats, we’ll get started with the v6 panel.

John Curran: If people will come in and get seated, we will get started. If you’re in this room, you’re here for the ARIN meeting. Good. If you’re in this room and standing, I don’t know what you’re doing.

Welcome everyone. It is 11:00. Yes. It’s 11:00. Welcome back from our refreshment break. Next up on the agenda is our IPv6 panel. I don’t know if we have slides. Do we have slides? Three. Okay.

So the panel is going to be discussing issues in IPv6. Aaron Hughes is the moderator. We have panelists Hector Rios, John Jason Brzozowski, Zaid Ali Kahn, and Alec Peterson. And at this point I’ll turn it over to you, Aaron.

IPv6 Panel

Aaron Hughes: Thank you, John. And thank you very much, panelists, for participating in this v6 discussion. First, just want to open with one basic rule of engagement. Whether you come up to ask questions or comments or you’re a panelist commenting, I would ask that you keep company names out of comments, whether you’re giving praise or you’re saying, for example, you had to wait on it. Please don’t use Bob’s Bait and Tackle ISP or CDN. Just say a CDN provider or a hardware vendor. Appreciate that.

So, first, we’ll just kick it off with a very brief introduction. Why don’t we just start with you, John.

John Jason Brzozowski: Can I – can somebody queue my slides up back there, if you don’t mind? These might actually automate themselves, if all things go well here. If not, then I have a trusty clicker.

So kind of leading up to this panel, kind of looked at the agenda here, tried to figure out what exactly you could possibly want to hear from me from an IPv6 point of view.

So I thought I would sprinkle in a little bit about where we’ve been and, more importantly, kind of what the current state of the state is. And hopefully that will fuel some discussion here with Aaron and the rest of the panelists.

Many years ago, I’ve been to a few of the meetings, we’ve talked about kind of the roots of some of our v6 deployment. Anybody who is kind of a cable/broadband customer, whether you’re in the United States or abroad, a cable modem is a pretty important component to how you utilize a DOCSIS network.

One of the things we usually lead off here with is kind of giving you some insight into where we started and where that is.

Aaron Hughes: Sorry, just in case, say you’re with Comcast. It hasn’t been mentioned yet.

John Jason Brzozowski: I’m with Comcast, in case you didn’t know. And today we have about 40 million cable modems on our network. 39.5 million of them are v6-only.

That’s a lot. And if the modem doesn’t work, guess what else doesn’t work? Nothing works.

So we did that. Can’t really see the scale anymore, but we’re probably going on four, five years now, and now we’re really just trying to get rid of the rest of the modems in the sense that you either upgrade them, wait for them to kind of cycle out lifetime-wise.

So for anybody out in the audience that’s wondering, like, does it really work? It works. You should try it.

Next slide. Or is it on me? I got it.

So on the heels of that, a few years later, maybe a little overlapping, we also turned on dual-stack broadband. So we added v6. We turned it on.

This is kind of old news. We talked about this quite a bit in some other fora, probably a year ago or so at a NANOG.

It’s an important chart for people who don’t really kind of have a lot of experience with this, but basically 90 percent of our customers today are dual stack-enabled. That means they’re actively provisioned with v6, actively using it.

I think at this stage of the game, we are either approaching or just about to kind of surpass – 50 percent of our traffic is v6 today.

And I can – if the question arises, I can talk about what that drop is there during the panel. I’ll leave you wanting that, though, until later.

Next slide, if it’s in my control or not. Last but not least, probably the most interesting thing, and I’m hoping that we can also generate some discussion around this. So probably should have mentioned this in the intro, but for those who don’t know, Comcast provides voice, video, data and a number of other services, right?

This particular graph is basically oriented towards our X1 platform. If anybody happens to be a Comcast customer, you use X1, hopefully you’re happy. If not, let me know. We’ll see what we can do about that.

But that platform has been a pretty successful platform. I, for one, can tell you that it’s a huge upgrade compared to the legacy video technology that John Sweeting is currently laughing about. And I’m laughing on the inside.

But it’s a huge upgrade. And this platform has been quite popular for us, so popular that it outgrew v4. And we knew it would. So what you’ll notice here is that is a pretty aggressive line up and to the right that – the blue and the red.

That is basically us migrating almost all of them, all the X1s to v6 only – no v4 support – in a period of less than three months. Tens of millions of them.

With that, that’s my last slide. I’ll hand it off to whomever Aaron tells me to hand it off to.

Aaron Hughes: Sure. Thanks, John. I appreciate the introduction. Hector Rios is from Louisiana State University. Could you possibly give a brief introduction as well?

Hector Rios: Hector Rios, Louisiana State University, main campus in Baton Rouge. I’m a network engineer in the department of Information Technology Services. I’ve been part of LSU for the past 15 years in different capacities, but mostly as a network engineer with a team of really talented people.

We’ve been supporting IPv6 since 2008. And should I go into the details or – so I can talk about the details once we’re finished with things, the introductions.

Aaron Hughes: Thanks, Hector. Zaid Kahn from LinkedIn.

Zaid Ali Kahn: Thanks. My name is Zaid. Just on a brief note, I didn’t bring any slides because there’s tons of information out on the Internet that you can download. We’ve given a lot of talks on this.

So we launched v6, from LinkedIn perspective, I think in 2014. It was September, October, somewhere around there. We brought all our sites to v6.

We started off, I think, the day of the launch at 3 percent, and now we’re somewhere between 10 and 12 percent of global traffic. Since then we’ve sort of managed to see a lot of growth. In also different parts of it I’m happy to say that our mobile site has seen a lot of growth. We have a major mobile provider that’s now serving just 80 percent of traffic over v6, which is a huge growth for us, seen from the mobile side.

And more than half of our traffic is actually mobile. So that’s actually great to see. We’ve seen a lot of growth in different parts of the world over time, and there’s also some stats out there on that.

The other sort of – this is from a high level, our next sort of venture into v6 is inside the data center. So we’re targeting towards v6-only data center and v6-only deployments. And I can go into detail when we actually talk about that. So I’ll be happy to share that when we talk about it.

Aaron Hughes: Thanks, Zaid. Alec Peterson is with Amazon CloudFront.

Alec Peterson: Hi, I’m Alec Peterson, as Aaron said. I’m with Amazon Web Services. We’ve been working on v6 in the background for a while. But we started announcing our support for v6 in 2016 starting with S3 support in the middle of the year, following with Route 53, WAF, S3 Transfer Acceleration and CloudFront in October.

And then we announced support for what most of our customers were waiting for, which was EC2, VPC, ALB and ELB as well. Since then we’ve also added support for Direct Connect and IoT, and as a large number of the Amazon services, the AWS services, are built on top of those building blocks, they now have the structure to be able to build on those.

So we’re thrilled to now being able to give our customers this IPv6 support, such as, in fact, helping enable the Comcast video platform as well. So we’re really excited about that, and happy to answer whatever questions we can on that. Aaron?

Aaron Hughes: Thanks, Alec. Since most of you answered where you were in your progress for deploying v6, I think, Hector, maybe we’ll come back to you. Where are you in your progress with deploying v6?

Hector Rios: As I mentioned, we started with v6 in 2008. And it started actually as a request that came from Internet2 when they had a meeting here in New Orleans actually. LSU was the host.

And we provided different networking requirements. And IPv6 wasn’t a requirement, but they wanted to have it at the conference. And once we started looking into the protocol, we became a little bit more interested about it. So we decided to implement it on campus at a small scale, basically within our building, in ITS, just so that we could get our hands dirty.

And that led into more investigation. We wanted to participate in the effort to support IPv6. So we had to do a full inventory of our network infrastructure, and we started to find out where we were lacking support or features. And that process took about two years, and eventually we deployed it campus-wide in dual-stack fashion. We participated in IPv6 World Day, and eventually IPv6 launch.

We work with the community to make them aware that we configure for dual stack. And as we started operating in that manner, we just continued to learn more and more about the subtleties of IPv6.

Aaron Hughes: Thanks, Hector. Why don’t we go to Zaid. What went into your decision to adopt v6?

Zaid Ali Kahn: I think the obvious one was the planet is going to run out of v4 at some stage, right? So that was something we wanted to head off. Business continuity, I guess, would be a good way to put it. If we’re out there serving, at the moment, more than 400 million users out there as we’re going to grow, we have to eventually sort of address this problem. So we want to get a head start on it.

And the other one was increasing mobile growth was a big factor. We realized very quickly emerging markets globally had no other option but to adopt v6. And we wanted to stay ahead of that curve. So I think that was the major self-contributing factors in that.

Aaron Hughes: Thanks. Alec, can you tell us a little bit about what drove your decisions to adopt v6?

Alec Peterson: Customer feedback drives better than 95 percent of our roadmap decisions at AWS. So ultimately it was hearing those demands from customers. Those demands, in turn, were largely driven by, I think, the things that have been talked about here in terms of the obvious exhaustion of IPv4, leading to network providers and viewer network operators needing to do unnatural things, like NATing and NATing within NATing to keep the IPv4 network connected, which creates natural performance constraints.

So we had customers saying they really wanted to be able to continue to connect directly to their customers and be able to grow that customer base without having to worry about those sorts of challenges.

Aaron Hughes: It’s interesting. You hear a lot of people say there’s no demand for v6. So it’s nice to hear an organization actually say we heard that from our customers.

Zaid, in a platform like LinkedIn, did you also hear customer feedback, or was this an internal-driven decision?

Zaid Ali Kahn: No, it was an internal decision. We don’t – our customers are, end users are – members are so massive, so much out there. But I think the way we look at it, we want to be able to keep up, right, with technology.

We also wanted to make sure that our members are having a good experience. And so if we didn’t take the leap on v6, then, to Alec’s point earlier, you hear about NATing over NATing. And so, at the end of the day, we knew that would affect performance.

So we want to make sure we have a v6 stack available that people can connect to. They shouldn’t have to come any other way.

Aaron Hughes: Hector, go ahead.

Hector Rios: I’ll make a comment from the customer side. It’s good to hear some companies that take a proactive approach. But from our perspective, it’s been a very frustrating road in the past few years when we engage vendors in different solutions that we look at. And we get two different answers.

One is that they don’t even know what IPv6 is, or they don’t have an interest because the customers are not pressuring them to implement it.

And just recently we evaluated a product that provided analytics and, again, we brought the equipment on campus. We tested it. And we knew offhand that it didn’t support IPv6, and we wanted to work with the vendor. But the answer back was that there just wasn’t enough demand for it, there wasn’t enough customers asking for it, so they had no interest in implementing it at the time.

Zaid Ali Kahn: Can I just add something? I just remembered, in terms of asks from customers, I did forget that we have a group that was selling to the US government, and I think the US government mandate was passed here.

That wasn’t like a major driver, but it was actually, to answer your question, if there was any kind of customer, that would be the closest. Just wanted to add.

John Jason Brzozowski: So one of the things for us almost 12 years ago was just v4 was too small. It wasn’t big enough for kind of the growth patterns. So for us it was early realization that it just – there wasn’t enough room out there. And honestly, v6 is so much more – so much simpler.

These days all the acrobatics you have to do with v4 is kind of gross. So every day that we go down this path we find there’s more and more reasons why v6 was and continues to be the right answer. The crazy gymnastics we have to do in some cases, or that we’ve seen had to be done in some cases, it’s just awful. It really is.

Aaron Hughes: Let’s move on to services. Start with Alec. What services today do you provide over v6?

Alec Peterson: Over v6 today, AWS provides dual-stack support for VPC, EC2, ALB and ELB, which are the Application Load Balancer and Elastic Load Balancer, as well as S3, Route 53, CloudFront, WAF, S3 Transfer Acceleration, Direct Connect, and IoT.

And all of these give customers the ability to operate either in an IPv4-only mode or in a dual-stack IPv4 and IPv6 mode.

Aaron Hughes: Zaid, same question. Which services do you provide?

Zaid Ali Khan: So for us, it’s mobile and desktop. Anything behind linkedin.com or what we call like sub-microsites around it, or v6, anything coming to the front and anything connected to linkedin.com is v6. And that’s why mobile – so including the client on here, plus your desktop, that’s pretty much all these things.

Aaron Hughes: Thanks. Hector, same question. What services are you providing over v6?

Hector Rios: So as I mentioned, we’re dual stack across the network. We support IPv6 on our wireless. So every wireless host that connects to our wireless will get both a v4 and a v6 address. Even on our VPN for remote access into the campus, we provide also v6 address.

We have worked with some departments on campus so that they can enable their websites for v6 accessibility. We have some wikis that are used by staff and students that are v6-enabled.

And about three years ago our main sites supported v6, and due to some challenges that they had with a content manager solution and a load balancer, they had to disable support for IPv6. So we don’t have IPv6 support with our main site anymore.

John Jason Brzozowski: So beyond what we’ve talked about already, video and data – voice is still something that’s in the works for us, but it’s less interesting to this crowd. Our public Wi-Fi, XFINITY Wi-Fi, is dual-stacked enabled, our CVN.

And basically everything that we need to fuel the business, our own internal cloud plus the work that we do with third parties, it’s really mandatory for us. So anybody who wants to do business with us has to support v6.

Aaron Hughes: Could you talk about some of the specific steps you took to deploy v6?

John Jason Brzozowski: Any area in particular?

Aaron Hughes: Your choice.

John Jason Brzozowski: So I’ll say back in 2005, the first three years were pretty fruitless in the sense that we spent the better part of three to four years doing a lot of prep work – writing the network, enabling v6, upgrading back office. That’s probably the piece, Aaron, that took us the longest.

But this is back from 2005 to 2008. Frankly, going even further back, we had to create v6 for DOCSIS. It wasn’t there in 2005.

So we did that. And then worked with all the vendors to get everything tested, deployed and ready. For people who understand how cable networks work, CMTSes all had to be developed, tested, hardened for v6.

And then along the way is really – I think there’s one word that comes to mind, it’s incrementalism. Even though the graphs are all very pretty and up and to the right, in a very short period of time there’s a lot of engineering that went into making sure that we had an incremental approach to migrating things to v6.

So for us it was making sure that we developed the technology and tools to really allow for that to happen. And that principle really ARIN applies to everything that we’ve done, whether it’s a cable modem in your house or commercial DOCSIS system, like in yours, or video or what have you. There are – incrementalism was key.

Aaron Hughes: Certainly. Alec, same question.

Alec Peterson: So I think John said it well; that taking incremental steps is important. Looking at it a layer deeper, from a technical perspective, we definitely started from the network layer and worked our way up.

With AWS built as a variety of utility services on top of the network, we needed to obviously make sure the network was ready, because going to having the services go to IPv6 before our underlying network would do it, you know, just logically doesn’t – wouldn’t make sense there.

So from there, once the network was ready, we then empowered all of our service teams and encouraged them to prioritize IPv6 on their roadmap based on what they were hearing from their customers as well as the initial overall plans that AWS had. And then that led to where we are today.

Aaron Hughes: Thanks. Zaid or Hector, you want to add for particular deployment steps?

Hector Rios: All I can say for us, like I said, we had to do an inventory over network gear to see where we needed to either replace or upgrade. Looking at our addressing scheme, we started with one particular scheme. And the way we did it, we were so used to working with v4 and being conservative, et cetera, and we hadn’t grasped, you know, the immensity of the IPv6 space.

And once we got used to that and learned that you don’t have to be as conservative as you are on v4, we redesigned our addressing scheme so that it would be more flexible.

In it, we were able to embed information that would help us in troubleshooting, like adding VLAN information or loop-back information, things like that.

And I guess what made it easy for us, is the fact that it’s – because it’s dual stack, it’s almost like a seamless transition.

Zaid Ali Kahn: For us, I sort of look at 2014 as sort of a pivot. Before that we spent two to three years making sure the infrastructure was ready, including the backbone and everything. We were already ready for, like, almost a year prior to sort of the app going to launch. But we were building new data centers, we were making sure that anything we did was v6-centric or dual stack everywhere.

And then when we sort of got closer to 2014, in order to go to the developers and say we’ve got to turn on v6, we wanted to be absolutely sure that we got our ducks in a row on the infrastructure side, which really helped, sort of, the case – if you want to convince your product folks that, hey, you’ve got to support v6.

So that was where we spent sort of the majority of the chunk, like we have thousands of services sort of behind linkedin.com that would have to eventually understand how to talk to v6.

The thing we did instead of making sure all the back ends could speak, we just focused on the front end. So one thing that we do is we have software load balancing on the edge, so we didn’t have to deal with any vendors from a load-balancing perspective.

So we ended up putting the features that we wanted in the software. So we were able to say, hey, don’t worry about all the back end; we’ll just translate for you and then serve you v4 on the back end. So that way we could sort of terminate v6 from an end-user perspective.

Those were the two things I would sort of point out that were critical in our decision-making. One was how do you store the v6 address? Right? Prior to that, that’s where a lot of the debate was because before, sort of looking at v6, people were storing in various databases inside our data warehouse in text format.

And in v6, because it can be stored in sort of multiple formats, multiple ways, you can write it, querying becomes a little bit more complicated. So you really need to move to a binary form of storage of the v6 address space. We had to sort of spend a bit of time figuring out how do we transition that without – and supporting the old one while moving to the new one and eventually deprecating that.

The other aspect was also to figure out how do we handle abuse on the site and scraping and those kind of things.

So we had to sort of, like, put a lot of effort in that area to make sure that when we launch, that we have pure visibility into our end users and also making sure that those security aspects are taken care of. Those were sort of the big pivotal points.

Aaron Hughes: Thanks for that. Obviously with any kind of technology change you make in your organization, there’s always going to be things to think about. Sometimes they’re relatively simple and sometimes they’re fairly challenging obstacles.

Perhaps you could share one or two obstacles you’ve come across through deploying v6 and what you did do overcome those obstacles.

And we’ll start with Alec on this.

Alec Peterson: Sure. We actually had a couple of interesting ones that I think will provide good learnings for folks who are still moving down the deployment path.

One was on network layer itself. And this related to Path MTU Discovery, where we found that when we turned on v6, we found a variety of components, both in our network as well as external to our network that weren’t actually passing ICMPv6 Packet Too Big Messages. They weren’t actually passing the IPv4 ones properly either.

But because of the number of providers out on the Internet that are still using 6in4 tunneling, you have a much higher likelihood of v6 traffic actually being subject to those sorts of Path MTU Discovery issues.

So I think the one big takeaway we had there was to make sure that your entire network infrastructure, and that you work with your providers to make sure their network infrastructure, is passing the Path MTU Discovery messages for both v4 and v6 just for good practice, uninhibited, because that can cause all sorts of very-hard-to-diagnose network problems in that network layer.

Higher up, we found these weren’t issues that we ran into in terms of in production, but we found these problems in our analysis, specifically that when you’re in a dual stack world, assumptions are different than in a single stack world.

And if you’re looking at how an application will use the IP address, sometimes you’ll have what we refer to as customers doing serial connections to divergent endpoints.

So, for instance, you might have a customer who is trying to get some authenticated content and they would go to a vending service and request that and request basically a credential for that authenticated content. That credential oftentimes contains the source IP address of the requesting client as part of the authentication.

So you can really constrain who can actually use that credential. In a single stack world, that assumption works out pretty well because you can easily operate under the assumption that the first connection to the vending service will come from the same source IP address as the second connection to the actual content service.

But that’s not true in a dual stack world because your vending service could possibly – even if both your vending service and your content service are both dual stack, the notion of dual stack is that either – if you reach either endpoint, either one is good. So you might connect to the vending service over IPv6 and you might connect to the content service over IPv4 or vice versa.

So those are the kind of things you need to pay attention to with your specific application and use of dual stack, to make sure you factor those sorts of things into account.

Now, there are ways by both making the client and the – the client, the vending service and the content service aware that they’re operating in a dual stack world that you can address that challenge.

But that requires work beyond simply making the application dual stack. So I think the biggest lesson there is dual stack is not just a drop-in for any and all applications.

You need to look at your application and make sure you’re not going to have that kind of assumption about the consistency of the network layer address across serial connections, because dual stack does break some of those assumptions.

Aaron Hughes: Certainly seen that before, even like auto reloading pages where authentication has happened and we’ve bound to an IP address and it flips and all of a sudden you’re logged out. Very common to see. Yeah.

John, want to share some of your obstacles, how you overcame them?

John Jason Brzozowski: There’s so many. Not enough time. Keep talking until Wednesday.

I think the one that I’m sitting here pondering as I’m listening to Alec, lately there’s been a resurgence of CPU problems, things like you buy from a retail perspective, like you go out to Best Buy, buy some gear, and at one point it did v6 and now for some reason it doesn’t.

And I call this one out in particular because it’s like Whack-a-Mole. You don’t know when it’s going to pop up, but it pops up at the worst possible time. Then you have to figure out how to chase it down and get it fixed.

So one of the things that I – and this is pretty recent even. Even, you and I have exchanged some emails about this.

There’s some other things that we’re seeing, even the past couple of months. It’s one of those things where it would be super if we had a – like all the people who introduced these CPU devices into kind of the retail ecosystem did so in a more responsible manner, right?

We find them. We find them and then we fix them. But unfortunately one of the cornerstones for our v6 rollout was the commitment that we made is it wouldn’t be impactful to the customer. So what ends up happening is in some cases our customers notice. Very small. But it’s something that I personally take very seriously.

Aaron Hughes: Zaid, want to share any obstacles how you overcame them?

Zaid Ali Kahn: Yeah, I’m just trying to think of ones – so Path MTU was definitely one. Early on we discovered that, and we had to put fixes around that.

That was kind of an easy one, but we had to discover that along the way because we were doing canary tests and we’re seeing things up front and people putting Twitter messages, Hey, I see v6 on LinkedIn, and having some problems. And that was interesting. But we had a very small rollout at that time.

As we started to get closer to the rollout, I would say that sort of – I’ve talked a little bit about sort of the storing of IPv6 addresses, so I won’t go into that, but the other one was just sort of understanding the impact it would have on the customer.

So forefront, one of the big things we did was, like, making sure that we’re able to measure v6 performance, and that was one of our sort of gaming factors. We had to – before we rolled out, we had to make sure we measured it. We deployed raw measurements to make sure.

And in that process, I think we found our CDN providers just weren’t deploying v6 as wide as we would have liked them to.

So taking those measurements and sharing that data sort of really helped our CDN providers get to the level of deployment that we were actually comfortable with for rollout, and that’s what we used to sort of drive the CDN providers to get – that was sort of one of our bigger obstacles.

And then once that sort of happened, then we were able to sort of pick a date and do the launch and all those things. So that’s where I would say there were bigger obstacles, yeah.

Aaron Hughes: Thanks. Hector, anything you want to share?

Hector Rios: Like John was saying, there’s many, many challenges with IPv6, in the beginning, through the course, and in the future. Early on at our university, we have a mechanism to allow hosts on the network.

We require MAC address registration. And when we started implementing v6, because this registration relies on both IPv4 and DNS, we quickly realized that if we implemented v6, we were going to automatically provide network access to our hosts even if they were not registered.

So the workaround for that was to only provide a v4 DNS so that we could still continue to control their access. And our DNS server would provide both, an inquiry of records. That was a workaround. We don’t have the best security for network access at the university, but what we’re looking into the future is to implement that one next.

With that came more challenges. We just acquired our new RADIUS solution. And even when you do all your homework or you come to running into surprises, we found with our RADIUS solution that we were not capturing the v6 address in the accounting records.

So, again, we just didn’t do our homework right, and we found this issue, and we’re working with our vendor to try to resolve that. And it’s just a bunch of weird things that you run into.

In our border router room, we were implementing it, upgrading it a couple of years ago. We couldn’t implement an ACL to control our SNMP access. And the workaround for that was to create an ACL for v4 and v6 with the same name and apply it. So a lot of weird stuff like that.

John Jason Brzozowski: One clarifying comment. I don’t want to sound like Debbie Downer, talking about so many. Just a piece of context for everybody who is listening, this is like a 12-year project. And I say that, like, tongue in cheek. So we’ve seen a lot of things early on that I know a lot of people in this room will never see.

So when we talk about like the host of issues that we’ve seen, we’ve seen them and conquered them and put them away, and they don’t, generally don’t, come back.

I don’t want people to take away, Hey, there’s so many problems. I don’t want to be the guy that somebody here says, I’m not going to turn on v6 because that guy from Comcast said so, right?

Aaron Hughes: We certainly appreciate the early adoption and working with vendors to take on some of those bugs first. I’m sure everybody can appreciate that.

So maybe let’s look at this from a different perspective and talk about investment. All these organizations are different sizes and different flavors.

For those people who haven’t implemented v6 yet, what kind of departments or staff would you recommend people get involved in the investment for deploying v6 for them and maybe for your organization, just when you think about this process? Obviously you’re talking about a 12-year process. That seems like a big investment.

Maybe we’ll start with you and we’ll move down the line.

John Jason Brzozowski: We were pretty fortunate, honestly. Some of the key leaders for us early on had made the decision. We didn’t really – I think the biggest thing that kind of kept us honest was making sure that we didn’t – we assumed that we were operating on a zero dollar budget, right?

I was telling somebody earlier, I can’t remember who it was now, but basically that’s still pretty much the case. We didn’t really – there’s only one system in particular that we had to actually have a dedicated budget for. It was our provisioning system. We had to accelerate and upgrade there. Otherwise we basically rode on the coattails of everything that happened in the network.

And I don’t claim that my scenario is kind of – it’s probably the exception to the rule, right? I think people that – the list of people to engage is everybody from anybody who cares about the customer experience to people who care about how are we going to get v4 addresses if we’re going to want to continue to grow.

They have financial implications. They have planning implications. You can even talk to people from mergers and acquisitions and say, hey, we want to go and buy companies. So how is that going to work?

So, I mean, for us it started with people on the infrastructure network side, and it really fanned out from there. And I think most product people, they don’t care about v4. They want certain – they want it to work.

So it’s really a mix of people that you gotta talk to. And, like I said, fortunately for us we had some leadership that had great vision.

Aaron Hughes: Hector, being from a university, I imagine your experience is quite different. Maybe you can share who you got involved in your v6 deployment.

Hector Rios: So I guess the vision started with us, because we had the understanding of the technology and the impact. The challenge was to be able to translate that into something that the university understood and was able to support. And it, again, continues to be a challenge.

So I think the key for us, we just have a new chief technology officer. Our previous CIO, chief technology officer, I mean, there were too many things on their plate.

And when you bring something like IPv6, I have to assume that it’s not a big priority. So I think getting the buy-in from your CIO from a university is huge so that he can be the person that translates the importance of v6.

The university moved away from an old mainframe system into a new ERP solution that’s hosted in the cloud and unfortunately doesn’t support IPv6.

So I don’t have any power over those decisions. And when you bring up something like that to people that don’t understand it, they’ll push it to the side.

So even with things like that, it’s really difficult to get across the idea of how important IPv6 is. So, but again, from the networking standpoint, I mean, because we understand, again, the impact and the technology, I think is incumbent upon us to do our best to try to gain support from as many people as possible. Again, starting from your CIO and as many other people as you can.

Aaron Hughes: That’s actually something I’ve heard quite a bit in deployments is that this technology, unlike most, requires upward management and education in other departments that’s different than a lot of typical technology changes.

Zaid, I know LinkedIn has a – treats their customer experience as absolutely critical. Can you talk about who you had to get involved in LinkedIn?

Zaid Ali Kahn: Our experience is a little different. We don’t generally have to get much buy-in from management. My organization is responsible for making sure the infrastructure is up and can serve. So it’s easy for me to go in and do v6; we need to do that.

However, I still need to work with my peers on various product groups to make sure that they would support turning it up at sort of a timely pace.

So, I would say that sort of the bulk of that went to trying to convince other folks that, hey, this is a priority this year as opposed to last year and sort of dealing with that, because we are – it’s always competing with various features and all those things.

So what I ended up doing was finding a few champions, one or two – one in very, very particular – who saw the value and said, hey, I’m going to go champion on talking to thousands of developers and giving an influence.

So I have found a partner on that side who really was like, hey, we gotta do this now. And went and talked to various project managers, product managers across the board to make sure. But even sort of prior to that, I think I just gave one presentation to sort of exec staff at LinkedIn and said, here’s why – and then everyone just nodded their head, and then I had to go figure out how to make it happen.

So coming back, my advice would be just finding the champion, right, that will help you to get the message across and to get it into the timelines that you want. That’s sort of where I think we focused on.

Aaron Hughes: Maybe we can convince ARIN staff to design some v6 pom-poms for the champions.

Alec, how about you?

Alec Peterson: I think Zaid really hit the nail on the head there.

The key here is to find the people who are responsible for prioritizing roadmaps and convince them, make them, get them to believe that they need to prioritize it.

And it’s going to be different for every organization. If you’re a network provider, it’s going to be different from if you’re a computing infrastructure provider, versus if you’re a consumer-facing entity.

But all of those stakeholders are going to be either directly or indirectly affected. And the one thing they need to realize is that they may not be hearing the feedback from customers now, and that’s dangerous.

Because the further away their customers get from the nitty-gritty of the network details, the less likely they are to have the foresight to realize they need v6.

And what’s going to happen is those customers will only be complaining by the time it’s too late and there’s already customer-impacting deterioration and performance and customer experience.

And by the time that happens, it’s going to be a lot of time between that and when you can actually get v6 deployed because it’s a project and it touches everything.

Things like anti-abuse systems. You have anti-abuse systems that are built on the notion of unique IPv4 addresses. All those assumptions change. So if you have anti-abuse technology involved there, they need to get involved.

Metering systems, accounting systems, all those sorts of systems that process log data all need to be changed.

So getting those stakeholders involved early and often and having them realize that by the time it gets to the point that enough customers are complaining, and your senior leadership and your CEO is complaining, you’re not going to have a good answer. You do not want to be that guy in that position or that woman in that position.

Aaron Hughes: Thanks, Alec. So let’s swing the pendulum and leave the challenges for a moment and go to benefits.

Thinking about your organization, either from an internal perspective or your customer’s perspective, have you seen any great benefits to enabling v6 in your infrastructure? Maybe we’ll start with you, John.

John Jason Brzozowski: So I have several different customers. So I have the customers on the broadband network, video, what have you.

The simplicity has been – v6 is so much more simple, and the customers are really the beneficiary of that. And the opportunity is on us to basically leverage v6 to be able to do that.

Things like being able to manage how we provision and deliver the actual services using v6 compared to v4, omitting all the acrobatics that come alongside with v4. Even performance benefits. We’ve seen opportunities there for performance benefits that ultimately are going to fuel a better customer experience.

And then flip – internally, on the flip side, my coworkers are my customers. So one of the things I often say is if we would have launched v6 and I didn’t put the tools into my coworkers’ hands, I had two choices: either be the most hated employee in the company or do all their jobs for them.

Neither was an option, right? It just can’t be done, either one. So we have lots of people who work at Comcast, and not putting the tools in their hands is just not fair, right? Couldn’t run a business that way. Again, while trying to improve the customer experience. Right?

So I’ve got customers on both fronts. And, again, I take that very seriously to the extent where I want to make sure that everybody has a solid, great running network to do the things they need to go ahead and do.

For us, I’ve seen some pretty gross things from a v4 point of view that, like, I sat there and I scratch my head and I say, I can’t believe that actually works. And v6 was a great opportunity to simplify it. Those are all internal symptoms that most regular customers would never see.

Aaron Hughes: Hector, how about you? From a university perspective, any great benefits from enabling v6?

Hector Rios: I think one of the main benefits is the awareness that we’ve been able to raise just because of us supporting IPv6 from my team’s perspective. I mean, we do have a lot of experience, so we know how to deal with issues.

But the rest of the community for those – they all get exposed to v6 all the time. So for those that don’t know, it raises their curiosity. And we’re available to provide guidance. We have the documentation, again, for people to know.

And so the hope is that by having it in place, you know, when there are conversations about anything v6, it’s not something that’s forgotten.

At the same time, we’ve had a few instances where, because we’re dual stack – I can remember one instance where our provider experienced an issue on the network, and the issue had been specifically on their v4 part of the network. And v6 was working.

So it was nice to see that at least we had some redundancy built in because of IPv6. Only the resources that were reachable via v6 were available. But, again, there was some benefit that we hadn’t thought of.

Aaron Hughes: Totally seen that, been locked out from v4 and been able to get in via v6 and help resolve the problem. Absolutely awesome.

Zaid, how about you, benefits from enabling v6.

Zaid Ali Kahn: Sure. I think earlier I mentioned about measurements. I talked about RAM and how we deployed that. So when we launched, we just wanted to make sure that that v6 was performing as good as v4. That was sort of the notion we went with back in 2014.

And then, like, having those measurements in place, you know, we’ve been checking and making sure that there are a lot of folks that are monitoring the site, that are starting to give us some data. And we started to see that, that in pockets we saw v6 was performing better than v4.

And I guess one of the unique things is on a mobile app, because we control both ends, we’re able to actually see more than most desktop applications, right?

So we were able to then get direct messages from our clients through our mobile providers. And we were able to see in some pockets, like, three to five to even up to, like, 10 percent or even 15 percent in some cases, depending on which mobile provider it was.

And that was like sort of a pleasant surprise, like we didn’t expect that, but we actually saw that mobile, certain mobile carriers, like, we actually saw performance improvements on v6.

Aaron Hughes: All right. Performance, education, simplification. Alec.

Alec Peterson: As an infrastructure provider, we’ve definitely heard from our customers that by having them be able to now deploy v6 is certainly letting them remove that from their checklist of things they don’t have to worry about.

But a lot of our customers still have to operate and do a lot of the gymnastics that John mentioned in terms of supporting IPv4.

So from that administrative overhead standpoint, it hasn’t provided the ultimate benefit of being able to do everything over v6, which is certainly what we’re shooting for.

But being able to now have a clear path towards when we finally get to the point where v4 is just not tenable has definitely provided a huge benefit to our customers.

John Jason Brzozowski: One more, Aaron. So innovation. One of the things that we’ve also been able to really realize, from our point of view, is if you can break out of the mindset that v6 is absolutely not v4, the opportunity for innovation is extraordinary, especially in this time for IoT.

I almost feel like I have to go to confession for even saying IoT. Catholics in the room, you know what I’m talking about.

But IoT, the opportunity for innovation in the home, in particular, with v6, we just have that much more room to innovate.

I mean, as long as you don’t get stuck in the mindset of trying to treat v6 like v4, there’s enormous opportunities out there – everything from how do you advance to state of the art in the home to things like v6 segment routing and everything in between.

Aaron Hughes: Waiting for Cathy to jump up and scream Homenet and Babel.

(Laughter.)

Aaron Hughes: So there are a lot of people in the industry here who are looking at you as leaders and experts. If you could give any one piece of advice to the listeners out there about v6 adoption, what would it be? And maybe we’ll start with you, Zaid.

Zaid Ali Kahn: I would say put measurements in place. Like start measurements early. You can’t – if you want to fix something, you need to make sure you measure it first.

So you won’t be able to see the problems. You won’t be able to address them. I would say that would be sort of my sort of one advice. And from an external perspective, like if you’re a content provider.

The other little advice, I’d like to give some experience we’ve had recently, was that we’re turning up a lot of v6-only or even dual stack inside our data centers.

We’re actually finding that we have to think v6 from day one, have to start thinking that, how to deploy zero-touch provisioning, those kind of things, so that when you start to think in that area, at some point you say to yourselves, Why am I supporting dual stack? It becomes an overhead – operational people say, I don’t want to serve dual stack, I just want one stack.

So then it sort of starts to get your mind and your thinking to that direction. And I think at that point you realize that you will only start to think v6-only.

So I’m just going to give two different perspectives of where you could actually get a lot of benefit out of.

Aaron Hughes: Thanks, Zaid.

Hector, how about you? Any advice you want to share with the industry?

Hector Rios: I guess the only comment I can make is it’s not as hard as people think. And, especially, I think we alluded to the fact we’ve been the ones that have been beta testers in a way.

We work with the vendors trying to solve the issues. But now, if we were to implement it now, I know that it would be a lot easier than it was when we started.

A lot of the – for us, networking products out there already come with built-in IPv6 support. So it’s not even a question now of are we making an additional expense, things like that. It’s already enabled.

So, again, just getting your hands dirty and knowing the fact, again, it’s not as hard as you think.

I would say for universities or anybody that has large wireless networks, you do need to do your homework, because v6 presents some unique challenges because of – it’s a little different than v4 and because you’re supporting a dual-stack environment.

To your point, at some point, yeah, we’d like to make transition to v6-only, but we’re not there yet. So we have to make sure that the gear we’re buying is going to be able to support both protocols.

Aaron Hughes: Thanks, Hector. Alec, advice to the industry.

Alec Peterson: I’d say follow the Henry Ford principle: There are no big problems; there are just collections of small problems.

So don’t look at v6 as, oh, my God, I have to convert my entire network and application stack, because you’ll look at it and you’ll just say, I can never get that prioritized.

Find a piece of it. Find a meaningful piece. See if you can get a piece of your network going. Just make incremental progress – to the comments that have been made earlier about incremental progress.

That’s an essential attitude because if you start making progress, then your peers at your organization will start to see that progress being made and really see v6 as the way forward. So start early and start small.

John Jason Brzozowski: I think you have to be the ball. What I mean by that is at work I would say be the packet, but you guys don’t work enough with me to know what the hell I’m talking about if I say that.

So I say be the ball. What I mean by that is you have to know what you’re working with. You have to know what about v6 matters to you to solve real problems.

If you don’t do your homework, and if you don’t understand how it works – and it’s really not as hard, as Hector said. I mean it’s at least a lot less hard than it was 10 years ago.

If you don’t know what ingredients you have to work, you don’t know how great of a dinner you could possibly make. So that’s really the analogy I leave you with – you have to know what it is that you’re working with so you can solve real problems.

If you’re just making stuff up, your odds of success are pretty low. But if you understand what exactly it is you’re working with and how to solve real problems, you’ll be very successful with it.

Aaron Hughes: So somewhat similar question but we’re wrapping it up. So when you think about this whole process, what is your key takeaway? We’ll start with you, Alec.

Alec Peterson: See, I would say my key takeaway from this whole process is that it’s great to be done and be in a position of having it there, and I think just reinforcing the fact that get started now.

I think that, as with any big project, you look back on it and you say, wow, it was a lot of work. But it would have been great to be done sooner.

So the best way to be done sooner is to start sooner. So start now. That would kind of be my biggest takeaway.

Zaid Ali Khan: I think my key takeaway would be in the lines of it is simple, it is not as hard. Right?

And I think the other thing is that as you get more into it, as you start to measure things and if you start to sort of look at sort of technologies that are inside your network, innovation becomes a lot more simple.

Like everything is simple in terms of v6. So once you start to have that kind of mindset, like, it becomes really exciting and the window of opportunity, like John was saying, sometimes you wonder how you did that in v4 – the same kind of thinking.

So I think that, to me, is sort of like – that’s what excites my team and my engineers. They get really excited on v6 projects because then they have all these new things that they can do and new ways of looking at things.

Aaron Hughes: Thanks, Zaid. Hector?

Hector Rios: I would say that it would be great to say that we’re glad to be done, but we’re not done. It’s, again, a work in progress.

The key takeaway, though, is the fact that we’ve been doing it for so long that any new challenge that is presented to us, we can tackle it.

Again, today we provide IPv6 addresses via Slack. We have a new IPv6 – I’m sorry, DSCP solution in place. DSCP v6 is the next thing for us. And after that is going to come getting rid of v4 and go v6 all the way.

So, yeah, we’re not done. There’s a lot more work to do, but, again, we’re doing it as we go and learning a lot.

Aaron Hughes: Sounds like back to incremental.

John, key takeaway.

John Jason Brzozowski: Have an open mind. v6 is not v4. Don’t bring any of the baggage forward. Be creative.

Aaron Hughes: Thank you. First, I’d like to thank all the panelists for their time and support and being industry experts, sharing this information with you and everybody that’s listening.

Really appreciate it. Also a thanks to Jennifer Bly for helping putting this panel together.

(Applause.)

John Curran: Thank you, Aaron, for your able moderation.

We’re now going to have our lunch, and then we’ll come back and do some policy sessions.

So, couple of things. There’s lunch table topics. When you go out to lunch, you’ll see a few of the tables in the lunchroom have topics on them. And if you want to talk about that topic, it’s easier to do if you sit at the table where other people are talking about that topic.

Not that you can’t sit at a different table and yell back and forth. But it’s easier if you try to get to one table.

So, joining the AC is one of the topics; increasing participation in ARIN is one of the topics; and who uses Whois and RDAP is one of the topics.

So, we try to have topics at the lunch tables to help people have topics of conversation. Gather at one of those tables if you’re interested. Let’s see. We have a special lunch. Someone has the clicker.

John Jason Brzozowski: No v6 table, man?

John Curran: You can create a v6. Find John if you want a v6 discussion.

John Jason Brzozowski: I’ll be at the bar.

(Laughter.)

John Curran: That’s for the people who haven’t gotten it done yet.

Next slide. Someone has my clicker. Thank you. Yes, Women’s Networking Lunch. There’s a Women’s Networking Lunch in the Royal Salon. Want to go talk about that? That’s back where we had Sunday’s programs, you run down there.

And security. This room is open. Take your valuables with you because it’s not locked. So we want to make sure that the people who go with your valuables are you.

Come back at 1:30 and we’ll start. We have excellent presentations – Policy Experience Report and a couple of new policies to take up. Thank you.

(Lunch break.)

Welcome from Network Sponsor: Cox Communications

John Curran: Okay. I’d like to welcome everyone back. We have an interesting and fun-filled afternoon. I’d like to – do we have slides to go through? Yes, oh, very nice. They’re here. See, very nice.

So we’re going to do – this afternoon we’re going to handle a welcome to our network sponsor. We’re going to have Jeff Finkelstein from Cox Communications come up and talk a little bit about what they’re doing and welcome us here.

We have a Policy and Implementation Experience Report. John Sweeting will come up and give that, talking about what we’ve learned implementing one policy.

We have two draft policies to discuss, 2017-3 and 2016-8. And both of those should be interesting, regarding annual Whois POC validation and indirect POC validation requirement.

It’s green. Let’s try it a little closer. Can I have a little volume on the main mic? Okay. Wow. I usually don’t have that trouble. Actually, I have the trouble that people hear me even if I don’t speak into the mic so they don’t know it’s off.

We’ll have refreshment break after the two draft policies. We’ll handle the IETF Report. Cathy Aronson will come up and give the IETF Report.

The NRO Activities Report I’ll give, and we have an Internet Technologies Health Indicators Report that I’ll give. And then we have closing announcements, and then we have our social tonight.

So should be a good afternoon block. I’m now going to invite Jeff to come on up and say a few words. Jeff, go ahead.

Jeff Finkelstein: Afternoon, everyone. Just wanted to take a minute and say thanks very much for having this event in New Orleans, one of the jewels of the Cox Communications markets.

We’ve spent a lot of time and put a lot of effort into making this city one of our premier and diamonds-in-the-rough markets.

As you know, after Hurricane Katrina, we lost a significant portion of the city and has been rebuilt, a lot of effort, so I’m hoping y’all are enjoying yourselves. If there’s anything we can do to make your stay more pleasant, please let us know.

I’m hoping the networking is working out for you. We’ve put a lot of effort into meeting the needs of ARIN and getting a lot of bandwidth brought into this fabulous hotel.

So for those that don’t know, the Monteleone has been around since 1886. It’s family-owned. And as the saying goes, as the French Quarter in New Orleans is the birthplace of jazz, that the French Quarter starts at the door of the Monteleone.

It’s a very interesting building. It’s been expanded upon. Typical employee tenure is about 30 years. There are folks that have been with the Monteleone about 60 years.

So it’s very interesting, and I’m hoping that you get a chance to go around the city and enjoy yourself.

We’ll warn you, things go south very quickly in New Orleans, especially late at night. Just keep your eyes open. Keep your hands on your wallets and purses.

(Laughter.)

Jeff Finkelstein: And especially watch out for the Sazerac. But I do recommend y’all give it a try in small quantities. Last thing we want is to wonder where somebody is and find out that they’re at one of the hospitals in the area.

Please, if there’s anything we can do to help, I’m going to be bopping in and out, because I have to juggle a bunch of things simultaneously. But we truly, truly are honored, because just as this is the birthplace of jazz and this is the gem of the city, ARIN is what keeps the Internet running.

And thanks to John and the rest of the staff for helping us through these many years.

I’ve been with Cox a long time and have known John quite a long time as well, and he’s bailed us out on a number of occasions, as has some of the wonderful ARIN staff.

Thanks very much. Laissez les bon temps rouler. Let the good times roll, just not too much. Have fun.

John Curran: Thank you.

(Applause.)

John Curran: Wonderful. Good to have a great sponsor here.

I want to get started with the first presentation, which is the Policy Implementation Experience Report. And I will have ARIN’s new Senior Director of Registration Services, John Sweeting, come on up.

Policy Implementation and Experience Report

John Sweeting: Thanks, John. I always prefer to be called new than old. Even though it’s pretty true.

Okay. Welcome back from lunch, everyone. I hope everyone had a great lunch and enjoyed it.

I’m going to give a quick presentation on Policy Experience Report. And what I’m going to talk about, I only have one to talk about, and it’s going to be the waiting list policy, which is in the NRPM. It is 4.1.8, unmet request.

This policy was implemented in January 2010, but we didn’t have to use it until July 2015. That was the first request that could not be filled from the free pool and ended up going on the waiting list.

What it says right there, justified requests that can’t be met, they have the option of being added to the waiting list. The way to get on there, if it’s initial, you can qualify for a /21 if you’re an ISP or a /24 if you’re an end user. That’s approved without justification.

Larger blocks can be approved, but they’re based on a 24-month justified need. You can also – if you qualify for, say, a /16, you can say the minimum you’ll accept is a /17, a /19, a /20. And that way, if one of those block sizes become available, you can be offered that.

But if you say, no, the smallest I’ll take is a /16, then if no /16s become available, you will get skipped over on the waiting list for a block – if a /20 became available, it would go to the first person that was willing to accept a /20. And, of course, oldest requests are filled first.

Some of the other rules around it. Each Org, you can only have one request on the list at a time. Any requests that are met by transfer are removed. And by “met” it means if you go out and get any address space through the transfer process, you are removed from the wait list.

Once a block becomes available, you’ll be notified on the wait list. You’ll have 60 days to pay the registration fee and sign the RSA, if that’s required, if you aren’t currently – have a current RSA signed.

There is some basic revalidation done. That’s just making sure your organization is still active, that your account is current, you’re not behind in paying and a few other things.

Normally there is no additional justification required, unless you’ve recently completed an 8.2, say, merger and acquisition transfer, and you told us you acquired, say, a /12 in that merger and acquisition and 0 percent of that is being used and you’re on the waiting list for maybe a /16 or something, we are actually going to then ask you to justify why you really need that /16 after you’ve acquired a /12 that you’re not using. But for the most part, additional justification is not required.

There’s a three-month waiting – once you get a request filled, you then have to wait three months before you can be added to the end of the waiting list again.

Some of the items I’ll review real quick here, waiting list outcomes, wait time, review process, and disaggregation. Man, I sent the wrong – okay.

So good news is that it’s working. Of 622 requests that have been added to the wait list since July 2015, 195, or 31 percent, of those have been filled.

136 of them have been closed and removed from the list. Most of those were through – they got space through the transfer market. There was two that opted not to accept the block and two that didn’t pay the registration fee within the 60 days of time limit.

And there’s currently today there’s 291 that are still waiting. The oldest one of those being 31 July 2015, a switch was a /16.

Of the 195 filled requests, the average time to fill them was 15 months. Median was 17 months. The longest wait was 24 months.

Of the 136 closed requests, average time was seven months. Median five months. And the longest wait time, 21 months. And that was filled via a transfer.

So we have a very strict review process for the wait list. As returned and revoked blocks, we have a couple of analysts that go through and review those. They make sure that they’re not routed. If they’re still routed, then we have some additional measures we have to take to make them available to be reissued.

We also need verification the return or the revocation was done properly, which on the return there’s a letter that has to be signed by an officer of the company saying yes, we really do want to return these addresses to you.

On a revocation, there’s several steps in the process that are – Val and her team take care of through FSD to make sure that everybody is given every chance they possibly can be given to pay that bill and not lose those resources.

So we have to make sure that all of those steps were followed. Then once we get a list of some space that has been deemed qualified to reissue, we’ll hold a management team meeting. We’ll have a legal review in there.

There’s four management team directors meet – myself from RSD; Val from FSD; Michael, who does the legal; and Nate. We all have to convince Nate that hey, we followed all the process on this and these are ready to be reissued.

Nate then will either sign it or tell us to go back and do some more homework. Usually he’ll sign them. But it’s always good to have that last review there.

Currently we’re reviewing 20 to 40 blocks each month. And there are 354 blocks that are currently in that process that have been returned, revoked, and are being reviewed.

Now, there’s a certain timeline. We wait six months past – any block that’s been revoked, it takes six months of it not being paid before they get revoked, and then we wait an additional six months before we even review them to reissue them.

This is just a chart that shows you there was 138 prefixes have become available to be given back out, and we ended up breaking that into – it ended up 195 prefixes that were reissued. So there was a gain of like 50 percent on that. So not too bad, but I guess not – in the whole scheme of things, it’s not too bad.

So that brings me to the last slide, some policy issues to consider. While the current mechanism is working, but it does highlight the question of what is the underlying goal of the waiting list. Is it to provide a timely way to actually match an IPv4 block supply to the demand of qualified recipients?

Well, the answer to that is it’s not really timely, as some entries are multiple years old. And their original need gets overtaken by events, satisfied by transfer market.

So should the waiting list entries last indefinitely, and the other question is, or should we use the waiting list to provide a last resort for organizations that actually need a small amount of IPv4 resources, and they can’t even participate in the transfer market, maybe because they’re a not-for-profit or they just don’t have the means.

So the current process doesn’t seek to provide a minimum assignment to the maximum number of organizations, but instead it allows the waiting for larger blocks.

Also, it doesn’t distinguish between organizations that lack the financial resources, smaller entities versus larger, and not-for-profits versus for-profit.

So we would welcome any and all input on those two or three questions in there from the community to help us, you know, manage the waiting list, and also is this what the community really envisioned the waiting list was going to do, or is there maybe a policy change that’s required.

So, with that – David?

David Huberman: Hey John, David Huberman from Oracle. Can you go back three slides, please? There you go. My first question is, absent any clearer and precise guidance from policy in the future, at some point you’ll reach – at some point you’ll catch up and the majority or all of the revoked and returned addresses that can meet these thresholds will be issued, and all you’ll be left is some modern version of a swamp, of squatted-on space, on routed space, on space that’s stuck on block lists or whatever.

Absent any policy advice, does ARIN plan on doing anything with this space? Or have you not thought about it? Or what happens to all the space that’s just stuck?

John Sweeting: I’m going to defer to Mr. Curran.

John Curran: When you say “just stuck,” you mean cannot be resolved?

David Huberman: Doesn’t meet these thresholds. We’ll use a simple example. A /16 that’s being routed by someone and you don’t know why they’re routing it.

John Curran: Okay. So we try not to do harm. And so that means that when we do return and revocation, we’re really trying to make sure there’s no harmed party by us taking this action.

At some point we’ll catch up with all the backlog. We’ll collect everything out there. We won’t be issuing effectively, there will be nothing new coming into the waiting list. The IANA will be done.

Now, you ask at that point: What’s the useful waiting list program? Or you’re asking a different question, which is: At that point, what happens to address blocks that we can’t clean up? Well, they remain in their current state, by definition.

David Huberman: Okay.

John Curran: And that’s probably what should happen, unless someone wants us to risk harm to organizations that might be innocent but just not aware we’re even out there.

David Huberman: Okay. Thank you.

John Sweeting: Back mic, David Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Go forward a couple of slides to the what’s the purpose slide. One more.

John Sweeting: To the which one?

David Farmer: Policy issues to consider, and you had what’s the underlying purpose.

John Sweeting: Okay.

David Farmer: A sub-bullet you don’t have there, which is what I feel the underlying purpose of the waiting list policy is, is to ensure to the greatest extent possible that address blocks are not stuck in ARIN’s pool someplace.

And so it’s to get them out of ARIN and get them into hands of people that can use them. These other considerations are secondary as far as I’m concerned.

John Sweeting: Thank you. Back mic.

Austin Murkland: Austin Murkland from QScend Technologies. From a small business perspective, if you get targeted by DDOS attacks, your options are basically go CDN based on mitigation or some sort of routing through scrubbing center via multi-home setup. If you don’t already have a /24, you can’t participate in that.

Somebody’s been on that list for close to two years now looking for a /16, they could easily have that be met by the transfer market. And if they want a /16, they probably can afford it. Whereas a small business usually isn’t going to be needing a /16 or can’t afford the transfer market current pricing.

So my recommendation would be to just try to target giving small businesses an opportunity to get more /24s when larger blocks become available.

John Sweeting: Okay. Thank you. Maybe you’d want to find an AC member somewhere during the meeting and talk to them about how to put in a policy proposal.

Front mic. Go ahead, Owen.

Owen DeLong: Owen DeLong, Akamai, ARIN AC. I think the existing waiting list policy was designed to try and balance fairness across all the people that for whatever reason decided that the transfer market wasn’t the right avenue for them. Those that get transfers pop off the waiting list and get out of the queue. So not a really big deal there, no harm done.

Those that for whatever reason don’t or can’t get transfers to meet their needs and are willing to wait as a last resort, so to speak, get to make their own decision about whether they wish to remain on the list or not.

And I think that’s the most fair thing we can do. I think that if we were to change the rules at this stage with so many people already on the list, there’s no fair way to do that to the people on the list.

John Sweeting: Thank you, back mic.

Kevin Blumberg: Kevin Blumberg, The Wire. I’ll start with the second one. There’s no way to fairly distinguish between not-for-profits, for-profits, all of that. I really don’t think that’s the area to go down.

John, you did a recent blog post about Section 4.10 being able to get a small block of IPv4 as long as you’re needing it for your IPv6.

So that is not going to have any cost implications other than doing the right thing and doing v6 and getting some v4 out of that. And that’s the avenue I would push people towards, rather than anything there.

My bigger issue is actually with the first one, which is the assumption that you’re getting on a wait list because you absolutely need the space right now, but it’s okay to wait two to three to five to however many years to get the space. If you have to wait an indeterminate amount of time to get space, your need is not real because it doesn’t make sense.

It’s a logic problem. So right now the pool is based on FIFO – first in, first out – right? It could just as easily be a lottery, which would probably be more fair than a FIFO scenario, but the question is at this point: Is it even worth changing?

There’s so little coming out of this. You didn’t provide aggregates. How much total space has been given out from the unmet list in total since its inception?

John Curran: We don’t have a total, but someone who wants to visually do that, my math fu is not up to that right now.

John Sweeting: As you can see, it’s somewhere around 63 –

Kevin Blumberg: It’s a /14 worth of space that’s being given out, give or take?

John Curran: A /19 and – sorry, a /14. About a /13 and three-quarters.

Kevin Blumberg: So if the issue is that we’re actually doing good by giving out really small blocks, that’s maybe one area to go, which is to limit the size of the block that gets given out in the unmet – to get more and more people, which I believe is what’s being done in other regions with their soft landing.

But otherwise I actually think FIFO is the biggest problem at this point.

John Sweeting: To that point, a /16, if the number one person on the wait list is looking for a /16, one person gets satisfied. It’s a /24, 256 people get satisfied.

Kevin Blumberg: Understood.

John Curran: By the way, I’m closing the queues. If you want to speak on this, approach a queue.

John Sweeting: One other thing, Kevin, on the first in, first out. It’s as long as it matches the minimum size that you would accept. Otherwise you get skipped over. That’s all.

Kevin Blumberg: No, I understand. My issue with FIFO is that it’s the people in this room who are in the know about this list who have an unfair advantage because they’re on the list in the first place. Most average people don’t know about this list.

John Sweeting: Thank you.

Go ahead, back mic.

Joe Olivieri: Joe Olivieri, Root Level Technology, Houston. I think a couple questions for clarification. One is the /24s are available. So if you’re looking for a /24, ARIN has them available for you; it’s just to implement IPv6, and it doesn’t cost you anything. That’s what he was saying. But there’s not a lot of information about that.

When I went to ARIN on the Road, it was the first time I heard about that. And I think ARIN could do a little bit better job advertising that for the smaller companies. And it also helps to implement IPv6.

A point of clarification question that I have is: The /16 is not going to get a /16 until one’s available. But if /18s or /20s become available, everybody lower than that is going to get their IPv4, correct?

John Curran: It depends on who’s in the queue. If the /18 is in the queue and waiting before the /19s and /20s are, it would be, it would go to the /18.

Joe Olivieri: But we’re not just stagnant waiting for a /16 to come in to do the first one, it’s –

John Sweeting: No, no, no, we skip over –

Joe Olivieri: I think that’s a misunderstanding, then –

John Curran: You specify what range you’re willing to wait for. We check every queue position when a block becomes available.

Joe Olivieri: And I think another question that you were asking was we’re not just looking at one person getting served. There’s 195 that’s been served already on the waiting list, correct?

John Sweeting: Correct.

Joe Olivieri: With the smaller ranges.

John Sweeting: Yes.

Joe Olivieri: Just wanted to point that out. Thank you.

John Sweeting: There’s actually a few /16s that have been issued.

Jason, last one.

Jason Schiller: Jason Schiller, Google, ASO AC. A lottery is a terrible idea because it gives the impression that it’s worthwhile to keep submitting requests because I could possibly win the lottery. I think it’s much better to understand that there’s potentially a two- or three- or four-year wait to get that space.

And with respect to is the need valid if they can wait two years, I don’t see that as necessarily being true. Certainly someone could have a valid need. They could have a valid need such that it justifies the cost of spending the money on transfers. Or their valid need could not justify that cost but it is still valid, and they’re going to sit and wait until addresses become available, and they could be potentially holding off a deployment.

So I don’t think just because someone waits two years means they don’t need the space.

John Sweeting: Thank you, Jason. Thank you, John.

John Curran: Thank you, John.

(Applause.)

John Curran: If you have ideas – by the way, the policy works as John said. But if you have ideas on how it should change for the better of ARIN and the community, then the people running around with the badges that say Advisory Council know – they’re really experts on how to write and submit policy proposals.

You can also just do it yourself, but if you want someone to help you, find one of those wonderful people.

Draft Policy ARIN-2017-3: Update to NRPM 3.6: Annual Whois POC Validation

John Curran: We actually have – see, people did that in the past, and as a result we have draft policies to consider. And the first one up is Draft Policy ARIN-2017-3: Update to NRPM 3.6: Annual Whois POC Validation.

As this is a Draft Policy, it’s going to be presented by the AC. And I see Amy Potter coming up to do the presentation.

Amy Potter: Hi, guys. My name is Amy Potter, and my colleague Alyssa Moore and I are the shepherds on Draft Policy 2017- 3.

This is one of the Whois accuracy policies that Leslie mentioned in her talk earlier, and a lot of the data that she provided there is going to be really useful for us in our discussions here. So thank you for that, Leslie.

All right. I’d just like to make one note about the slides. Both the problem statement and the policy statement are redacted and summarized here. So I’d encourage all of you to take a look at your policy guides for the full text of both. The authors put in a lot of thought. Yeah, it’s a really thoughtful text. So please take a look at that.

There’s also a really handy compare-and-contrast chart because this policy is somewhat similar to another one that will be presented, I believe, directly after this. Although, it has a very different problem statement.

So from a public policy perspective, the failure to have an accurate ARIN public access Whois information can present challenges to a number of different entities.

It’s the public safety officers and law enforcement agencies have trouble rapidly identifying the IP addresses that are used in ongoing abusive activities. It ends up wasting network operator time and resources spent on responding to potentially misdirected legal requests.

And domain name and IP number resource hijacking, which Leslie discussed earlier, is another issue that pops up because of these inaccurate POC information.

So the problem of potentially inaccurate information is most acute with legacy resources, as was discussed earlier. Legacy registrants are held by thousands of entities that do not have updated and verified Points of Contact. Many times the original POC was removed and replaced with a placeholder.

Current ARIN practices do not allow for organizations that have been merged or acquired to update their POCs without entering into a Registration Services or Legacy Registration Services Agreement with ARIN. This causes many organizations to go through the process of updating – or to not go through the process of updating their POC records.

As the amount of criminal activity that goes on online continues to increase, users whose IP addresses have been abused need to have – need to be able to obtain redress.

For organizations that have been tasked with protecting the general public, one of the most important registration records in the Whois is the last ISP in the chain of network providers there.

To facilitate a timely and effective response to abusive criminal activities, the ARIN public access Whois directory must be up to date and map the IP number resources to the correct network provider.

Privacy, safety, security are all equally important outcomes and depend to a large extent on the accuracy of the ARIN public Whois directory.

So as I mentioned, this is – oh, actually we’re starting with the current text of the current policy. States that during ARIN’s annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete.

Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid.

ARIN will maintain and make readily available to the community a list of number resources with no valid POCs. This data will be subject to the current bulk Whois policy.

So sort of summarized the proposed changes to the text. You can find the full text in your handouts.

So ARIN will perform an annual POC verification by sending out an email to each of your POCs, the admin tech, NOC, and abuse POCs for every organization that holds a direct assignment, direct allocation, reallocation or AS number.

It’s important to note that similar to the next policy that’s going to be presented, this does not apply to reassignments made to downstream customers or to end users.

Legacy resource holders will also be able to update their POCs without entering into a contractual relationship with ARIN. Sort of the mechanism for enforcing this, each POC will have 60 days from the date they’re first sent the notification to respond.

After the initial 60-day period, there will be – non-responsive POCs will be marked as non-responsive. After an additional 90 days, so 150 days total from when the first notification was sent out, ARIN staff will conduct a thorough research and analysis before marking those non-validated, abandoned, or otherwise illegitimate POC records as invalid.

Records that are marked as invalid will be taken out of reverse DNS and their associated resources will be removed from the public Whois, thereby disabling reverse DNS.

So we have some questions for discussion here. Is taking resources out of reverse DNS and removing them from the public Whois an appropriate incentive to update POC records given the severity of the problems posed by Whois inaccuracy? If not, how can we effectively incentivize POC updates in a way that actually addresses these problems in a real way? And does the community support allowing the legacy resource holders to update their POCs without entering into a contract with ARIN even if there has been some M&A activity that has occurred?

Paul Andersen: Thank you, Amy. A few housekeeping points first. So back to that lovely flowchart.

So this is a Draft Policy, as opposed to the one we did this morning. We’re much earlier in the process. That’s important for a few reasons, because what we’re really looking for right now is discussion. A little less argument and support, but we’d love to understand as well, but the AC is looking for feedback on how to reconcile, is this a good idea to be pursuing.

The other thing I just want to obviously point out is that you’ll notice there’s another Whois policy coming up. There’s been this lovely comparison chart pointed out.

There’s a tendency in these discussions, when there’s two policies that may be interacting, to try and start making the two discussions into one. And my request to the community is please come forward to the mic, give as much detail on what you like and dislike about this policy, and leave the reconciling/drafting/merging to the AC.

They will take all this feedback, they will meet and they will decide how they’re going to reconcile the two policies. So if at all possible, do that.

With that, if you can hear the sound of my voice either online or in the room, you’re welcome to approach the mic. But we need discussion.

Peter Thimmesch: Peter Thimmesch, Addrex. Two points that we’re trying to figure out for discussion. First, we believe that organizations hold number resources, not POCs. So we’re not sure how that squares with the first part.

And the last part, we didn’t see anywhere in the proposed text which would allow for the legacy resource holders of a merged or acquired entity to be able to update that. So if that could also be at least proffered or if we can send something, we’d like to see that. Okay?

Paul Andersen: Thank you for the input. Rear microphone.

Steve Ryan: My name is Steve Ryan. I’m ARIN’s outside counsel. I just want to remark on the justification for the policy talks about law enforcement. Actually, civil society has an equal and equivalent need for the same accuracy.

In other words, I think because of the origin of the policy, it could be lost that civil society that doesn’t have agents and desk-drawer subpoenas has the exact same need.

So I can’t address the POC issues, which I think this is a really important discussion, though, but I really wanted to just emphasize that private parties need this.

And we had a brush years ago with SOPA and PIPA, which were badly written bills in Congress, that might have addressed issues in an overbearing way. And I think the discussion briefly this morning, there’s a question from the front mic about legislation, we need to solve this problem, to the extent that we can, to show government that we can be the effective forum that we are.

Paul Andersen: Thank you. Front microphone.

Owen DeLong: Owen DeLong, Akamai, ARIN Advisory Council. So a few things on this. Number one, I think there’s a factual inaccuracy claiming that organizations cannot update their POC records without entering into a contract with ARIN.

I think POC records can be updated. Org ID records, on the other hand, have difficulty being updated without going through the contractual process.

So unless this policy addresses that shortcoming on Org IDs, rather than POCs, number one, the policy statement calling out POCs is inaccurate, and, number two, the failure to provide a mechanism for Org ID updates without a contractual relationship with ARIN is not going to solve the problem.

I’m not sure whether that’s a problem we want to solve. If John wants me to defer to him and come back to the rest of mine –

Paul Andersen: Well, I think Amy would like to speak first to that, and then John.

Amy Potter: So if you are a legacy address holder and you do not have any live POCs, you need to go through an Org ID recovery.

However, if you have gone through some sort of M&A activity between when you first received the address space and when you’re trying to do that Org ID recovery, you do need to go through an 8.2 transfer which requires you to sign an RSA or LRSA.

So for certain organizations, they are not able to – certain legacy organizations are not currently able to update their POCs without entering into a contract.

Paul Andersen: John.

John Curran: I agree what Amy just said, but responding to Owen.

Owen, you presume that the requirement to enter into a contractual agreement means the problem statement’s invalid.

The problem statement is about people who don’t have updated POCs, and it’s trying to solve those being updated. It’s not clear whether or not they – for the people who have gone through mergers and have more substantial updates to do, it’s not clear whether or not, for some of them, that is or is not an issue. You can’t pre-presume it’s an issue for all of them.

Paul Andersen: Another quick point, or…

Owen DeLong: I had other points, yes, but just to respond to John. I was saying that the statement that they can’t update their POC records is inaccurate, because they can. Notwithstanding Amy’s little technicality, there may be some subset that can’t.

Anyway, moving on, I think we need to look at – we’re trying to incentivize certain behavior here, which is updating your combination of Org and POC information on a resource.

There are two possible ways to incentivize something, and I will divide them into two categories of carrots and sticks.

To the best of my knowledge, we’re fresh out of carrots. I think ARIN has three sticks that are available to them in escalating order of collateral damage.

The first stick, which has very little or no collateral damage, is the Section 12 review.

The second stick, which has substantial but not devastating collateral damage in most cases, would be pulling the PTR records. I’m not sure pulling the Whois data in addition to the PTR records is such a great idea. But that’s something we can debate later.

And then, of course, the third stick would be actually pulling the resources themselves and reclaiming and possibly redistributing them.

Perhaps we need to look at some level of process that escalates through those three steps. Or perhaps not. I’ll leave that up to the community to debate. I don’t have a strong opinion one way or the other.

I will say if we don’t come up with some combination of carrots and sticks that works to some extent, Steve Ryan is right; we’re going to end up having the legislatures of various countries that we serve decide that for us in various ways.

Paul Andersen: Thank you. I’m going to go to the rear microphone.

Avri Doria: Avri Doria, Technicalities, which is a legacy holder for which I am the POC.

I have, I guess, first a question which is just ignorance. When you say that you send a mailing out, do you send multiple mailings? Or it’s one, you miss it, and you’re out of luck?

So that’s one question. Because I know I constantly miss email that’s sent to me.

Paul Andersen: Let’s do the questions one at a time. Who wants that one?

John Curran: We send an update per the policy once a year. It’s an annual update. You get one every year.

Avri Doria: So you get one. If you don’t answer it, then you could go through a whole bunch of the repercussions before you got another. In fact, you might not get another. Let’s say you didn’t answer the first.

John Curran: Completely distinguish our reminders for you to update from the process of what’s happening to people who have out of date information. You could have updated your information last month or five, seven months ago and we send you a reminder to update it again. So failure to respond or not responding is completely independent.

The question is: What do you do with information where the POC hasn’t been updated in some number of months or years? But that’s independent of the reminder system. Okay?

You’re tying it to an email. It’s not tied to an email. The email is to remind you: Update your POC. Whether you do that or not, what they’re talking about is a policy that would involve going through the entire database, whether they got emails or not, and acting on people who have not updated their contact for whatever reason.

Avri Doria: In other words, the punitive action is for not updating, not for not responding.

John Curran: It’s not for responding or not responding, it’s literally for not – if you have a Point of Contact that has not been refreshed for any reason, a policy that goes through and takes Points of Contact that have not been validated in a certain time period would sweep them up, whether an email was set up or not.

Avri Doria: I think I’m more confused than I was before. But that’s okay. That happens to me frequently. So I’ll work on it for a while and see if I can understand it.

In terms of incentives that was being talked about, I think, if I understood one of the resolutions, is to take the reference out of the Whois. So if I was a bad guy, that would not be a bad thing for me to happen to me.

Another thing that occurs to me, and I’ve seen it several times here now – forgive me, I’m a newcomer, but I’ve seen several times here a presumption that law enforcement needs it; therefore, we must do it. If we don’t do it, they will make laws that we won’t like.

I wonder how come that’s such a sort of given fact here, and I wonder whether you’ve had the extensive discussions over privacy and other things that take those questions and make them such a stated fact.

And then the last thing I want to say, in terms of the last bullet, if you were to make me sign a contract to update my POC, I’m almost positive I wouldn’t. I just would see that as a disincentive. Thanks.

Paul Andersen: Okay. Thank you for your comments.

I just have a quick question – or request. If you are going to speak, could you approach a mic. We have limited time, and I just want to get a handle on how many people we have to speak. I see we have remote participation.

So please line up if you would like to speak, just so we can give a good balance of time to everyone. We’ll go to remote participation next.

Andrew Dul: Okay, we have Christopher Blecker from the Walt Disney Company: While this does put teeth into the POC validation, this could also make the situation worse. Removal from reverse DNS could possibly break services for users and removal from public Whois may actually harm investigating owners of blocks.

Having it marked as nonresponsive or invalid is one thing, but having it removed from public Whois removes one of the breadcrumbs in finding who is the actual owner of the block, especially in time-sensitive situations.

Whois accuracy is a good thing, but I’m not sure this is the right way to go about it.

Paul Andersen: Okay. I would ask all those at a microphone if they could try and keep their comments to one minute or less if possible.

Far microphone over there, please.

Dani Roisman: Hello, Dani Roisman with SoftLayer and IBM. I definitely agree that we should not ever be removing Whois information due to noncompliance with POC validation. I also want to reiterate the fact that resources are assigned to Orgs and not POCs. So the way this is written I don’t even think is actionable, where it states that if the POC is marked as invalid, then records will be taken out of reverse DNS. If anything, that would have to be modified to say if all POCs for a given Org.

I think there’s another carrot, actually. So Owen had mentioned we ran out of carrots. Maybe there’s a financial incentive. Maybe we charge a penalty fee if you’re doing the renewal, annual renewal, where you have all invalid POCs. Or maybe we offer you a discount if all your POCs have never gone invalid, et cetera, et cetera. Maybe there might be a little bit of a carrot there.

I think also something that Leslie mentioned earlier today is perhaps doing a little bit of – being a little bit smarter about renewing POCs. So if we’ve actually worked with an individual Org at some point in time, in person or on the phone, if we’ve successfully collected billings from them, clearly they’re alive and responsive, for those that are actually being billed. I think we can be smarter about kind of refreshing that trip odometer anytime ARIN actually interacts with somebody live and validates, oh, this information is accurate. So I think that also should be considered.

I would actually be interested in having ARIN conduct a financial exercise to see what would it cost to actually perform a massive outreach by ARIN to all the invalid POCs. Any Org that actually holds resources that has at least – it has zero valid POCs, I would say how many man-hours would that take, what would that actually cost for ARIN to proactively reach out a little bit more than just an email, maybe some physical mail, maybe some phone calls, et cetera, and try to reach out to those POCs.

I think, whatever we should do, we should remove any barriers to database accuracy. I don’t necessarily agree in suddenly trying to impose penalties.

Also removing PTRs might actually prevent a POC from validating, may actually break the ability to send email into ARIN. Keep that in mind.

And many Orgs, many legacy Orgs might not be actively using PTR, in fact. So I don’t think we should consider that as an effective way to enforce this policy.

Paul Andersen: Thank you for your comment. Front microphone.

Jason Schiller: Jason Schiller, Google, ASO AC. In response to your questions, if you want to break reverse DNS, I’m fine with that. But please, dear God, do not take it out of the Whois.

I think taking it out of the Whois is actually just going to encourage hijacking. And the Whois, even if it’s stale data, is better than no data. At least that gives me a lead of someone that I need to contact if there’s an operational issue.

I certainly would like the Whois to be more accurate. I do support legacy resource holders updating their POC information. Certainly if they can prove that they are the authentic holder of that space, which is what we have a consultation about currently, yeah, I just want to echo the response, please, dear God, do not take it out of Whois.

Paul Andersen: Thank you for the comment. Rear microphone.

Elvis Velea: Hi. Elvis Velea, V4Escrow. I agree totally with Jason. Don’t remove it from Whois. It’s going to create a bigger mess than it already is.

As for allowing legacy resource holders to update their POC, please do. Please allow. Of course with due diligence done, allow any legacy resource holder to actually get their contact data correct.

Basically Whois and the registry are probably one of the most important things ARIN should care of.

Paul Andersen: Thank you. Thank you for your comment. Front microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. A number of people before me have brought up many of the points I originally came up here to make, but I have one left, which is that there was a question about the email validation and what outreach would be involved in something like this.

I would expect that given the severity of the stick here that there would need – a dire need for additional outreach if we adopt a policy. I believe that additional outreach required should be codified in the policy.

What do we do if – what do we do to try to reach somebody who hasn’t updated their POC record? If we’re going to do this, that should be stated in the policy as well, is what chances people have, what opportunities do people have to correct this before their resources are pulled.

Paul Andersen: Thank you for the feedback. Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. Don’t remove the Whois; mark it inaccurate. Have no problem with the removal of PTR, but my question actually is: Can we remove the PTR in a legacy record that we do not have any contract with? Does that put ARIN at major risk, changing something that has been the way for 20 years?

Which actually comes to – you don’t need to answer, John, because let me – I’ll tell you why. Because it really comes down to the bigger problem. There’s a lot of things in here that I think we need staff and legal on now rather than later, such as contractual relationship is hand-tying ARIN in terms of what it can and cannot do, rather than saying RSA, LRSA, no contract can be done.

I’m just wondering if it’s better to have all of this dealt with staff and legal early on now so we know what the pitfalls are, so that we can fix it, rather than having it dumped on us as it’s about to go recommended.

So I’d love to hear the answer, but there was more to it than just that one.

John Curran: To answer the question, the contents of the registry and the services that we provide are what the community wants us to do as the Board of Trustees deems from your input.

Okay. And while staff and legal will do a review and say if there’s a risk, ultimately, you know, we need to see an exact proposal in order to know the exact risk.

If you said is there any risks if we set a policy that doesn’t provide reverse DNS services for some people in the registry, and I say no, as long as it’s clear who, and you say, okay, we’ll randomly choose 5 percent of the registry and take away its DNS service, I’ll say, wait, now there’s a risk.

And so the exact proposal matters for the risk assessment you’re asking for.

We’re happy to do one early on this, but please give us text. Don’t ask us to do a risk assessment on anything that might have come up at the mic in the last hour.

Kevin Blumberg: Thank you. I have concerns as stated with the word “contractual relationship” and it tying ARIN. I have concerns with can you remove legacy resources. But I believe this policy is a good policy overall. It just needs some polishing, and that’s my feeling on it.

Paul Andersen: Okay. Thank you. Remote participation.

Andrew Dul: Christoph Blecker, Walt Disney Company. Plus one to Dani’s comments around financial incentive. Discount for all validated POCs would be a great carrot to try. And polling customers for POC validation at or around billing time sounds like a great idea for staff to take on.

Paul Andersen: Thank you for that. Front microphone.

Chris Tacit: Thank you. Chris Tacit, Tacit Law, ARIN AC. Without commenting on the specific remedies that this policy suggests, I just wanted to back up and talk a little bit about the context of this issue and specifically to respond to comments made around concerns about law enforcement and privacy.

It seems to me that law enforcement is part of this community. It’s not us against them. They’ve come here. They’re participating in our process. And we owe them the same courtesy as we would any other members of our community.

The second thing is the privacy balance has already been struck by the policy. What we’re talking about is the accuracy. Nobody is using that information to get any more information without court supervision.

If information that flows from that POC record needs to be – needs to be obtained either by law enforcement for their purposes, perhaps to save a life, not just to charge someone, or for a civil suit, it would be done pursuant to a court order.

So there’s no privacy breach inherent in fixing a problem.

And my last point is that with the runout of IPv4, we’re past the point where needs-based policies can serve as a bit of a discipline for improving the accuracy of the registry. So we really need to be focused on that part of our mandate and shore it up as much as we can going forward. Thank you.

Paul Andersen: Thank you. Side microphone.

Craig Thompson: Craig Thompson, Caldwell Global Communications. A few years ago we had a nonprofit customer that we had served for many years, and they said, Hey, we have some IP space; could you use it? We said, Well, sure.

At the time it was pretty difficult to try to work through the process of acquiring that IP space directly. We talked to our upstream and said, We’d like to route this. They said, Can you get us a letter that shows you have permission to? We said, Yes.

So we routed it for years and years and years, and finally last year it worked through the process of actually getting the space transferred. It took a lot of work because there was chain-of-custody issues that had to be resolved.

And that just brings me to the point that in a lot of these cases, if the legacy space is being routed, it seems like the ISPs and the carriers that are routing this space need to be contacted to find out who is this customer, who are you routing it to. Because if someone had done a lookup on this particular IP space we were using for years, it would have shown someplace out in the west part of the US, whereas it was actually being routed to us in the east part of the US.

So my question for the ARIN staff is: In beginning to look at these allocated space that you don’t have contacts for, do you already have a plan in place or do you have contacts with the carriers to try to get some of the low-hanging fruit of finding out who it’s actually going to? Do you have anything in place for that?

John Curran: As it turns out, the Number Resource Policy Manual is really clear when it comes to POC validation, and what it actually says is that we send an email out every year.

It actually doesn’t call for us to do research, investigation. It doesn’t call for us to contact upstream ISPs. Doesn’t call for us to do a lot of things.

We’re happy to do more. Mind you, the moment you tweak that knob, be careful, because the denominator has hundreds of thousands of records. So anything you add is material. Okay?

But if you want us to do something more as part of POC validation, either before we send the mail or after we send the mail or for the nonresponsive ones, that’s certainly in the realm of the community to specify.

We’re happy to do it, but we’re not – if you’re asking organically have we branched off in that area and are doing creative things, no, we’re not.

Chris Thompson: Not currently. And I would like to say that I am for the allowing organizations to update their information without having to enter into a contractual relationship. I think that’s a great idea.

And I’m also for the idea of doing financial incentives for companies that do wish to update their data which hasn’t been updated.

Paul Andersen: Thank you. As a small housekeeping, I’ve not seen anyone approach a mic in several minutes. So I’m giving you last call that I’m going to close the mics after the next speaker. So if you’d like to speak, please start making a motion towards a microphone or start typing in Jabber.

Rear microphone.

Jason Bothe: Hi. Jason Bothe, Rice University. I don’t support this, the breaking of PTR records or removing contact information, and I’d like to see a conscionable effort made by ARIN to perhaps pursue the organization through registered mail or something or a registered agent of that organization in order to obtain the information it requires.

We’ve extended address space to other organizations to better the community as a legacy address holder, and we sometimes find that it can be otherwise caught in the crosshairs of this breaking of that information and not being able to get the proper communication. But perhaps contacting the registered agent or the organization would be helpful for the community. Thank you.

Paul Andersen: I just echo I think what John said. We’re happy to look at these kind of things, just realize that there is a large number of contacts and it could start to not scale well from a cost, especially if we have human interaction. It can obviously impact costs, which we’re always very sensitive about.

The microphones are closed unless you’re making a motion right now. And I don’t see it. And if there’s no one typing, we will do the last two comments from the front unless a remote pops in. So go ahead.

Bobby Flaim: Hi, it’s Bobby Flaim from the FBI. In support of this policy proposal, like was mentioned in the presentation, Whois obviously is important to law enforcement. But one of the other things is it’s also important to a lot of other public safety agencies as well. Consumer groups. It helps us with identifying victims. It helps the certs. It helps anti-abuse groups. So it isn’t just law enforcement.

And also this policy goes towards just being able to serve legal process, which was mentioned before by Christian. So this is very, very important that people recognize this.

And a part of Leslie’s presentation earlier, she said there were three steps – the contract with the RSA, whether we do a policy or legislation.

And, John, you had talked about you hadn’t heard anything about legislation, but in private we really are talking about it.

And we are here. We are here to try to work this out. I’ve been coming to ARIN for 10 years. And if I have to hear Whois come out of my mouth one more time, I’m just going to – I don’t know what.

But it’s really important, and we really are trying to be a good community member, but this is so important not just for the attribution and finding the bad guys, but IP spoofing, the health of the Internet in general.

So we’re agnostic, obviously, about the technologies and the sticks and the carrots, but we really do want to make sure that we see it work. So thank you again.

Paul Andersen: Thank you for your participation.

For those not aware, Bobby and also Jason two meetings ago or last meeting did come and give a good presentation, you can see in the archive, that explained from their perspective some of the challenges they’re facing.

Any remote participation? Nope. All right. Last comment.

Alain Durand: Alain Durand. I was wondering if it would be worth us separating the validation for POC that like resources are really old, like legacy of predating ARIN, from the resources that have been managed by ARIN from the get-go.

Because it seems to me that for the legacy stuff, it might be a self-corrected problem. As we talked earlier this morning, transfer actually increased via accuracy of those things. As more of those resources get transferred, the less this problem will be relevant.

So it’s just a thought that came to me. We should maybe want to separate within two buckets.

Paul Andersen: John, quickly.

John Curran: People have noted that there’s actually three buckets. There’s legacy, there’s ARIN-issued, and then there’s IPv6. And you could actually end up with separate requirements for all of them, recognizing that as we go forward eventually the requirements for IPv6 may actually be the most important ones long term.

Alain Durand: If I can comment on that one. We may even have a worse problem with IPv6 because there’s even less carrots because folks coming in get a large allocation and never come back.

Paul Andersen: Any last words, Amy?

Amy Potter: No.

Paul Andersen: Let’s thank Amy for her presentation.

(Applause.)

Paul Andersen: This is a Draft Policy. So the Advisory Chair gives me his indication – he’s indicated we do not need polling at this time, so that ends the discussion. Thank you very much for your input. I’ll hand it over to John for the next policy.

John Curran: Thank you. Wonderful discussion. I’m sure that the happy folks in the AC will ponder all this.

Again, they’re in the crowd. So if you see an Advisory Council member, feel free to reach out to them, talk to them about anything that you didn’t get a chance to come to the mic with. They have the colorful job of digesting this, and trying to see if there’s any way to incrementally make it a little better so the next time it comes here, it gets a little more support. Or deciding it’s pointless and – and – one way or the other, it’s their job to try to advance the ball.

So the next one up is Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement. Chris Tacit and Andrew Dul are the shepherds. I see Chris coming up to do the presentation. Come on up, Chris.

Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement

Chris Tacit: Thank you very much. Who has got the slides?

Okay. So this is the problem statement that was provided in support of this particular policy, and it relates to the volume of work required in order for ARIN to contact and verify the POCs every year.

There was some assumptions made in the problem statement that – some of which may or may not necessarily pan out to be correct, such as whether or not these emails constitute unsolicited commercial emails, the so-called damage to ARIN’s ability to conduct ordinary business over email, because these emails may be treated as spam and so on.

And there is a lot of work associated with this. That certainly, I think, we all recognize is certainly true. In any event, the author of this proposal believes that POC validation efforts should be directed to directly issued resources and that that has the greatest value for both Internet operations, law enforcement.

So with that in mind, I just want to show you what the current language of this particular section is. And the change that is proposed is the addition of the red text.

And essentially what this does is by mentioning these, specifically, it removes the indirect assignment verification requirement. That’s the net effect of the new text.

So when this went up on PPML, it caused a great deal of discussion. There was a lot of opposition to the proposal. A lot of it was based – a lot of the objections related to the need to ensure that the validation continues in order to not degrade the accuracy of Whois. Questions were raised about why ARIN would have a more difficult time doing this than ICANN does for domain names.

And some, of course, stressed what we’ve also heard with regards to the previous policy; that inaccurate Whois is important for law enforcement. And, as we’ve heard, for many other purposes.

There was some alternate suggestions made in some of those comments. One was should – if the workload is too big for ARIN to verify every single one, would sampling do? Can the process be automated more? Can more be done to validate these records upon their creation to ensure their initial accuracy?

If the problem is that some of these emails are being treated as spam, can the language of the email be changed so that it doesn’t read in as spammy a way and that would not necessarily require a policy change.

Defining more of a direct business relationship with indirect POCs to avoid having validation email labeled as spam. And I guess there isn’t a relationship with POCs themselves, the relationship is through – contractually through RSAs and LRSAs with ORGs.

And avoiding the creation of multiple and unnecessary records. So these were some of the alternatives.

So people who didn’t like it suggested a bunch of alternatives. So some questions that we are thinking about is are some of the underlying assumptions that were made as a basis for the policy, the problem statement, really true?

And I’ve already mentioned these two at the beginning. So we need some assistance from the community in getting some general comments on this proposal.

So, for example, does the community want us to continue working on this problem? Does the problem statement need to be modified in some way? Would a different policy proposal address it better? And, if so, what might that look like?

And one of the alternatives that seems to generate considerable interest was ensuring that ARIN validates new POCs upon creation. But, of course, that doesn’t necessarily solve the problem of what’s there already.

And I won’t touch the last point, heeding the Chair’s admonition that we want to talk about this policy, focused more on this particular policy rather than a comparison of the policies.

So that’s all I have. Thank you.

Paul Andersen: Alright. We have another Draft Policy. We need you to fill up the mics and give discussion.

Again, let me go back to some of the questions. We’ll start with the rear microphone.

Elvis Velea: Hi. Elvis Velea, V4Escrow. I think the problem statement needs to be modified. If you could go back a couple of slides to the addition to the – one more. One more. This one.

So right now ARIN does the POC validation to every POC in the database, right? That was a question. Or not?

Paul Andersen: All 600,000.

Elvis Velea: All 600,000 of them.

John Curran: All of them, every one.

Elvis Velea: Right. Right now the problem statement is should ARIN only verify the POCs for the resources that were assigned or allocated directly by ARIN?

And I think that the responsibility for the resources that are SWIPed or reassigned should actually be delegated to the organization that is doing the SWIP.

And I think also that if an organization registers assignments underneath their block that was given by ARIN and does not follow up with their customers to have their POCs validated or updated, then it’s that organization’s responsibility.

And ARIN may have a stick there.

Paul Andersen: Thank you. Front microphone.

Owen DeLong: Owen DeLong, Akamai Technologies, ARIN AC. I represent an organization that has a relatively wide diversity of reassignments issued to us by a relatively large diversity of providers throughout the world.

We often learn of POC records and Org IDs that have been created on our behalf by these entities when we get the annual POC validation email.

It is very useful to us in that getting those emails allows us to go fix those. And we have no other visibility into the fact that these have been created in many cases.

So taking out the annual validation of those will actually severely decrease the accuracy of records, at least that apply to my particular organization, because we are constantly seeing new ones of these created.

I probably see two to three of these POC validation emails for creative records of this type per month, to put it into perspective.

Paul Andersen: Are you therefore not in favor of this policy?

Owen DeLong: I am therefore very much not in favor of this policy. I think we should drop it like a hot rock.

Paul Andersen: Thank you for that clarity. Rear microphone.

Louie Lee: Hi. Louie Lee, Google Fiber and also the ASO AC.

I think the reallocation and the reassignment should be accurate and audited, but it should be the responsibility of the ISP to keep those records accurate.

It would be great if ARIN can invoke a 3.b of the RSA and complete some random audits of the downstream SWIPs. And then if there’s a concern, to do a more extensive review of the given ISP’s downstream, ISP could follow up on that.

Then if ARIN can do some educational outreach about the requirement for the ISPs to do this work and inform them of the possible audit implications of their SWIPs are not in order, that could be a way to move forward on that.

There are also some operational concerns that were discussed on PPML such as the need for a downstream organization to act to SWIP. Of course, needs to be sorted out and appropriate concurrent policy crafted.

Paul Andersen: I wouldn’t mind just clearly hearing if you’re in support or against because I have a slight hard time digesting that from your –

Louie Lee: Okay. So wouldn’t want anything removed. But – let me get back to you on it. There’s a twist on it.

Paul Andersen: I’m happy, we’ll wait in anticipation. While we’re waiting, far microphone.

Dani Roisman: Hi there. Dani Roisman with SoftLayer, IBM. In short, I am in support of this policy as it’s written. I think it makes sense that ARIN’s relationship is with the direct recipients of resources from ARIN and those interacting directly with ARIN.

I do represent an organization that has a significant number of downstream assignments to our customers. And I do agree, as was said previously, that it’s the responsibility of the organization to ensure that their POC, their downstream POCs remain accurate.

I wanted to – just something that I mentioned during the previous time I was up at the mic, that I think it would be interesting to see what would be the financial impact to ARIN if they shifted, if they invested some resources in active POC validation.

I would even argue that hopefully some of the resources that could be freed up from the process of doing needs justification – again, back to my – I know this is a recurring theme I mentioned multiple times before, but we all agree that the database accuracy should – or many of us agree that database accuracy should be the number one mission statement of ARIN.

And so I would say I would support ARIN spending money on human resources to actively – to actively ensure the accuracy of that database, and that has to do with POC resources [sirens] – they agree as well.

That’s what I would say. I’m in support of this. I think ARIN should be spending –

Paul Andersen: You have to kind of go over it. Could be here for –

Dani Roisman: Okay. I think ARIN would be better spent – ARIN’s money would be better spent having their analyst go after accuracy of the database, including POC validations. And in this case it would be creating a report for organizations to ensure their downstream POCs are accurate, pointing out where they’re inaccurate, and finding some way to incentivize them to work on that.

Paul Andersen: Thank you to the speaker who had to work over sirens during that.

John Curran, quickly.

John Curran: Just to be clear, the reason we’re not doing more in investigation is simply because we don’t have a policy that says what specifically you’d like us to do.

And even the resource impact, once we know what you want us to do, we can flesh that out and to see whether or not it’s significant or not. We’re definitely not going to preemptively come up with some creative staff thing here where the community hasn’t told us go do this with these resources.

Paul Andersen: Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I don’t support this policy. I believe many things that Owen said already to be 100 percent accurate.

I would say that, that being said, we don’t define in the NRPM the difference between a detailed SWIP and a simple SWIP. It’s for staff and implementation, and that’s a technical matter. And to me this is a technical issue.

The issue is that currently ARIN, in my mind, is not following best practices when it comes to detailed, which is the validation after the fact, that, yes, you can use Kevin Blumberg’s email address, I actually would like that.

And this has been discussed. That part of it does not need to be dealt with in the policy. But if Org A over there is going to say that Kevin Blumberg is the user of the space, then Kevin Blumberg should at least be able to say yes, I’m actually the user and I would like my personal information, whatever it may be, put into the Whois.

So that to me is a technical issue. Has nothing to do with policy. It’s just best practice that if my name is going to get put and my company’s information is going to get put in a record, that I have the ability to say yes to that.

That’s being discussed on the Mailing List.

John Curran: You’re right. That’s not a policy issue. Actually, it’s as simple as something you could put in as a request, which is if an email address is being put onto a block, you want ARIN Online – you want us to automatically go ask that person to confirm or not accept it. It could be as simple as a feature request.

But very different than Section 3.6 which calls for very specific process for annual POC validation.

Kevin Blumberg: I understand. What I’m saying is I will submit that ACSP request for that technical adjustment.

And like I said, I don’t support this policy. I don’t believe this is the right way to go. There’s another policy that we’re talking about separately. This one I don’t support, and I would like to see this dealt with technically rather than in policy.

Paul Andersen: So it was reminding me at one of the breaks that we love – I’m just going to make the acronyms and – because we’ve run through ACSP, the ARIN change/suggestion process.

Just a reminder, there are other avenues other than the policy process we’re dealing with today. If you have operational suggestions for ARIN, we have a formal suggestion process. We’ll have Open Microphone tomorrow, I believe, as well as Wednesday.

If you do have suggestions from an operational perspective, they are always welcome, even if they are technically out of scope of policy.

I’m going to go with that far microphone. I think it was close, but I’m going to go for that one first.

Craig Thompson: Craig Thompson with Caldwell Global. I recently signed up for Uber, although I didn’t know it. I got an email on my business account that I have with Gmail, like a separate contact address, that someone in Memphis, Tennessee, had signed up for Uber and used my business email address. I have no idea why.

Took me a few days to get it sorted out, but finally did. And I’m not in favor of this policy because I believe that each person who is listed needs to have the right to be able to say, well, that’s correct or incorrect.

And I also, from an ISP perspective, think that the ISP should only maximally be responsible for the Org aspect of SWIP and not the Point of Contacts themselves.

Because that would say, okay, you need to know everybody who works for these organizations as well. Just simply needs to be if you SWIP it to somebody, you say it’s SWIPed to this company, this Org ID, and then that particular Org is responsible for updating their POCs.

And I would also suggest that it could either be a policy change, something in the documentation that says if you take IP space and you reallocate it to your own customers, then part of your legal agreement is that they have a – not necessarily a contractual relationship with ARIN, but they agree to receive emails from ARIN if that were an issue legally.

Paul Andersen: Thank you for the comment. Front microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. A fundamental question this policy brings up for me is: Why are records being added to the database that have not been validated before entry?

Paul Andersen: That sounds like a good thought to ponder.

John Curran: We have no validation requirement in the technical part of the system. No one’s ever told us we should. And therefore any ISP can redelegate any line noise they want into the database under their address block.

Paul Andersen: I think it was suggested that we should, though.

Running out of speakers. We do have a little bit of time. So if you would like to give very valuable feedback to the AC. Again, it’s fine even to just go up and say “I support,” “I don’t support,” and leave it at that. But if we don’t have any, we’ll close the microphones shortly.

Rear microphone.

Elvis Velea: Elvis Velea, V4Escrow. I just had the first comment on this policy proposal, and I never stated whether I agree or not with it.

Let me just say that I agree with this policy proposal as long as it would also delegate. So it would add to it a delegation for the ISP making the SWIP to actually be able to verify or be asked to verify the POCs underneath that block.

Paul Andersen: Okay. We’re going to close the microphones after the next speaker starts. Sorry, finishes. Not starts. That would be really unfair.

Please approach a microphone quickly or start typing. We’ll go to Louie’s hat next.

Louie Lee: This is Louie’s hat, right here.

Paul Andersen: I miss the old hat.

Louie Lee: Thank you. To answer your question earlier. Sorry I delayed a little bit. So yes for the – to support removal of verifying the contact information of downstream customers, but if ARIN would invoke the 3.b section of the RSA for random audits and then sort out Owen’s operational issue as a community issue.

Paul Andersen: Thank you. Now we’ll close the microphones.

Cathy Aronson: I really hate that you just closed the microphones, but Cathy Aronson, just because I feel like it.

I feel like this is like ARIN saying I know all the rest of the database is screwed up, but I’m just going to put this blindfold on and blame it on those guys.

I don’t agree with this at all. But I personally would like to feel – I would like to hear from the people who were in the room last night, like Bobby, about whether you think this would solve your problem or not.

Paul Andersen: We have a little time. Not to call you out, Bobby, but the question has been raised.

Bobby Flaim: Hi, this is Bobby from the FBI. I think the previous policy solves our problem more than this one does. So I hope that helps you out, Cathy Aronson.

(Laughter.)

Paul Andersen: Thank you. Alright. No –

Andrew Dul: Does it make it worse?

Paul Andersen: Does it make it worse?

Andrew Dul: Sorry, the question was, I just had a follow-up to Bobby. Does this make your situation worse? I mean, we’re potentially removing a lot of data over time, right? But it might be inaccurate. So there’s a balance there between inaccurate and…

Bobby Flaim: Yeah, then you go into a long conversation. Sometimes bad data is good data because it does give you leads. But, on the other hand, we don’t want to encourage the continuance of bad data. We want to get good data. So how we get there becomes a real sticking point.

So I don’t think that’s helping you that much, but…

Andrew Dul: No, very helpful to understand.

Bobby Flaim: We know it’s a tricky problem, but we’re just trying to ensure that we have accurate contact information. No matter who that is and how we get it is – we know it’s a problem.

Paul Andersen: Thank you for grabbing that.

Chris, any last words? No. John? No. Thank you very much for the presentation, Chris.

Dan, I believe we’re going to – same as last time, correct? There will be no poll. That ends this policy. Thank you very much. I’ll throw it over to John for the break.

(Applause.)

John Curran: So before we go into break, I had forgotten – I was doing my mental math, and I forgot that a very large block went into the IANA return pool before it came out the other side and came to ARIN, our portion, and went to the reallocation, and that included some /11s and /12s. It’s all in the graph. But when I mentally did the math, I didn’t count those.

The happy folks at Addrex did some real quick math, and their count of what’s been issued through the waiting list I think is right. I haven’t double-checked it, but it’s the equivalent of 62 /16s.

So, substantial. Almost approaching a /8. I had forgotten about the 45 /8 going into the wait pool and back out the other side.

So we’ve had an equivalent – I say that’s about right, 62 /16s. So the waiting list policy has handled a substantial amount of address space that went through it.

Okay. I’m now going to tell you we’re going into break. Same old rules. So everyone head out there. When we come back from break, first I’d like to – actually, this is the back from break? No, this is the go to break. This is back from break. When we come back, we’re going to thank our sponsors.

We’re going to go to break. We’re going to resume from break at 3:30. And we have the IETF Report when we come back. We also have NRO Activities Report. I have a presentation on Internet Health Indicators, and then we have the closing announcements.

So be back here promptly 3:30.

(Break.)

IETF Report

John Curran: If folks will come in and be seated, we’ll get started. Welcome back to the ARIN 39 meeting.

At this time we’re going to resume with our final block of the afternoon. It includes the IETF Report, the NRO Activities Report and the Internet Technology Health Indicators report.

The first of these is given by our IETF reporter, Cathy Aronson. Come on up, Cathy.

(Applause.)

Cathy Aronson: Hi. So I have 30 minutes and 85 slides. I think I need like a speed skating outfit.

John Curran: 40 minutes.

Cathy Aronson: I guess I have 40 minutes. Uh-oh, watch out. This is my current “neener” slide. This is one of the cabins from the movie “Shane,” and I took that.

Anyway, it was from the ’50s. So maybe you didn’t see it. But anyway. Alright.

So this slide is probably going to go away. For years it said it wasn’t official. But I guess I’m official now. That’s kind of scary.

Anyway, I’d love your feedback. If you were there and I got something wrong or you’re just annoyed at what I said, you’re welcome to tell me. It’s happened before.

A lot of this is my opinion and my take on what happened. So, you know, take it for what it’s worth.

Oh. And I forgot this last year, and it confused people. This meeting, I’m always talking about two IETFs. So this was the Seoul IETF in November and the March 1 that just ended Friday. Talk about being the speed skater.

So if you’re looking for a particular set of slides, all my slides are kind of mixed up in order of when I want to talk about them. Since I have 85 slides and 40 minutes, it’s a little bit of a challenge.

So if you have a hard time finding a reference or whatever, just let me know and I’ll help you find it.

So let’s see. Oh, super duper duper exciting week at the IETF. Are you ready? Is everybody ready?

We have the first woman chair of the IETF.

(Applause.)

Cathy Aronson: And we have the first woman chair of the IRTF. So awesome. Way to represent. They’re both awesome, and it’s just going to be really – it’s historic.

The shoes are out. But I have a couple of collages that you can view at your leisure of various things I saw throughout the week. I like the Spam fried rice the best.

And in Chicago we played Whirlyball. And if you have never played Whirlyball, it’s super fun. Elise and I managed to win a game on our team. And I have a lot of bruises.

There’s six different places in the country that you can play this horrible game in bumper cars. But anyway, on to the real stuff.

But used to be an ancient NANOG tradition to play Whirlyball. There’s one in Florida. There’s one in Cleveland. There’s one in – no, they’re not in Ann Arbor anymore, but there are two in Michigan in towns I’ve never heard of. And there’s one in Chicago. Oh, is there one in Seattle? I didn’t know that. That’s news to me.

Okay. So what is the IEPG? The IEPG is a working group that’s happened for the last 25 years, maybe, on the Sunday before IETF from 10:00 to noon. And it’s really a group of operators that talk about stuff that’s pretty interesting. It’s probably the most interesting part of my talk; thus I put it first.

So we had a demo of the DNS DB and a bunch of information about some attacks that were happening on the DNS.

Like I said, this is a fly-by overview. So some of this stuff, if you want to read about it, you’ll have to look it up. But let’s see.

There’s some database, some information about the number of queries and how to mitigate attacks that you can look up if you want. And Geoff’s talks are always super interesting.

Let’s see, some data about DNSSEC deployment. 89 percent of the TLDs are signed, but only 15 percent of queries are being validated now.

There’s packet capture of the DNS. There are some tools that are available now. So there’s a lot of DNS. IEPG was almost all DNS, both times maybe.

Okay. So you can measure IPv4 and IPv6 NAT, and there’s actually a tool you can look up if you want to check it out. Here’s some data from the measurements.

This was at – I think this was at the Seoul IETF. So it’s data from November. So there’s a lot of NAT 4to4. So v4 to v4, v6 to v6 is small, V6-only host, zero, which has actually gone up. I have some more stats on that. There’s some data.

You can run the tool that was on the previous slide if you want to check it out. It’s a LACNIC tool, apparently.

So there’s a thing called Let’s Encrypt, it sounds pretty exciting, that people are starting to use. And so a lot more encryption is happening since the Snowden events and those sorts of things. So there’s some information about that.

You can actually sign your various things, your domain and stuff, for free instead of having to pay, which is making more people do it, which is a good thing.

This is the – he called it the DNS horror show. I don’t know. I think there’s a lot more scary things, but there’s a lot of stuff going on with bad stuff that’s happening in the DNS, like he said CDNs have a special place in hell. There’s like extra stuff at the end of packets. There’s NS records that are created on the fly.

My favorite is if you query for a v6 A record, you get a v4 answer, which is somehow not right, kind of bad, I think.

So, anyway, Geoff gave a talk just last week in Chicago about the BGP-4 routing table. And there’s some really interesting takeaways for this group in particular.

The one I liked the best that isn’t necessarily for this group, there’s a whole chunk of the Internet that can’t get to a whole other chunk of the Internet, and no one seems to care, which I think is pretty interesting.

But maybe, I don’t know, maybe everybody just goes to their big websites and they don’t really go to the ends of the earth anymore.

But a few things that are really interesting is that as we run out of addresses, the routing table is still growing at the same rate. So the same number of routing entries are being added every month. But they cover less and less space.

But for some reason there’s still more routes, the same number of routes, pretty consistently.

The average diameter of the network hasn’t really changed. It’s pretty – I forget, five point whatever, I don’t know if I have it on my next slide, but they’re adding like 6,000 prefixes a year, but they’re just smaller and smaller.

The thing that’s really interesting is – maybe it’s not on this slide yet, but I’m going to say it anyway – that older address space is starting to show up in the routing table, like address space that might not have been previously routed but maybe it got transferred to somebody.

So older prefixes that were assigned long ago are starting to show up in the routing table, which is really interesting. So this whole transfer process that we’ve been doing, and trying to free up old address space is actually happening.

A small number prefixes are generating all the noise; that’s nothing new. But it’s the same in v4 as in v6. Like I said, there’s a whole part of the Internet that can’t get to a whole other part of the Internet.

Anyway, no one’s complaining. Like I said, the age of the address space is going up, which is good. It’s a good thing.

Let’s see, what else? These are some more drafts that are going on. This guy gave this whole talk about the whole mismatch between the IETF saying, well, you should use a /64. No, you should use a 128. Like 127 is okay.

These are all the different RFCs and how they’ve differently specified what length prefix you should use. It’s a little confusing, to say the least, but I found it really entertaining.

Let’s see, bundle demand. So each one of these, for those of you that haven’t seen the speed skating event before, each working group I go to are birds-of-feather sessions; I try to put a little bit of a blurb for you to refer to as to what in the world that thing is.

So this is the bundled domains, and what it is, I’m not going to talk too much about this. But this is a little bit interesting.

So in Chinese, there’s, like, two different character sets, and they’ll have the same domain pronounced the same way but spelled differently and they’re supposed to resolve to the same thing.

So there’s a big work underway with these non-ASCII character sets to figure out how to make that work. So that was one of the big talks that we had.

Okay. So this is really awesome. So I always ask people, if you hear about something that’s going on at the IETF and you think I should go to it, David Huberman posted a note about this, and sometimes I catch these things and sometimes I don’t.

But this is called CASM, and basically it was a birds-of-feather session to not form a working group about this but about IP address management systems and what people might want from IP address management systems.

And since we’re all about IP addresses here, it was a good thing to go to. It’s a little not quite thought through, but these are all the different – they’re trying to define, like, what you would want to do with an IP address management system.

And so there’s a draft that they’re starting to talk about that. And maybe – I don’t know. It seems like they might form a working group.

But George Michaelson was asking about the layer between the IP address management system and the RIRs, like the Whois and RPKI and all that stuff, like maybe we should define the layer – what do we need from all these ISPs, IP address numbering systems and whether we should use tools that already exist, like OpenID and JSON and REST and all that.

One guy said we’re inching toward thinking about how to invent a conversation. They’re trying to figure a way. I might not necessarily have found this on the agenda or something might have seemed more important to me, so I really appreciate it being pointed out.

So if you see something or if there’s something that’s interesting for this report that you think I should go to, then by all means, mention it.

So v6ops, I go to this one every single time. This is basically operations of the v6 Internet, how to interact with v4-only networks.

Let’s see. So these are some of the drafts we talked about. The first one talks about PI and PA space. And I always try to follow those, because I don’t really like the IETF specifying whether you should use provider-aggregated or provider-independent space.

Like, it seems like it might be a little overreach. So I’ve been following that. They’re not really specifying, but they talk about it.

And then there’s – I talked about this a few times. There’s a unique prefix per host instead of a unique IPv6 address per host, and there’s a lot of work being done there.

The multi-enterprise multi-homing that I talked about last time that I heard five times is still kind of moving its way forward. So they’re still trying to solve multi-homing, which seems like the age-old problem.

So a couple of organizations got together and drafted requirements for IPv6 routers. I was one of the people who worked on the requirements for regular, ordinary routers in the ’90s.

So I’ve been following that, because routers should do things and not do things. But it seems like it’s pretty straightforward. And it’s a good read.

And then there’s a Customer Edge router document, which I’m not really sure how that interacts with Homenet yet. So it seems like it’s kind of redundant with Homenet, but we’ll see.

They’re talking about making it so that it’s only really specifying things for v6, v6-only to interact with v4 as opposed to v4-only interacting with v6, which is, you know – it’s a step along the evolution.

Let’s see. This is a dynamically configuring v6 host. And there’s a lot of stuff going on there.

And Happy Eyeballs is how happy are your customers using v6. And they’re talking about if you get a v4 address and a v6 address, if you get the v6 address first, they’re saying maybe you should just use v6 and not wait for the v4 address.

And Apple has done a ton of work with Happy Eyeballs and their gagillion devices that have them, so their paper is pretty interesting on that.

I talked about this in another talk, too, the /48 for the transition. It seems like maybe it’s a little late for that, but the document’s still moving forward.

V6 use cases: I think, like what John was saying on the panel, like there’s so much more that you can do in it, and you don’t have to do the gymnastics to make the address space work, so why not start looking at different things that could be done with v6 that maybe you can’t do anymore with v4.

So 6man is changes to the v6 spec to help make v6 more deployable as opposed to the operational parts of v6.

And this is my favorite one. IPv6 is still not an official Internet standard. So gotta love that. So it’s moving forward to become – it’s a draft standard that we’ve all been implementing for, what, 15 years or something. 20 years. Yeah.

So, someday it will be an actual Internet standard. Awesome. But they’re just trying to make the tweaks to kind of catch it up with where we are now so that it could become a real standard.

Let’s see. More 6man. V6 node requirements. So what do you need from a v6 node and how should it interact?

Let’s see. There’s a lot of this stuff. I think I’m just going to skim. I went to one version of human rights. And we have the human rights chair here, Avri, which is awesome.

So they’re looking at protocols and how they interact with human rights, affect human rights, limit human rights. And it’s pretty interesting work. And actually there’s a panel I’ll talk about at the plenary this time that was really great that was all about that.

Let’s see. And if you haven’t ever read the human rights declaration, that’s really a good read. So I put the link in here. It’s good to know.

Let’s see. There was an Internet Society lunch in Seoul about Internet of Things, which is not my favorite term. And it was pretty interesting. I have a few little notes from that.

And it was a free lunch. So a girl’s gotta go. The technical plenary was a little bit of an advertisement.

But the Jon Postel Award recipient was the woman that started really the first Internet connection in Thailand. And her talk was really interesting. And she’s done a lot of really good work in Southeast Asia. So that was pretty exciting. I dare not pronounce her last name.

But let’s see, the IEB technical plenary was all about – this one was in Seoul, I believe, and it was all about the latest attacks that were happening at that time.

And then the one in Chicago, like I said, was all about human rights. And it was a really nice discussion between Dave Clark, who is truly one of the many fathers of the Internet, mothers of the Internet. And that was pretty cool. That’s all recorded, too. So if you have a chance, you should check it out. It was a really good talk.

The security AD, the security directorate. Sometimes when I don’t have a v6 thing to go to, I go to the overview ones. Sometimes they’re just repeats. But this one was actually really interesting, some work that’s done with different incidents in Korea, because we were in South Korea.

So they have a lot of – just like everybody here, a lot of attacks going on and a lot of people trying to figure out ways to solve them.

And if you have a lot of questions about security, we have Merike Kaeo, our local resident expert. She can update you as well on some of these guys.

So DNS Ops, again, it’s a working group that’s all about operations of the DNS and the root zones. I try to go to this one when I can. And these are some of the things that are going on about ipv4only.arpa, which I’ve been trying to follow.

Let’s see. There’s a bunch of work being done to capture DNS packets and analyze them. You can get bulk captures now, too.

Let’s see. A lot of people are trying – thinking that what we should do is move to doing DNS over TCP because it’s connection-oriented and it’s more reliable. So there’s a lot of work being done on documentation on why you would want to do it and why it’s better and the connections are long-lived and all that sort of stuff.

And then there’s a few more crypto drafts that I am not even qualified to talk about. But you can read them if you’re interested in cryptography. And these are a few more drafts that are being worked on that I have 85 slides and forwarding this.

Now, the IRTF is the Internet Research Task Force, again, newly headed by a woman, yay. And some of the stuff that’s going on there, it’s kind of pre-IETF. So it’s stuff that may be coming in the future. There’s a lot of work on it, like artificial intelligence.

There’s also the Applied Networking Researching Prize, which are people, they submit like their research, and then they win. And at every IETF, there’s at least a couple of them that give a talk. And, I guess, I thought I had more slides on IRTF, but I guess I don’t.

So GROW is the Global Routing Operations Working group. A lot of really high-level routing stuff happens in there, like coordinating MTUs at exchange points and different kinds of things that the global routing system would need as opposed to an individual protocol.

So one of the things that’s being drafted is what should BGP do when you pull your box out of the router and you plug some stuff into it? And basically it should do no harm instead of just starting – some people think it shouldn’t start advertising everything. It should just bring up the neighbor and maybe you tell it what you want it to do.

So there’s some work being done there, some work being done on BGP communities.

So BGP – BMP is a BGP monitoring protocol. And it’s being deployed. And there’s a lot of work being done to look at what’s really going on in the BGP.

And there’s a tool that some folks were talking about that they wrote that would take all the routing out of route views and the routing version of route views in Europe and look at it with those metrics.

And the reason that that tool got written is because not enough people are running BMP yet to actually get enough data out of it to really look at what’s going on in the routing table.

But there’s some tools that are – there’s MRT to BMP. It’s publicly available and you can run your routing data through it and look at it.

Let’s see. They’re adding features to it that’s more local routing. So BMP in the beginning is just pre- and post-policy, but this would be more localized routing that you could get in. And there’s some folks working on code for that.

Session culling. So this is a draft that would specify how you would slowly turn the routing off before you took a router down for maintenance so that everything would reroute and it wouldn’t just be down until it rerouted.

And there’s some work being done, I think I talked about before, in the autonomic networking about something similar, where there’s a management system that would do something similar. And I guess now they’re trying to specify it.

So this was probably one of the more interesting groups I went to. And I just had nothing v6 to do at the time, so I went in there. It’s a whole lot of measurement and analysis and a whole lot of people measuring stuff, which is super fun.

So this was – so it turns out what you name your machine and when you connect to the network, you know, like, a lot of your information is really easily figured out from the connection when you connect your computer.

Like, there were so many people in this study that their name was unique. So they used their first name but maybe their first name was really unusual and there were a lot of them. So like people can actually tell who you are.

So they were recommending, like, you name your machine something, you change your log-in name. You know, all the usual stuff.

But they actually did a whole bunch of, like, sniffing on the wire and trying to figure out who all these people were, and they could. It’s kind of creepy.

This is some IPv6 data. I don’t know. I cut and pasted it. It might be hard to read. But this is prefixes, v6 client address counts, and various different protocols that are either being phased out or not. But v6 is definitely happening out there, which is kind of neat.

Let’s see. What else? This is a global coordination to measure the Internet. And the talks were really interesting about this, and there’s a link there if you want to check it out.

I don’t know what else I want to talk about here. I think we’ll skip that.

So IPv6 support. Oh, I know what the takeaway from this was. I’m sorry. Every once in a while there’s a slide I think: Why in the world did I put that in there? It’s 89 slides in 40 minutes.

They’re starting to see 3 percent v6-only hosts. And they think some of them are 6-to-4, so they’re really 6 but they’re translating to 4.

But still we’re starting to see – and it sounds like, from what John was saying, there’s a whole lot of v6-only that’s 6-to-4 on Comcast, too. It’s really starting to happen, so it’s kind of cool.

This is more looking at v6 deployments. There’s also a bunch of tools being written to generate the reverse zones for v6, because you know they’re ginormous, and you really don’t want to have to type that stuff.

So a lot of DNS is being generated forward and reverse to match and just plugged in there, because the files are huge and the address spaces are huge.

So I always used to complain about, you know, like addresses in v6 that were generated randomly. And random is all fine and good as long as you don’t all start with the random number of 1.

So these keys that were used were all generated with really faulty random number generators. So they were really, really bad keys using to secure the DNS.

So there’s this woman that did all this research, and it was completely ridiculous. It’s like everybody started with 2 and they thought their key was going to be secure. It’s really bad.

It’s actually a really comical presentation. So there’s an online mobile app that’s been put out to measure online Internet censorship. I don’t know, I haven’t tried it yet. But the OONI app. Gotta get it.

So Sunset v4 hasn’t met in a while. I think they met in Seoul. And I think – let’s see, what did – oh, it’s a proposal to stop work on v4. So the IETF is really stopping working protocol work on v4 unless it’s needed to interoperate with v6. So it’s really become a limited – much more focus on v6, much less focus on v4.

Let’s see. And IEB has actually put out a statement that v4 is exhausted, wake up, start doing v6. Only took, I don’t know, a long time.

I guess local hosts can resolve to anything. So they’re talking about how maybe it should just be local host again. So hosting.

Let’s see. There is a bunch of work in the IRTF happening on machine learning. So it’s interesting to follow.

Let’s see. The Internet Area is another one of those high-level working groups, so stuff that they don’t know where to quite put it yet.

Okay. So IP version 10, unfortunately for this guy, he was remote and his audio got cut off and we never actually got to hear his talk. But it’s like another weird tunneling protocol where you put v4 and v6 in the header and you call it v10.

I’m not sure that’s going to go very far. But I don’t know, I can’t wait. So there’s a draft, if you want to check it out. But I don’t. I can’t imagine. It’s crazy, right? Joe’s like laughing hysterically out here.

GUE is another tunneling protocol that we’re not super happy about, because there’s too many tunneling protocols.

Let’s see. What else? Extended ping is something that if you’re an operator you might look into. So there’s a lot of security implications with extended ping. So maybe you ping something and you get information about the other interfaces, is kind of what it’s about.

So maybe you don’t necessarily have to get the response from the interface that you pinged over. So there’s a lot of work being done by Ron Bonica on the draft for that. So I’m not sure about that.

So my favorite, Homenet. We’re still talking about the same old things in Homenet.

This is the purpose of the group. It’s basically to make an automated, easy-to-install, plug-and-play home gizmo network for everybody kind of thing.

So there’s some drafts. They’re still debating about Homenet because they had Home.net, but then it wasn’t defined as special-purpose domain, and people complained for various reasons. So they’re trying to standardize .homenet.

And I think we’re in the same place we were in in Seoul and in Chicago. So I’m not really sure how far we’re going to get with that. But I really feel like from the panel discussion that maybe some of this stuff, the ship already sailed. I think I even heard somebody on the panel say that at an IETF at one point.

So these are more drafts that are going on in Homenet. HNCP is a Homenet routing protocol.

Let’s see. And then in Chicago, I call him the biggest fan of Babel. So, Babel is the other routing protocol for Homenet. So basically it’s like RIP on steroids, and I don’t know why we needed a new RIP. But apparently we did.

And they’re still talking about .homenet, like I said.

So SIDR, the Secure Internet Domain Routing working group, became SIDR Ops, so basically it’s far enough along that it’s just all about operating it now.

So we just have SIDR Ops working groups. I only went just briefly, because there was a lot of stuff going on, but here’s some of the stuff that’s going on in SIDR. They’re doing a lot of testing on certificate authorities and them talking to each other and fetching data back and forth.

And maybe during the engineering report from ARIN we’ll hear more about the RPKI, probably.

So they said that they were going to have more answers at the next meeting, but they didn’t. So I don’t have much to talk about that. There’s some route leak drops that are pretty interesting.

Routing area is another one of the groups that has a lot of stuff under it. Let’s see. Dynamic multi-path routing is how to route around bottlenecks.

Let’s see what else. These are some of the more drafts from there. DNS Service Discovery. I think I went to this one in Seoul.

There’s a lot of stuff to try to make the DNS better, like pushing the information ahead of time and discovering proxies and that sort of thing going on.

Operations, there was a really neat presentation about Wi-Fi calling and how it works and what they need to make it work better. It’s about their deployment.

There were some pretty good graphs. Let’s see. I went to this IP Wireless Access and Vehicular Networks because this whole thing terrifies me – cars talking to each other and routing around each other.

So these are the drafts that they were talking about in there. 802.11 OCB, which is this Outside the Context of a Basic service. I don’t know how they get these names.

This is some of the work that’s going on in there. I don’t really want my car to talk to another car. I don’t know about you guys. Yeah, wow.

Okay. So these are some cool links to check out if you’re interested in IETF stuff. And like I said, if you can’t find something on your slides and you want more info, just send me an email.

If you’re going to your first IETF, there’s a video on how people might be rude to you. And you need to read stuff ahead of time.

And there’s IETF Systers, so we’ll all support you if you’re a sister. Just find one of us.

And this is my favorite sign from Seoul. And the quote of the meeting.

So, anyway, does anyone have any questions or comments?

John Curran: Microphones are now open for shorter speeches disguised as questions?

Cathy Aronson: I have to give credit to Randy Bush for that. He had like a comic that said that, and I just stole it. And then there were all these people at the microphone just, like, crazy, going on and on. Anyway.

John Curran: I see no questions. Thank you, Cathy.

(Applause.)

John Curran: Okay. We are going to move into our last couple of presentations. And first one is the NRO Activities Report. And I have – wow, that’s me.

Yeah. So here we go. While we’re waiting I’ll say I do want my car to talk to other cars and tell them to get out of the way. I’m all for that.

Number Resource Organization (NRO) Activities Report

John Curran: So the NRO. The NRO is the five RIRs working together. We have a mission, apparently. Collectively, we want to be the global leader in Internet Number Resource management as a central element of a stable, secure, open Internet.

I’m giving the update because I’m the chair this year of the NRO. It rotates among CEOs. The NRO is – we have an MoU that basically says that when the five RIRs work together, we can be called the NRO.

We coordinate RIR system activity. We promote the multi-stakeholder, bottom-up policy development process. And we fulfill the role of the ICANN ASO.

In ICANN, the bylaws call for an organization called the Address Supporting Organization, and then it says the NRO shall be that.

So we’re the NRO, but when we’re in ICANN, we just put on a hat that says ASO because it matches what the bylaws says.

This works out pretty well. Doesn’t work out universally well. And it’s something that has come up a little bit. I’ll talk a little bit about that.

So the NRO has an executive committee made up of the five RIR CEOs. As I said, I’m chair this year, so I’m chair of the NRO. We have a secretariat hosted by APNIC. German is our secretariat.

Because we have five RIRs that do similar things in different regions of the globe, but we need to coordinate across them, we actually pick the people out of the respective groups in our respective organizations and have cross-community working groups, effectively.

Those are the coordination groups. So we have a communications coordination group, an engineering coordination group, and a registry services coordination group. And that’s the leaders of those respective teams in the respective RIRs.

So, for example, when Leslie was talking about Whois accuracy and some of the metrics that have been talked about, I’ll talk about them later, that was things that Leslie talked to the education services coordination group, the leaders of the Registration Services teams in each of the five RIRs.

We don’t really talk much externally about the coordination groups, because all they’re doing is is doing work that we’re doing on behalf of you. I’d rather tell you what ARIN’s doing and let Paul tell you what APNIC is doing, et cetera, et cetera. But we do have coordination among us, and quite a bit actually. It’s one registry, even if there’s five organizations.

Okay. Internet Number Status Report is an example of one of the things we coordinate amongst ourselves. It has the global statistics on IPv4, IPv6 and ASNs, what’s been assigned and allocated, available online.

We do a Comparative Policy Overview, which we update quarterly, which cross-references sections of policy, like the transfer policy in all five RIRs. And that’s also available online.

We have expenses. Our expenses include the NRO meetings and some of these joint activities. It also includes our support of ICANN. And it also includes the IANA Numbering Services Contract. The expenses are allocated among the five RIRs based on the size of the organizations in terms of registry revenue.

So when you look at us proportional, that’s roughly how it breaks down by percentage. Our general operations expense, about 331,000 a year, our meetings and travel communications, things like that. Our contribution to ICANN is 823. So that gets divided up among by those percentages.

We have an RIR Joint Stability Fund. Each of us makes sure we have reserves standing by. Collectively, the pledges are more than $2.1 million. If an RIR were to suffer an adverse effect financially, for example, we all have pledged cross-support to each other to make sure that financially that RIR would be able to keep going, because again it’s one registry, you can’t have one piece of it suddenly go dark.

And there’s also commitments for staff and other support. But it’s a pretty important thing to make sure – we’re all in it together. We’re not doing this independently.

There’s an RIR-IANA SLA as of last year. As per call for the IANA Stewardship Transition Plan, we established a Service Level Agreement between the five RIRs and our IANA Numbering Services Operator, which is ICANN.

And ICANN actually has a division inside ICANN which is the Public Technical Identifiers division, which Elise runs. And ICANN has PTI do the functions.

So we have a contract with ICANN, and the same old team in ICANN is still doing the same function, but now we have an actual agreement. That’s been in effect since October 1st.

The SLA Review Committee, three members from each region – two selected from the ASO AC, two selected, and then one staff represented. And together the SLA Review Committee is responsible when we want to see how the PTI has been doing as the IANA operator for numbering services.

Then we ask the SLA Review Community to advise us on that, look at the performance reports. That’s to make sure that even though it’s a contract between the RIRs and ICANN, the IANA serves the whole numbering community. So we have a review community to help with the review process.

Here’s the review community composition for 2017. And they’re just getting started, which is appropriate, seeing as we just started the operation under this new contract on October 1.

ICANN accountability. There’s an ICANN Cross Community Working Group on Accountability.

Now, of course, there’s been one of those for two years, but now there’s an ICANN Cross-Community Working Group on Accountability Workstream 2, which is all the things they didn’t get done before the IANA transition.

And there’s an amazing amount of subgroups in that activity, and we have people watching them. It’s unclear how much we really need to watch them because it’s really about ICANN governance and ICANN governing bodies and how they operate.

Our relationship with ICANN is we’re defined externally from ICANN. The RIRs are external organizations collectively with the NRO. We have a relationship with ICANN through the MoU; we have a relationship with ICANN through the IANA Numbering Services SLA.

But this is really how ICANN governs itself. And so while we’re watching, it’s not a lot of times we’re putting input into the process. Sometimes we do have a need for putting input, if they asked formally what we think.

We were very careful when we did the IANA Stewardship Transition Planning to make sure that when we did take a position in ICANN, we anchored it back to the views within the RIRs, the community, by going out to the Mailing List.

We need to figure out if we take positions here how to do the same sort of thing. But it’s – ICANN likes to have cross-community working groups, and this one is still going.

RIR accountability. So we have accountability review that we did of ourselves, how each RIR is accountable to the community it serves. And that includes a summary of RIR governance mechanisms. And we review the bylaws and the dispute resolution.

We actually had an independent assessment of that done by some law firms, and you can actually see the accountability assessment online. And there’s an accountability FAQ to show – just to make sure that each of the RIRs indeed is accountable to the community that it serves.

ASO review. So our ASO MoU with ICANN says the NRO shall provide a periodic review of the ASO’s effectiveness within ICANN. In other words, the role that we perform in the ICANN function. So within ICANN the reason we work with them is that ICANN is where we develop our global policies.

We develop it in each of the five regions, but then we rely on ICANN to – once we’re sure it’s correct, ICANN reviews and ratifies that, and that becomes global number policy that’s used by the IANA, by the PTI team.

So we work with ICANN in that, and the ASO AC does that function. The other function they do in ICANN is elect ICANN board members.

So we did a review five years ago about how well we’re performing our duties within ICANN. It was time to do another one. We did a call for proposals late last year. It was awarded to ITEMS International. McTim is around here in the back.

If you have questions about the ASO review, he’s the one to find because he’s in the middle of doing it. Interviews with people about how we’re performing within the ICANN structure is what he’s actively in the process of doing, and we’re looking forward to a report that comes back with an assessment and recommendations.

That’s it. That’s the NRO report. I guess I’ll take questions.

No questions? It is sunny outside. We are in New Orleans. We are a short distance from Bourbon Street. But I’m sure – go ahead, Cathy.

Cathy Aronson: Cathy Aronson. Can anybody participate if they want to answer Tim’s questions?

John Curran: Absolutely. Not only is there a survey – there’s a survey link somewhere, Tim? Is that still open, the survey? Why don’t you come up and talk about the ASO review. Go ahead.

Tim McGinnis: Hi, I’m Tim McGinnis. I’m doing the ASO review for ITEMS International.

Yes, we do have a survey link. Normally when we do a review, we do a series of interviews that inform a survey. And we send out to a larger community. However, in this case we’ve got sort of a truncated timeline. So we have decided and our methodology will be to do the interviews and the survey at the same time.

And given that the ASO is a rather obscure area of interest, there are very few people that are able to give us really useful information. So we decided not to make that link public.

But if you want to take the survey, you can come and see me, and I can certainly share it with you.

John Curran: It’s an independent review. We let them do their methodology and decide what they’re going to do.

So if you have input to the process, you want to talk to them about the review, find Tim.

Tim McGinnis: Yes, thank you. If you have something useful to say about the ASO, we’re all ears. And we’ll be in Budapest at the LACNIC meeting and in Nairobi at the AFRINIC meeting. So we’ll be available throughout all the RIR travel season.

John Curran: Thank you. Any other questions on the NRO report?

Moving right along. We have one more quick update. And this is actually somewhat ICANN-related. You’ll see it’s on an NRO slide deck, and again it has my name there for some reason. I gave these slides at the ICANN meeting in Copenhagen. And it’s an interesting project.

Internet Technologies Health Indicators

John Curran: The project is called the Internet Technology Health Indicators project. It’s a project that ICANN initiated as part of its strategic plan. It’s attempting the – because there’s a number of registries involved in the overall Internet identifier space, as part of their strategic plan they want to be able to report on what’s the health of all these registry systems.

So ICANN put that in their strategic plan. It’s in the office of the CTO. Alain, are you hiding here somewhere? Oh, very good. He and David are working – Alain and David are working on this project, which involves, of course, measuring all the various registries, like the registries that the protocol parameter community has, the DNS community, and the RIRs.

This is an interesting situation, because, well, our community is predominantly at RIR meetings, not at ICANN. And we did sit down and have that discussion. And we said, look, we’ll try to do this jointly, but we’re going to have to facilitate it, because there’s no way to do it at ICANN and have the input it needs. And it’s very hard to do something in 10 RIR meetings and get a single answer.

So to start the discussion, we had the registration services staff at the five RIRs put together an initial Internet unique identifier, an Internet technologies health indicators strategy, an initial set of metrics. And they’re still doing that. They’re literally – this was work in progress.

And then what we’re going to try to figure out is how to do a community consultation in five RIRs at once, all on these initial metrics, to get feedback. Because we want to have one set of metrics for the Internet number registry system, not five.

And then once we have that and we’re sure all the RIR communities agree, then we want to bring it back into the ICANN process and say, this is what the numbers community is using for its metrics.

The RIR CEOs, the NRO AC, we met and talked about whether we would do this at all. And it’s not – ICANN does have some coordination and information mission that encompasses the entire space.

And so we try to work with ICANN wherever it makes sense, so that when someone comes to them and says, what’s happening in the Internet number registry system, there’s some basic information they can provide.

And they felt like it was worthwhile to work with them on this, even though it’s really – it’s not – it’s really about us. It’s really about numbers.

So with that said, we’ve been working, the registry staff has been working on an initial draft this year. We’re hoping to have a release of the discussion draft sometime in the next month or two. And then we have to figure out the process for consultation.

When we did the IANA work, like the IANA stewardship planning, transition planning, we set up a single Mailing List, and then we all set up Mailing Lists in our own region. Still to be discussed how we’ll do this consultation.

But to give you an idea, the metrics are supposed to span all the Number Resources. We’re excluding the reserved ones – special purpose and future delegation – because that’s more in the realm of IETF.

So what are we talking about? Well, you actually saw a preview earlier. Ah, the registry data. Is it comprehensive? Is it correct? And is it current? That’s what the registration services managers have been trying to figure out useful definitions for, so we can actually come back and say, here’s what we think the current measurement of the current number registry system is on these metrics.

And we’re not taking comment on this yet because this is going to become a draft document, which is going to get sent out for comment, for you guys to actually to start looking at the measurement units and the exact measurement terms. And the goal is to try to have something that works amongst all five RIRs. That’s not easy.

We actually – things like is the record accurate? You may have one RIR that says it’s accurate if it points to a legal street address. Another RIR may say it points to legal street address that actually matches a street address that has an organization which is using the resources.

And so we have to try to come up with one set of metrics. And this is not going to be easy.

So just some notes. There’s questions about what do you do when there’s multiple aspects to a metric, like, if something is correct, does it have to be 100 percent correct? Are some of these metrics partially correct? How often do we measure these? What’s the measurement period?

These are the things the Registration Services managers, working with each RIR, are trying to figure out as to what could be a working starting place.

But, again, we’ve got to, when we’re done, send it out to consultation, have you folks say, this is how I want the registry system measured or not.

That’s it. Sort of an interesting project that we’re doing jointly with ICANN. Alain, come speak.

Alain Durand: Alain Durand from ICANN. First off, thank you. When we started this about a year ago, you said that we want to do this jointly, and you said that you guys will start first. And we are here now and very happy about that. So thank you very much.

I wanted to give you some context about why this is important. Somebody asked ICANN manage – or help coordinate – not manage, help coordinate is really the word, operational word – a satisfied notifier. Is this satisfied notifier healthy? And is it better this year than next? Or the previous year? And how do we know that?

Could not really answer this question without having data. And this is what it is all about – providing some data to answer this question. Are we doing better this year than we were doing last year? This is really what this is about.

So the actual value of whatever we’re going to measure is fundamentally irrelevant. Is it 84.5 or 72 or 620? It doesn’t matter.

What matters is we can compare the value from this year from the value from a year ago, two years ago, and look at the trend. And if we associate that number going down is good, and we see the number going down, you’re doing very well.

If it’s the opposite, then we may have an issue that needs more community input. So that’s what we’re trying to achieve here. And I’m very, very happy to see that this is what is happening in collaboration.

And I’m here this week. I will be in the other RIR meetings this year. So if you have questions about the overall project, talk to me. If you have a question about the RIR aspect of it, talk to John.

And thank you, John Sweeting and your team, for setting this up.

John Curran: Thank you. Back microphone.

Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. Having valid data points is great, and I love this whole concept. In listening to you, John, there’s actually one thing that I realize is actually an added benefit to all this, which is being able to compare us, each of the RIRs, against each other, not in a negative way, but to see who is doing things, as you said, street address versus organization at street address, and seeing how we can improve ourselves just by looking at one RIR might do things a little better in one area, another RIR might do things a little better in another area.

And there’s little tidbits we can take –

John Curran: Seemingly standing straighter and – yep.

Kevin Blumberg: Yeah, without all of us going to every RIR and trying to understand how they work. It allows us to self-review and glean from that. So that’s actually a really nice aspect of it.

John Curran: And I do think while ICANN is the one who sort of initiated this, these are our metrics. These are what we decide we want to do.

And it’s a useful thing for us to work with ICANN on projects that help make this a more understandable system to people who may not be entrenched coming to these meetings.

If we can have simple metrics that we can use for communication, that they can use for communication, that we agree on, that certainly helps us in describing how we’re doing as a registry system.

Any other questions on this?

Okay. With that said, we are done with the presentations.

Public Policy Meeting, Day 1 - Closing Announcements and Adjournment

John Curran: I have closing announcements. My goal is to get you out of here in 100 seconds.

Okay. So, first, thanks to our sponsor, network sponsor, Cox.

(Applause.)

Our webcast sponsor, Google.

(Applause.)

And our break sponsor, Avenue4.

(Applause.)

Okay. Tonight’s social, 7:00 PM. It’s going to be at the Mardi Gras Pavilion. And we’re going to have shuttles leave starting at 6:45. Wear your badges. You have a badge for the social. Make sure you wear that so you can get in. It should be a wonderful time. Ends at 11:00 tonight.

And reminders, breakfast opens at 8:00 tomorrow. Our Public Policy and Members Meeting starts at 9:00. All the meeting materials are online.

That’s it. Thank you. See you at the social tonight.

(Meeting adjourned at 4:30 PM.)

Network Sponsor

Webcast Sponsor