ARIN 41 Public Policy Meeting, Day 2 Transcript - Tuesday, 17 April 2018 [Archived]

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

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

Public Policy Meeting, Day 2 - Opening Announcements

John Curran: If people will come in and be seated, we’ll get started. Good morning, and welcome back. Day two of ARIN’s Public Policy Member Meeting.

I hope everyone enjoyed the social last night. Good times.

I’d like to do a few opening announcements of what today consists of:

First, welcome to the remote participants, I know you’re out there. All the remote participants have access to the webcast, the live transcript, downloadable meeting materials and the virtual microphone and polling, which we are doing via Slack this time. You must be registered in order to be a remote participant participating in the microphone and the consensus polling.

Because there’s a live transcript and because we have remote participants, I ask you speak slowly and clearly. Some nice person’s over there transcribing this. Some of you talk fast. I actually talk exceedingly fast if I’m not careful. But please take your time. Say your comments clearly.

Okay. I’d like to thank our sponsors, Webpass, Google Fiber, and Google. Some of you didn’t clap. We’re going to turn off your Wi-Fi access shortly.

(Laughter.)

John Curran: Next time I get this up, I want to hear a lot of applause.

So download the meeting app. We’ve taken time to have a meeting app which has the ability to see the agenda, get information on all the events, very useful.

Rules and reminders. Okay. When we get into the policy discussions, the Chair is going to moderate the discussion so everyone has a chance to speak and be heard. State your name and affiliation clearly at the microphone.

Please comply with the courtesies in the guide, okay. You must respect one another. There is a standards of behavior. If we have a problem, please bring it to me; we’ll deal with it.

Today’s agenda. We have the Number Resource Organization Number Council Report. That’s also what we affectionately refer to as the ASO AC. We have the IANA Numbering Services Review Committee.

We have a Service Level Agreement with ICANN to provide IANA Numbering Services. We have a review committee that reviews their performance, made up of participants from all five RIRs, and they’ll give a report.

We’re going to cover this morning a Draft Policy, Recommended Draft Policy 2017-13: Removing ARIN Review Requirements on Large IPv4 Reassignments. We’re going to have updates from our fellow RIRs from AFRINIC, LACNIC, and APNIC. We’ll have another Draft Policy, 2017-10: Repeal of Immediate Need for IPv4 Address Space.

We’ll have a RIPE update. Then we’ll have the IANA PTI. The IANA is performed by the Public Technical Identifiers organization. We’ll have the President of PTI come and give us a status of how they’re doing.

We’ll have a presentation about some initiative communication that ARIN is doing in IPv6 case studies. We know some of you have done a great job deploying IPv6, and by writing it up and sharing it with others it makes the road a little easier for them.

Then we’ll have lunch. Then we’ll do an Internet Number Resource Status Report, which is the report across the RIRs that give the status of the address pools.

Afternoon will include the Draft Policy 2017-3, which is the update to NRPM 3.6 annual POC validation. We’ll have a report on transfers and how those are doing. We’ll have a report on our software development activities, our website redesign update, and then we’ll do Recommended Draft Policy 2017-12: Requiring New POC Validation on Reassignment. We’ll have a discussion, RDAP update.

And we’ll do an Open Mic session. The Open Mic will cover any topics that have come up, but also cover anybody who wants to comment on any of the open consultations we have at ARIN. That takes place during the Open Mic at the end of today.

So with that, I will introduce the head table. This is Paul. And I see Tina. And I see Leif and Bill Sandiford. And, oh, my God – Chris Tacit. I’m sitting here, Tacit, no, tactical, Tackett, I don’t know, Chris, Chris Tacit. It was obscured.

Let’s get started. Kevin Blumberg will come up and do the Number Resource Organization Number Council Report.

Number Resource Organization Number Council Report

Kevin Blumberg: So, good morning, everybody. While we’re just waiting for the slides, would anybody like to do some calisthenics while we’re waiting? We’re good? Okay. Oh, I’m trying to go back to the front. The first page. Perfect.

My name is Kevin Blumberg. I’m one of the vice chairs of the ASO AC. And in the room today we actually have Louie Lee from the ARIN region; Jason Schiller, who is the third ASO AC member from the region is remotely participating; and I’d like to welcome Hervé. This is your first out-of-region meeting. And he’s from the RIPE ASO AC. So welcome, Hervé.

So the Number Council, we had a bunch of discussion yesterday. And the NRO NC is the RIR-focused council. There’s 15 members. And we’ll go into it. Each has three members. One is appointed for the ARIN region. I am the appointed position. And we have two elected individuals. Again, Jason and Louie from the ARIN region.

The makeup of the body is the 15 of us, as well as having observers and RIR staff, ICANN staff, ICANN board members have joined in on the meetings, things like that.

So it’s a fairly diverse group of people globally and organizationally as well.

So the term of office in the case of the ARIN region is three-year terms, but it does differentiate depending on the RIR. Each RIR gets to set its policies in regards to that. And we’ll show that in the next slide.

We’ve got a website, the aso.icann.org. There’s lots of information on there if you’re interested. The MoUs are on there. The procedures that we operate under are on there.

You can see all of those types of things. Our attendance lists, these are elected positions. If you want to see how your elected representatives are doing on the council, that information is there.

All of our meetings, we have 12 meetings a year, once every month. One is in person. That was just actually in the San Juan, Puerto Rico, ICANN last month. All of those meetings, the transcripts are available for that or the meeting records are available for that.

So there’s lots of information if you’re curious or would like to see what we talk about and do. That’s definitely there. The main focus is selection of two ICANN Board seats, seats 9 and 10.

We do appoint a member to the ICANN NomCom, which is the general body as well, and fairly infrequently advise the ICANN Board. We do meet with the ICANN Board as part of the ASO as a whole. We’ll be sitting there. They have questions for us. That is available. Okay.

We elect a new chair every December. The process, I should say, starts in December. The actual election is in January so that the people that have just been seated from January 1st are the ones making the decisions, et cetera. But the process starts in December, just from a timing point of view.

And this year Aftab Siddiqui from APNIC region was chosen as the chair, myself as the vice chair from the ARIN region, and Ricardo Patera from the LACNIC region. Importantly, the chair and vice chairs cannot be from the same regions. It’s very important that we have regional diversity as much as possible.

And here’s a list for everybody of the different regions and terms for each person. I’ll leave it on the screen for ten seconds. And we’ll go to the next one.

Yesterday when the NRO EC, Paul Wilson, did his update, he showed all the different roles that each of the EC members do, and that changes yearly. I guess it’s up by one, so next year Alan Barrett from the AFRINIC region will be the chair and, et cetera, et cetera. So that rotates around as well.

So this is one of the important functions that we’re just getting finished on, which is the ICANN Board seat selection 9. As you can see, we’re very close to announcing for that seat. And that will be out in the next month. So that’s the final process.

It’s a fairly involved process. We have a set of procedures on the aso.icann.org website. And it takes about – it takes about a year to actually do. So this is the actual process here, but then we have to verify that that is the process which starts about eight months before that.

We have a work plan that we go through, and it actually takes about eight months more. We make sure our work plan is good. We make sure the dates are good. We make sure the dates are consistent with bylaws, et cetera. And these are the actual implementation dates. Okay?

So we are responsible for observing in each RIR region if there are global policy – global policy is the most important part of our–of the council.

We have what are called PPFT, Policy Proposal Facilitator Teams. A nice, long word. We just call it PPFT for short. And Jason Schiller in the ARIN region, as an example, is the PPFT member.

Their job is to report back to the ASO AC for their regions if there are any global policies or anything that might be a global policy or anything that might look like a global policy, to let the council know to keep them updated, et cetera.

So, Hervé, actually, you’re the PPFT for RIPE as well.

So we have a global policy update. There’s something that’s been submitted into the LACNIC region. And Jorge Villa is a PPFT member, is in contact with the author. I believe there’s a LACNIC meeting coming up in two weeks in Panama, and there should be more information from there.

The ASO council had a brief discussion, has asked the PPFT member to be in contact with the author to clarify some aspects of that. And we should have more at our next meeting.

And once again, you can go to aso.icann.org or reach out to us. We’re more than happy to answer any questions you may have in the halls, et cetera.

Any questions? Wonderful. Thank you.

(Applause.)

IANA Numbering Services Review Committee Report

John Curran: Next up on the agenda is Louie Lee. He’ll give the IANA Numbering Services Review Committee report.

Louie Lee: Thank you, John. Good morning, everyone. I’m Louie Lee, and this is Louie’s hat. And I am here to give the IANA Number Services Review Committee report.

So as you’ve seen from past presentations that Jason has given, there is nothing to see here. This stuff is really boring and should be boring, as long as the IANA operator continues to do a good job. Now, please do pay attention at the end for a little discussion, if you would.

So I would go over the formation of the review committee role and the members, along with a current work status, and then the 2017 IANA transactions, which for us resulted in a report, and I’ll go over the conclusions. And the last bit is the community engagement and input. And that’s where I actually want you to, you know, pay attention.

The review committee was chartered by the NRO Executive Council and formed in 2016. It’s based on the CRISP recommendations that the Internet Number Community proposed to the stewardship coordination group, the ICG, called for the establishment of an IANA Numbering Services Review Committee. So we abbreviate that with IANA RC.

Our role is to advise and assist the EC in its periodic review of the SLA of the services provided to the Internet community, and we are also a tool for the community to evaluate and review the performance of the services that are provided. So we help to ensure that there’s community involvement to support and enhance the multi-stakeholder model.

Who is the RC? The RC is made up of 15 members, and in the ARIN region it’s made up of the elected members that are the NRO Number Council: namely, myself and Jason Schiller. Jason is the vice chair, with Nurani Nimpuno from RIPE as the chair.

You’ll note that in bold we have some new representatives since the last update given the October. Also you’ll see the asterisks. Those are the ones that are the staff representative from each RIR for this RC.

So our current work status. In February we put out a call for comments for the IANA Services Performance Matrix and the performance standards metrics. This was a 30-day call on the metrics that were provided to the community on the requests that IANA has received and responded to.

And then just last week we published our own report on the matrix, these metrics, and also any community input that was given. Also as a review committee, we are refining our operating procedures.

So there were four transactions in 2017. You see here the March and July transactions which had to do with a v4 request and an ASN request. We noted that these were acknowledged on time, responded on time, and implemented and accurately on time.

And then in September and December there were also a v4 request and an ASN request, same results.

So last week we put out a report, and you can totally read online the full report. But our conclusions, we reached four conclusions. The first one was that all four requests were fulfilled accurately and on time.

And the second one was that the SLA obligations, we saw that there was no indication of failure or near failure or any concern for interest – or concerning or interesting patterns that we detected.

Also the Internet number community, we concluded there were no indication of concern for IANA performance, partially in that there were no comments provided for the matrix, which kind of seems like everything’s going okay.

So I’ll ask you more questions about that later. So we believe that there was sufficient community outreach and involvement in order to support and enhance the multi-stakeholder model in the open, transparent, and bottom-up performance for the IANA performance.

So this is where we’re getting into where it might be a little interesting to look up from your email. This Review Committee, we’re expected to engage with the community during our term.

And this is communicating relevant developments and collecting feedback on the IANA numbering operations. So we take this in as advice when it’s appropriate, and we’ll review the comments and summarize it in our reports.

So now that we have our first report out, how well do you think this process worked? Any concerns about that? Any concerns about the conclusions that we’ve reached or maybe thoughts that we could do a little better for the 2018 report?

Do you have other feedback? Observations? Praise?

John Curran: Microphones are open.

Andrew Dul: Andrew Dul, CrowdStrike. I have a question: If you feel the process is the right level of effort for what we are asking the IANA to do today?

Louie Lee: Go ahead and repeat that.

Andrew Dul: Are we spending the appropriate amount of time – like is it too much time, too little time – to do this report, given our current relationship with IANA?

Louie Lee: Okay. I’ll take it. I believe we’re doing the right amount, putting in the right amount of effort in. In future years, if what we’ve been doing as a process is working well, the amount of work actually would be decreased because now we have a good template.

We understand what we’re looking for and we can just follow along and do it that way. If there’s changes or concern that the community has about the way we’re doing it, please let us know.

Andrew Dul: No, I think it’s good from what I can see so far. I just – as one of the people I think who pushed for this type of committee when we were doing the CRISP project, my thought, listening to the first report, was when we thought up this idea or thought there should be a review community of the SLA agreement, I’m not sure I had thought through all the ramifications of what it means and who does it and all that stuff. Right?

And you come up with this process to do it, and so my question comes from: Did we get it right? Are we doing the right and appropriate thing with the right number of people, not too many people, not too few people?

So it sounds like after our first report, feel like we have a good process now, and we can use that as our future learning to go forward.

John Curran: So, yes, we have something that works. It’s a work in process. There are things in this world that don’t work. They should usually get attention before the things in the world that do work.

Having said that, given the number of requests we do per year, given the track record of performance, we have an incredibly robust review process for an incredibly well-performing vendor. And all of it could be done with much less activity.

Is it worth the effort to put in to reduce and change the process and get agreement for it in order to save the net labor? It’s a hard tradeoff. When you have something that’s working, it’s borderline.

Certainly if the community directs and all the RIRs agree, then we can undertake that. But even that process takes time.

Owen DeLong: Owen DeLong, representing myself. We pay IANA functions roughly 600-something thousand dollars a year, right, John?

John Curran: Our contract – the IANA Service Level Agreement for IANA Numbering Services has us pay $675,000 per year for that purpose.

Owen DeLong: Okay. Where does that go? Because it’s certainly not that expensive to operate a registry where you delegate blocks of numbers to RIRs. I’m asking –

John Curran: There will actually be a report later, a PTI report by Kim Davies. But also recognize that the IANA function handles us and handles protocol and parameters and handles the DNS route zone.

All of that is in the PTI. It all has a group of people. That’s an expense. Plus ICANN has expenses: overhead expenses, expenses, legal support, shared services that they use. All of that go into one pool of money, and we said we would pay 675.

It’s not a fee per request. It’s not – it’s just a fixed-degree number. Could it be done for less? Possibly. Could it be done with the same rigor for less, the same level of reporting? We have a very high level of reporting for a very low number of requests – monthly reports, even though we only have half a dozen requests a year.

So given all the constraints we’ve put in on the service provider, there’s a lot of costs that would be a lot less if you and I were keeping track of this in Excel out in the hallway out here.

But I guess at a high level that’s your answer. Probably best to approach Kim Davies when we have the report later.

Owen DeLong: Okay. I think there’s a lot of ground in between the Excel spreadsheet and $675,000.

Louie Lee: If there’s nothing else? Thank you.

John Curran: Any other questions? All set. Thank you, Louie.

(Applause.)

Proposed ARIN Fee Schedule Increase

John Curran: Okay. We’ll now move into our policy block, And I think the first one is going to be up – actually, I’m going to take a moment.

Do you have the updated slides that Nate sent this morning for the fee? Okay. Can you put them on the laptop. Sorry. Might as well get that over with because we’re a little – a couple minutes early.

So I’ll introduce what I’m about to say. So yesterday when we did the fee structure change proposal, I put up a set of slides, and about halfway through the presentation people who were watching me would notice I visibly paused.

I kind of stalled and did a little reboot out here. It was about 15 seconds of silence because I realized the slides I put up were slides from four months ago, the first draft of the slides I did, not the ones that have been through the whole process.

And so the numbers are wrong. Nothing is wrong about what we proposed. The discussion is still just as relevant. The feedback you gave us is just as useful. But, for example, those slides showed the total amount of revenue being recovered from all the legacy – from the legacy holders as being $200,000.

Well, that’s next to impossible because there’s only – there’s only about 500 legacy holders. That would average $4,000 increase per legacy holder.

So the numbers I had up were a very early version, and we caught that, I caught that, a number of Board members caught it. Our Treasurer caught it. But I finished the presentation. I just want to say we’re going to update the website with the correct numbers, but I wanted to show what they were.

Everything here is all the same. Everything here is all the same. These numbers are what actually gets generated by the proposed fee increase – facilitator fee increase, 34,000, because effectively 1,000 per facilitator, a $900 increase per facilitator. And end-user maintenance generates approximately 1.4 million.

And then for LRSA fees, the increase of $50 per object for LRSA users generates about $33,000. The total increase about 1.47. The amount attributable to LRSA holders is about 33,000. Just want to make sure you have that.

That’s what this looks like on our base case. Our base case has a situation where, you know, our reserves are dropping, our net position, our investment balance drops in 2018. Not as much in 2019, ‘20, ‘21, or ‘22, because we do have a reduction in expenses.

But our base case still shows our reserve balance dropping over time to about 17 million in 2022. With the fee increase we end up about neutral in terms of revenue and expenses. So our reserve balance and investment balance overall is pretty much maintained.

These are the correct numbers. Nothing else is – you had the discussions with a couple of numbers that were just off because it was my very first draft before people like our actual finance department had even looked at them.

So the right slides are online, and these are the correct numbers. And we did get a lot of feedback, and we’ll be taking that back to the Board to try to figure out what to do with the proposed fee increase. That’s it. Thank you.

Recommended Draft Policy ARIN-2017-13: Remove ARIN Review Requirements For Large IPv4 Reassignments/Reallocations

John Curran: Okay. Now we’re going to move ahead into our Recommended Draft Policy, and this one is Recommended Draft Policy 2017-13: Remove ARIN Review Requirements for Large IPv4 Reassignments Reallocations. It’s Recommended Draft Policy.

I’ll give the history of it. Because it’s recommended this might be the last time you’ll see it at an ARIN meeting; literally, this could be put into last call and sent to the Board of Trustees and be in the NRPM, in the Number Resource Policy Manual, the next time we get together.

So let me give you the history. It was submitted as ARIN Policy Proposal 248 in October of last year. It was advanced to Draft Policy in November and Recommended Draft Policy in March 2018.

As a Recommended Draft Policy, the Advisory Council is saying that it is clear, technically sound, and it provides for fair resource administration.

It has not yet been presented at an ARIN meeting. It’s coming to this meeting, but it’s considered in such good shape that it could, again, be advanced into the policy manual right after this meeting.

The shepherds are Springer – John Springer – and David Farmer.

So what this does is it removes the requirement for staff to review and approve customer reallocations for reassignments that’s presently contained in NRPM 4.2.3.5. We would not have to then approve the large reassignments and reallocations that are made from direct allocations.

If you have a large block and in turn you reallocate a large block, we, right now, by policy, are to review that large reallocation.

We will continue following our processes for reassignments and reallocations to verify usage for IPv4 requests submitted for the wait list or recipient transfers.

So to the extent that you’re saying that reallocation is why you have less space, then it would still be subject to review at some point if you then end up with a request for wait lists or you put in a request to receive resources.

It can be implemented as written. There’s no material legal issues regarding the proposal. The impact is minimal resource impact. We update our internal procedures, do some staff training and minor engineering work.

So I’m now going to have the Advisory Council presentation, and that’s going to be presented by John Springer.

John Springer: Good morning, ladies and gentlemen. You’ve already seen this. I did want to point this out. Essentially the implication of this is that – current practice is that when you make an allocation of an 18 or a 19, a sub-allocation or assignment of an 18 or 19, that process is reviewed by ARIN at that time.

This policy would remove that check at that time. However, the check would still take place the next time you come for another transfer or to go on the wait list.

Essentially what we’re doing here is this Section 4.3.2.5 was put in place to be sure that people were not gaming the system by receiving allocations of 16 or above and then assigning or sub-allocating them in such a way that they would immediately qualify to come back for additional resources in an unfair way.

Because the free pool is gone, it is postulated that that’s no longer a relevant situation. Current market value – you would need to be getting about a 16 to be sub-allocating or assigning 18s or 19s, and the market value of those these days is a million bucks. So theoretically nobody is doing that maliciously.

The effect of this Recommended Draft Policy is to remove this section, 4.2.3.5. It’s in your copy of the NRPM in your printed guide, online, a number of different places here for your convenience.

There’s been a modest amount of discussion about this on the list. So far it has been relatively noncontroversial. And there’s been a modest amount of support on the PPML for it.

So assuming that we don’t light a fire here today, shepherds intend to take this to last call after the meeting.

Paul Andersen: The policy after the social, it was a bit of a tough, tough slot. This may be the last time you will see this proposal at a meeting.

So the microphones are open, remotely and in person. Again, do not stampede towards the microphone. I’m worried for your safety.

Rear microphone, please.

Cathy Aronson: Hi, Cathy Aronson. I support this. I think this is great. So thanks.

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

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written. This is work we just don’t need to be doing anymore. And thank you for the cleanup, the author and the AC for shepherding this along. And, yes, please, make it happen.

Paul Andersen: Support, thank you. Anyone else wish to speak to this? It is important to speak even just to say, as those two did, in favor or against. Does anybody want to give reasons why this policy is not a good idea?

(No response.)

Paul Andersen: This just goes to show the quality of the social last night because everyone is still recovering. So congratulations to staff on that. Chris? No?

If we do not see the stampede stop to the microphones in the next five seconds, we’ll have to close the microphones.

But, again, noting this will be the last opportunity for you to – potentially the last opportunity for you to comment on this. And the AC is looking for your feedback.

John, anything you want to add? No. Quiet bunch. It’s just striking one section, so fairly simple policy change.

Okay, the microphones are now closed. We will thank John for his presentation. Thank you.

(Applause.)

Paul Andersen: Wait, John, we have a late-breaking comment. So remote participation comment, please.

Chris Tacit: From Jason Schiller, Google, also AC – ASO AC. Sorry.

I previously worked for a large ISP. This clause was to help ensure a large allocation/assignment was not made incorrectly which would make the ISP ineligible for additional ISP space. I have not heard this is still needed. I suggest it should still be optional. I support as written.

Paul Andersen: Thank you for that comment.

Chris Tacit: And Ryan Jones: I support as written.

Paul Andersen: Anyone else want to quickly speak since we did reopen for a second? Start moving. No. Okay. Thank you very much again, John. Sorry about that.

(Applause.)

Paul Andersen: You get a second clap. All right, given that this is a Recommended Draft Policy, I will now ask the question, and, yes, stretch your arm for just a minute, which I think is probably good this early in the morning.

So if you could please – the question being whether or not you support the policy, ARIN-2017-13, as written. Would all those that are in support please raise your hand nice and high and keep it that way. Thank you. And you may lower.

And I’ll ask all those opposed to this policy 2017-13, please raise your hand nice and high. Remote participants please indicate online via Slack now, I guess. Thank you, you may lower your hand.

We just wait for the tabulation. Everybody waking up. Perhaps a quick round of applause for all the staff that did organize that very lovely social. It seemed to be very well attended. Good music, good food. Lots of entertainment. So thank you.

(Applause.)

Paul Andersen: The team always puts on a great show. The envelope is coming. Given it’s early in the morning, I’ll double-check it’s the right one and not Best Actress.

Recommended Draft Policy ARIN-2017-13: Remove ARIN – Remove ARIN Review Requirements for Large IPv4 Reassignments and Reallocations, 92 in the room, eight remote; 29 in favor, 0 against. We’ll pass this on to the AC, and we’ll move on to the next presentation. Thank you.

The Current State of RDAP

John Curran: Okay. Thank you very much. Excellent. I’m going to have Andy Newton come up and give a presentation on the current state of RDAP. I think it’s fairly important as we evolve the technology that makes us all work. Go ahead, Andy.

Andy Newton: Thank you. My name is Andy Newton. I’m the chief engineer for ARIN. And I think two years ago I came and gave a presentation on RDAP. So I’m going to give an update on the state of things.

So RDAP – getting back to the basics of what it is, it’s the Registry Data Access Protocol. And its genesis really was from where ARIN and the RIPE NCC separately developed protocols that allow you to get to Whois data via RESTful means. Turns out they were incompatible. We did these kind of separately and didn’t know each other were doing it.

As it also turns out, there have been a lot of people who complained about Whois in the past for other reasons.

And these complaints are basically things you’ve probably heard of before: There’s no internationalization in Whois. There’s no clear way of understanding where to find the authoritative server for data. There’s no authentication.

There’s no security. That’s a big one now since privacy is a big concern these days.

And probably the biggest issue with Whois is the standard actually does not specify the different data formats. So nearly every server operator has a different data format, and it doesn’t make it easy to write clients that can parse that data.

These things have been talked around ‑‑ about for a long time. And the Whois, the RESTful services that the RIPE NCC and ARIN did kind of helped prime the pump at the IETF to start working on a standard RESTful way of doing this.

The IETF started looking at this in 2011, and in March of 2015 they finally produced some RFCs on it.

So the basics of RDAP. It’s a RESTful service. It’s JSON over HTTPS. The HTTPS provides the security and the authentication, and the JSON provides structure and internationalization support. The protocol itself supports both domain name registries and IP address registries.

And the way the protocol is structured is that the features of the protocol – the queries and the data model for representing IP addresses and Autonomous System Numbers and getting all that information – is really a superset of what the domain name registries need.

Turns out that IP address registries also have domain names. We call them reverse DNS. But a lot of those semantics are the same. The only place it really does not overlap is with nameservers. We tend not to have first‑class nameserver objects, where the domain name registries do.

The way the JSON is modeled is done in a way that allows someone who is programming to this to be able to reuse code over and over and over again.

So it defines some common data types and then wraps those or puts those into some common data structures which are repeated throughout the JSON.

Finally you have object classes which represent things like IP networks, Autonomous System Numbers, domain names, and so forth. And then those are all wrapped up into containing objects called search results. So it’s fairly straightforward.

The other thing that RDAP gives you is bootstrapping. This is how you find the server that you need to query. And in RDAP, the way the IETF specified this was they said the IANA should produce some JSON files that clients could go and get periodically and parse.

So, the IANA has these files. They’re listed here. There’s two for IP addresses ‑‑ one for Autonomous System Numbers and then one for domain names.

So in the IP addressing model, the way this works for bootstrapping is not as straightforward as it is for ‑‑ it’s not exactly the same as it is for domain names because we have ERX and we have transfer resources between regions.

So the way it would work really is a client would query an authoritative server. In this case we have the client querying for 45.65.1.1. And it would ask ARIN, hey ‑‑ IANA points to ARIN saying that space resides with ARIN; however, it’s been transferred to APNIC. So the ARIN servers would then return an HTTP redirect saying ‑‑ telling the client to go talk to APNIC.

In this model I actually have a bootstrap server in here. That’s kind of a helpful service. It wasn’t specified by the IETF, but there are these things called bootstrap servers, and I’ll talk about them in a minute.

So, March 2015 is when the RFC came out. It’s been about three years since RDAP has reached proposed standard status by the IETF. So where are we?

At present, all the RIRs have deployed RDAP. Each one has an RDAP service that has Whois data in it, and you can query it and it works great.

The other thing we have are these things called bootstrap servers. So what a bootstrap server is, it takes those four different IANA files periodically from IANA, puts them into a web server and allows a client, an HTTP client, just to send the query directly to the bootstrap server.

And the bootstrap server then does a redirect, an HTTP‑level redirect to the proper authoritative RIR server. So the clients no longer need to worry about getting bootstrapped data if they don’t need to. That’s great for things that are like running in web browsers and so forth.

ARIN developed a bootstrap server. We deployed it. We open sourced it. And shortly after that, LACNIC took the open source code ‑‑ they needed some other features in it that we didn’t provide. So they took that, they improved upon it, and then they’ve deployed it as well. So both ARIN and LACNIC have bootstrap servers.

On top of that, LACNIC has two‑tiered authentication. Now, this is a topic that’s been talked about in the Whois space for a long, long time – getting two‑tiered authentication to Whois data. So LACNIC has actually gone and done it.

If you query LACNIC server and you do it repeatedly over and over again, they’re going to start rate limiting you.

If you want to, if you really have a good need for that data and to query them so often, you can apply for an API key, very similar to the API keys that we use for our Reg‑RWS service. You can apply to LACNIC for an API key, and they’ll give it to you. And you can use it with their RDAP service, and your rate limits will go up significantly.

The domain namespace, a lot of good stuff has happened in the RDAP world. Unfortunately it hasn’t been such a good run on the domain name side.

So far we only have four ccTLDs who have deployed an RDAP service, and then one gTLD provider, which would be Verisign.

So as far as tooling goes: ARIN, LACNIC, and APNIC have all developed conformance testing tools. So these are test suites that anyone can download and they can run against their RDAP service to test whether they’ve met the letter of the law as far as the RFCs are concerned. And these help both server operators and client implementers.

ARIN’s also developed a command line client called NicInfo; it’s the best‑in‑class command line client according to the Mark Kosters Software Review Index. That’s a joke. If you have a system capable of doing Ruby like macOS or Linux, you can even do this on a Windows box, just type “gem install nicinfo” and you’ll get the client.

Looking at GitHub there are over 30 projects that are RDAP related. So there’s a lot of code out there.

And APNIC has a really cool ‑‑ I couldn’t find the link, but APNIC has this really cool tool called Visual AS, or vizAS, which they use to query autonomous system information from the different RIRs, trying to map out how the networks are pieced together. And it’s a very interesting little research tool they have.

And I would be remiss not to point out that APNIC has done a lot of work as far as social media goes, and they have a nice blog series on RDAP as well.

I think about a year ago, maybe two years ago, Geoff Huston demoed this at an ARIN meeting. This is the APNIC RDAP history tool. And when he came and demoed it, we were all like: “Ooh, aah, that’s really cool.”

Well, they actually went back and improved upon it. It looks even slicker than it did before. And here’s the URL, if you want to go look at it, query it and play with it. It’s a wonderful little tool.

And finally we have LACNIC’s RDAP web client. This is very new. In fact, I’m not sure everyone in the LACNIC community has seen this. But they told me about this last week. This is their RDAP client. It’s completely inside the browser. It’s 100 percent JavaScript.

And I was looking at it, and they may potentially open source this software. They’re looking at doing that. And if they do, there’s potential that ARIN and LACNIC could collaborate on this.

We have an open suggestion for implementing an RDAP Web Client ourselves. So this would be a good opportunity to collaborate for the RIRs.

It’s actually written in AngularJS, and as it turns out, we have a lot of developers who are familiar with that framework. So it’s a good opportunity.

The future. So, ARIN is looking at providing a way to search for networks based on Origin AS. As some of you may know, when a network is registered with ARIN, there’s an opportunity for the registrant to put the Origin AS information on that network. And we’re looking at ways to allow you to search RDAP for the networks based on the Origin AS that’s been provided.

At the IETF, I only have one thing listed here, but there are two efforts going on there. The guys at Verisign, who are doing a bang‑up job, the guys at Verisign are looking at object tagging. And basically what object tagging is, is being able to create a namespace for nameservers and POCs and Orgs and things like that. They’re called entities in the RDAP space. And being able to create an official way of creating a namespace for them.

So it really codifies some of the things we’ve been doing here in the RIR world where you see “-ARIN” on your POC handles or “-RIPE” on the RIPE contacts. It’s a way of codifying that so it’s much more of a best common practice.

As a side note, Scott Hollenbeck at Verisign started on that effort about two years ago with the IETF, and he just now finally got it up to the adoption phase. So sometimes things move a little slower in the IETF than we’d appreciate.

So, anyway, the other thing that is being worked on – again Verisign is doing the bulk of this heavy lifting here – is the federated authentication with OAuth. So again, they’re looking at using OAuth 2.0 and the OpenID Connect standard to try to allow federated authentication with the RDAP.

So what that means is you’d have third‑party entity providers providing identity so RDAP servers could do authorization based on those identities.

And if you think about that, maybe an example of how that might work in our space is: I said LACNIC has a rate limiting that goes on, well, as opposed to applying for an API key from LACNIC, there may be a future where they trust identities from ARIN.

So you could actually query the LACNIC server and have your rate limits go up, based on the identity that ARIN provides if you have an ARIN Online account something like that. That’s the type of possibilities we’re talking about there.

Finally, there have been some gaps that we’ve noticed between the RDAP implementations. Matt Griswold did this great presentation called “Death to Whois” at the last NANOG. And he’s been playing, because ‑‑ he’s been looking at using RDAP for helping out with the PeeringDB work. And he’s discovered some inconsistencies that we probably need to clear up.

And on top of that, there have been a couple of people who have commented on Mailing Lists, both at RIPE and ARIN, noticing that there are some things we need to fix. And we’ve also discovered these internally as well.

So we’re working with the staffs of the other RIRs. We’re going to address these problems. In some cases they are fixes to our implementations, just things that just slipped through the cracks.

In other cases, we actually need to do improvements to the standard itself. We need to either go back to the IETF and get things extended or have some best common practices about how the operating model works.

And, finally, this is an outgrowth of APNIC’s history tool, but there’s been some talk about doing bulk RDAP. Now, what this would be is all ‑‑ a standard way of representing all the data in a bulk format. The idea here is that since most of the RIRs have bulk data formats, but we all don’t do it the same, it would be great if there was a common way of specifying this data.

So when you’re writing tools you use the ‑‑ do bulk imports from the different RIRs, you don’t have to do it in five different ways. And it also would work for the domain name registries as well.

So, that’s it. Any comments, questions?

John Curran: Microphones are open.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Yesterday we had a bunch of discussion about data privacy. Any thoughts on features or capabilities we need in RDAP to help support that?

Andy Newton: So that would be more on the lines of the two-tiered authentication, and I believe RIPE does this to a certain degree. They will – they do this with both Whois and RDAP. Whereas, if you query them at a certain rate, they’ll give you – I think it’s email addresses and names.

But if you go over a certain threshold, they start just backing off the data they give you. They’ll still give you the results, but they won’t give you all the PII or what could be considered PII. That’s one way of doing it.

We could also just do simple tiered authentication where you authenticate to the server and you get the PII, whereas people who don’t, don’t get it. It’s technically possible. It’s really more of a matter of policy.

David Farmer: Okay. Thank you.

Andy Newton: Yes. Paul.

Paul Wilson: Yeah, thanks, Andy. Paul Wilson from APNIC. That’s a really interesting presentation. I’d like to see some do it at coming APNIC meetings, because we think RDAP is pretty important. So really nice to see that. And thanks for the links to APNIC.

For information, if anyone is interested in seeing either that VizAS tool, it’s apnic.net/vizas – v-i-zed-a-s – and WhoWas is apnic.net/whowas, which is an easier URL than that one. So that’s just for information.

Something that occurred to me very briefly yesterday – I haven’t had the chance to think about this properly – is just, again, in another, in an extension of our use of RDAP, would it be appropriate to use RDAP to retrieve that API access to the routing registry, which was raised I think by Owen yesterday?

It’s not something I’ve thought about deeply, but it may be something that we could consider if API access is actually being requested.

Andy Newton: For provisioning the data or for getting the data?

Paul Wilson: For getting the data, for query.

Andy Newton: Yes, we have thought about doing extensions for that as well.

Paul Wilson: Okay, great. Thanks.

Andy Newton: Mr. Kosters?

Mark Kosters: Yeah, Mark Kosters, ARIN. Andy, could you go to the federated authentication? Can you talk a little bit about what we’ve done at ARIN regarding OAuth?

Andy Newton: Yeah, so, we’ve actually created – we’ve taken an open source OAuth server, I think Mitre wrote it, and we’ve done some back-end work to integrate it into our systems.

The use of OAuth – we’re not just looking at it for doing RDAP work; we’re actually looking at it to create session state on the client side for ARIN Online.

So we have a number of suggestions that have come into ARIN about increasing the time-out and doing things to make ARIN Online better as far as how a customer sees that.

And what we need to do – there’s an architectural issue that we have with ARIN Online where we need to move session state into the client, because right now it’s kept on the server. And that will improve the user experience of ARIN Online tremendously. And OAuth is one of those keys to getting that done. And that’s how the authentication will work.

As I’ve talked to – I’m not a security expert, and I don’t like to play one, but I’ve talked to security experts who deal with web authentication, and they’ve said – the messaging I always got was “don’t try to create your own security framework on the web. You’ll probably mess it up. Just use OAuth.” And that’s probably a pretty good idea in my opinion.

So we’ve looked into that. We have some OAuth work done. It’s still sitting there ready to go. We’ve had – sometimes the best-laid plans of mice and men don’t go the way you want. But we have it. It’s still there.

And hopefully when we get around to getting back to dealing with some other issues that we have going on within Engineering, we can actually deploy OAuth. And the plan is to, when the IETF gets around to specifying how OAuth works with RDAP, that we’ll be ready to go.

Yes, Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. Really great to see open source tools available for this. You want to bootstrap something? Make it easy. And those tools make it easy. The more tools available in open source, the more it’s going to get used. Just guaranteed. That was the first thing.

The second was in regards to Origin AS, just a clarification. Origin AS is an ARIN-unique – it’s used predominantly in the ARIN region as part of the application process or part of ARIN Online, or is it used across all of the regions?

Andy Newton: So, that’s a good question. I was, up until about two months ago, under the impression that ARIN was the only RIR that did this, but I was informed that LACNIC also does it.

And while they, as far as I know, don’t have any plans to do with this RDAP, they are looking at what we are doing, and they may try to implement it themselves. But they do do this as well.

Kevin Blumberg: So where that was going was having a feature matrix among the RIRs as to, oh, supports this feature, this feature, this query, this feature, the same, so that we know when it’s the same and when it’s different or when the results – when this feature is only supported in ARIN versus it’s supported in all five of the regions, or LACNIC only supports this feature.

Having that matrix is really useful when somebody is looking to – especially a multinational is looking to deploy this type of – or use these types of services.

Andy Newton: That’s a great idea. I will say the protocol itself does announce those types of features. But unless it’s written down somewhere, it’s hard to get to. So that’s a good idea.

Alicia Trotman: Hi, Alicia Trotman, government of Barbados and ARIN AC. I see you have some ccTLDs there. We actually enlisted a .bb ccTLD, and I was wondering what’s the procedure to deploy? And is DNSSEC, even though it’s security, the reasons for that is security, we’re not yet DNSSEC compliant, and is it required to get on board with RDAP?

Andy Newton: No, DNSSEC is not required. The requirement is that you stand up an RDAP server and then you go register it with the IANA. That’s really all there is to it. Now, standing up an RDAP server can be easier said than done, I understand that. So that’s going to be the big hurdle. But getting it into this list is really a matter of registering it with the IANA.

Alicia Trotman: Okay.

Andy Newton: And we have a remote participant?

Chris Tacit: Yes, we do. Thank you. Andrew Gallo, GWU: What, if anything, is the relationship between Origin AS and the Whois record, RPKI, and ARIN’s IRR project?

Andy Newton: That’s a good question. Some people have noted that a route object in the IRR and RPKI ROA and then all of a sudden this Origin AS on a network semantically look the same. And in many cases they’re communicating similar or the same data. I believe really the only difference is the intent of the person who gave the information to us.

So in this case, we would have to go read the policy under which we register the Origin AS. But I don’t know if the network operators register that information with us with the intent that it’s used for creating routing filters or whatever.

It’s much more the case with ROAs and IRR route objects. So that’s really where the difference lies, is the intent of the person who gave us the data.

Yes, David Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. One pedantic point. The three things you just mentioned – Origin AS, ROAs, and route objects in IRRs – there’s some minor details about, is it just the specific route or is it less or more specific routes included.

There’s some details and difference between them. Origin objects, if you read the – more specifics, in theory, should be included. Route objects, they should not be. And ROAs, depends upon what the ROA says. The ROA has semantics to decide that. So there’s some subtleties there.

Andy Newton: Right, exactly. And certainly an RPKI ROA object is a little more expressive than this Origin AS. But it all does come down to mapping an AS number to a prefix. So the semantics are very, very similar.

Aaron Hughes: Aaron Hughes, in this case, no particular hat, just a point of information related to the last question. There is some work being done in the community around standardizing where to get useful – authoritative source of information about AS Set to prefix.

I believe Job Snijders is leading the effort around a discussion for rewriting IRRd with the intent of, when a ROA is created, removing all IRR objects from all IRRs running the software, and instead create an object saying there is a source that is pointing at a ROA, to clean up this mess over the long term.

The discussion is starting. I believe he’s going to do a presentation at RIPE in Marseille in a few weeks, but to address this exact issue, who’s got the authoritative source or where to build the prefix list from.

Andy Newton: Yes. Any other questions? All right. Thank you.

(Applause.)

AFRINIC Update

John Curran: Okay. Next up we will start our RIR updates, and the first one is going to be Ernest coming up and doing the AFRINIC update.

Ernest Byaruhanga: Good morning, everyone. I’m Ernest, and I bring you greetings from AFRINIC, from Alan and the entire team from Mauritius. And I’ll take a few minutes to give you some news about what’s been happening over in AFRINIC, starting with some statistics.

In 2017, we issued about 7 1/2 million IPv4 addresses. And that was about 36 percent less than we had issued in 2016. We also issued 113 /32s of IPv6 address space as well as 150 Autonomous System Numbers.

And 2018 so far, we have issued about 10 percent of a /8 in v4, that’s 1.6 million IP addresses, 12 /32s of v6 space and 43 ASNs. Our current IPv4 address inventory is about 67 percent of a /8.

Membership. We had 144 new members last year. And so far this year we have signed on about 40 new members. That brings us to a total membership to date of about 1,570.

The total v4 space held by all members is about 102 million IPv4 addresses. V6 space is about 9,200 /32s. And on the legacy side we have about half of a /8 of v4 space held by legacy resource holders.

So we are already in the IPv4 exhaustion Phase 1, according to our soft landing policy, which defines the various phases of v4 address exhaustion.

And we entered Phase 1 in April 2017. So we’re effectively issuing space from the last /8 that we received from IANA. And in this Phase 1 we can only issue a maximum of a /13 of IPv4 address space, which when we cross to Phase 2, the maximum will be a /22. We shall cross to Phase 2 when about a /11 is left in our inventory.

We’re, however, focusing not so much on how long v4 space will last, so our capacity-building team is putting a lot of effort in getting v6 space deployed on the continent by training as many folks on the continent as they can and sharing as much knowledge as they can through our training programs.

A bit of news from the policy development side. We have a couple of policy proposals that are open and under discussion, the first one named PDP-bis. Our authors like to use this “bis” naming a lot. That’s the Policy Development Process-bis. It’s a full revamp and revision of our Policy Development Process, and it mainly looks at putting in place clearer mechanisms for appeals and disputes. We have it in our PDP, but it has some issues that could be improved.

The authors are also proposing that by introducing distinct phases in the policy proposal lifecycle, which is lacking currently, and a bit more transparency around consensus gauging, because we have a couple of times when consensus has been declared and the community felt maybe there wasn’t consensus.

Second proposal, lame delegations in the AFRINIC reverse DNS. This actually was ratified already by the Board and it’s currently going through the first stages of implementation.

That policy proposal that is under discussion is the Internet Number Resources Review proposal. So this one effectively allows AFRINIC to conduct audits on how members are using IPv4 address space as well as other types of resources, but it’s mainly focusing on IPv4 space utilization.

And these audits can be random audits or they can be triggered by anybody, a whistleblower. So anybody can call AFRINIC and say, hey, organization X we feel is misusing IP address space and please audit them. And this policy would allow for such a scenario to happen.

And any member that fails an audit would have their space reclaimed and reallocated.

The Registration Services Agreement already has provisions for these audits to happen. The authors felt there should also be some policy provision for that.

Next, IPv4 soft landing bis. So this is another proposal that is supposed to be a complete replacement of our current soft landing policy, which defines how we manage space from the last /8.

The key highlights from this proposal is that in Phase 1 currently we can issue up to a /13 from the last /8. So this proposal reduces that to /18. And it also reserves a /12 to facilitate v6 deployment.

So this proposal, although it’s currently under discussion, but it had actually crossed that stage last year. We had a meeting in Lagos where consensus was declared on it at our face-to-face meeting.

And according to our PDP, it had to go into a last-call period. And it went into last call, and consensus was again declared after last call. However, some members in the community felt that there was no consensus and used the mechanisms in the Policy Development Process to appeal the decision of the Co-chairs. So the appeals committee indeed upheld that appeal, and over time the decision of the Co-chairs, and the proposal is back on the Mailing List for discussion.

We received a couple of IPv6-related policy proposals, four of them, from the same author. And I believe some of these have already been proposed in other RIR communities. The first one is IPv6 policy and references update received on – some time last month.

And it removes or corrects several inconsistencies in the current IPv6 policy text, and also the proposal improves on the definition for utilization.

The next up, from same author, clarification on IPv6 sub assignments also received last month. Clarifies the concept of sub-assignments in Article 6.8 of the AFRINIC Consolidated Policy Manual.

Next from the same author, IPv6 initial allocation update, also ensures policy text is aligned with a wider set of possible v6 deployment scenarios, also from the same author.

And next from the same author, IPv6 PI update. This proposal updates the relevant text in the Consolidated Policy Manual to accommodate the possibility to obtain v6 PI space, even if the requesting party has no v4 PI space.

So the current process in our policy provisions is that if you want IPv6 PI space, you must be able to show that you either have v4 PI space or you can qualify for v4 PI space. This is the issue that the author is trying to address.

Last but not least, a bit of news from our capacity-building team. We’ve been doing a lot of training, especially IPv6 training, as I mentioned before. And last year we reached about 639 individuals on the continent from 19 distinct African countries where we aggressively tried to give them hands-on knowledge on deploying IPv6.

The same capacity-building department is in charge of a program called FIRE Africa. This is a program that allocates money to individuals with some interesting projects that do align with our mission. And we gave out about 350,000 US dollars to 13 winners in this area.

The same capacity-building program is in charge of giving out fellowships and looking for suitable fellows to attend our meeting. So far 12 have been selected this year to attend our upcoming meeting in Dakar, in Senegal.

Our next meeting is next month starting in – starting late April with some AfNOG workshops. AfNOG is similar to what you have here as NANOG. But our public policy meeting starts on the 9th of May. It’s going to be an interesting meeting. You guys are welcome to come and join us in Dakar.

Thank you. I’ll be happy to take any questions.

John Curran: Microphones are open. Any questions for Ernest? Okay. Thank you, Ernest.

(Applause.)

John Curran: Okay. Actually, next up is – I see Oscar here for LACNIC, I think. Oscar? Oscar will give the LACNIC update.

LACNIC Update

Oscar Robles: Thanks, John. Good morning. My name is Oscar Robles, and I’m the executive director of LACNIC. And today our talk is going to be around these three topics. So let me jump into the presentation already.

As you can see, we have had a strong growth in the membership numbers. Steady, mainly driven by the smaller allocations, the micro small and the small allocations, the pink ones and the purple. And additionally, last year we created a smaller category than that, than those, which is the nano, which started to appear in these graphics.

Those are the numbers. As you can see, it’s a very steady growth, more than a thousand new members every 10 to 11 months.

As I was mentioning to you, last year the general assembly of LACNIC, the membership, approved the integration of new categories: The nano, which is for smaller than /22, blocks smaller than a /22, which is a /24 and /23, and we differentiated the bigger categories, bigger than extra-large, from 2XL and 3XL until 6XL, or 6 extra large.

Also the general assembly approved the decrease in the fees for ASN allocations to nano and micro, micro/small categories. That was in order to facilitate the ISP, the smaller ISPs inclusion.

As everybody may be aware, a year ago we started the Phase number 3 on the soft landing policy, the IPv4 and depletion. And we expected to have this Phase number 3 for five years, but now that we’ve been in one year with this phase, the expectation is now to last only two more years, which is a reduction of two out of the five initial expectation.

And as you may know, this phase is – we allocate the space only to those organizations that have not received any previous allocation from LACNIC of IPv4, of course.

A few years ago, two years ago, the LACNIC policy process approved the transfers besides the mergers and acquisitions transfers. So there are internal transfers already, and only intra-RIR. And we have had only 15 transfers, 1-5 transfers, in these two years. These are all the transactions – transfers we have had in this 24 months.

And last month we just announced a service, a listing service for transfers, where we list not only those offerings, the space, those requesting space and the brokers or marketplaces for IP transfers.

In a few hours of publishing that service we received more than 40 requests to be listed as recipients of space and only two for IP brokers and marketplaces. So if you are interested to be part of this listing services, just let us know.

What else? So also as part of our cooperative procedures, every year we remove part of our Board. And last year two positions were to be for election. There were 13 candidates from 10 different countries, and the voting process in October resulted in Gabriel Adonaylo re-election and Rosalía Morales elected for the first time.

Actually Gabriel is around here with us. Just raise your hand.

They will be – their time will be three more years in the LACNIC board.

As part of our commitment to a secure and stable and open Internet, a couple of topics. First, as Paul was mentioning in the NRO data, we are working with the other RIRs to the deployment of the 0/0 in the RPKI route. And the relevant part – or thing I want to highlight here is the collaboration between the technical teams in the five RIRs.

Also, in the DNS security and stability, we have worked with route server operators for the deployment of global nodes in our region. The K instance and the I-root instance were deployed in the recent months.

So the thing is that we are not root server operator, but the root server operators recognize LACNIC as a relevant partner to identify relevant networks and organizations willing to have their own node in their facilities or their network. So we’ve been doing this for a while now.

Then talking about the IPv6 readiness, taking information from RIPE website. Almost 40 percent of the LACNIC networks are able to transfer IPv6 traffic. As you can see, this is higher than the average in the – in the world. And we note that not everything is readiness but also content.

And speaking on our content, Uruguay has grown tremendously in the last month, up to 30 percent of the traffic. Mainly driven by the incumbent, the main operator, which is Antel. And they introduce IPv6 in the broadband, in the residential broadband. So they have jumped into the top place of the region with that 29th, almost 30 percent of traffic, IPv6 traffic in Uruguay.

Brazil maintains a steady deployment with around 25 percent. And the good part here in Brazil is that it’s driven by many players, not a single operator, but many regional and smaller sized ISPs, which are more tempted to do innovation and new things.

And Tobago and Ecuador maintains 20 percent of IPv6. Peru used to be an early adopter, then they stalled at around 15 percent. And the good part now is that they started to grow again, but they fix something that they had in their implementation that prevented others to actually see them through IPv6, and now it’s a cleaner implementation, it appears.

Argentina and Bolivia, Guatemala, Mexico, they’re starting to deploy IPv6 now with good numbers.

Most of our efforts are intended to build capacity in IPv6, of course. And as you can see, more than 50 percent of our trainees last year in online training and webinars and in person, more than 50 percent of them were IPv6 courses and untrained.

2018, we’ve trained already 500 professionals, and we already have an online course, a continuous online course on IPv6 basics. So we expect to have – to grow this number of people trained by 20 percent at least for the 2018.

And we recognize that not everything is technical training, but we tried a different approach, an additional approach last year, and we will see in a few years whether or not we were successful.

In Guyana and Suriname, we picked these two countries because we felt that the traditional larger countries will have their IPv6 deployed sooner or later. You can see Chilé has a flat line with the 0 percent IPv6 deployment. But we think they will end up having an IPv6 deployment sooner or later.

But we are allocating efforts to those countries that will be facing good challenges in the next five years. So we picked Guyana and Suriname and approached decision-makers, not technical guys. Well, it happened that those in charge of those organizations used to be engineers or have a technical background, but the thing is they’re not there for the technical knowledge but for the – as decision-makers, either executive director or CFO.

We talked with the Ministry of Telecommunications in Guyana, for example. Catherine Hughes is in Suriname. We talked with the operators and the parliament as well, talking about IPv6, IPv6 risks, IPv6 opportunities.

As you may know, that area of Guyana, Suriname, and French Guyana is a very rich area with oil, and they’re having a lot of discoveries of oil, and they’re seeing increase in activity, in commercial activity.

So there’s a lot of services growing and a lot of demand for Internet access and security and security cameras. So it’s starting to have interesting economics in the region.

So IPv6 is one of the things that may help them to address all the requirements for access for the people in the region. So we approached them, and it’s been only ten months since we attend these countries. And we are trying something else in – something similar in Central America. And we’ll report after that, after a while, after a follow-up, whether or not this was successful.

So then going back to other initiatives, you probably know FRIDA, which is a Regional Fund for Digital Innovation. We have two topics for this 2018 announce, and one is community networks and the other one is gender and technology.

We have had a lot of proposals sent to this fund. Last year – 2016 we received more than 500 applications, and last year there were more than 300.

Additionally, we have a couple of initiatives supported by other organizations, one like – it’s called Ayitic, that is funded by IDRC, and it aims to increase women’s access to digital employment and capacity building on the Internet, skills in IT. And it is fully funded by IDRC.

Another, a smaller project, is with Google to develop workshops related to IXPs in the Caribbean and Central America.

Then talking about policy proposals. As you can see, there’s been interesting growth in a number of policies proposed in our public forum. It’s been a continuous growth since 2014.

And this is very good news. We are now trying to see that the discussions are really happening, not only quantity, but we would like to have also quality of discussions in the region. But that depends mostly on the community, and that would be up to them whether to adjust or adopt the Policy Development Process in the region.

Additionally to the two main events of LACNIC, we have smaller events, mainly in those places that will be unable to host a bigger event. And we organize these smaller events jointly with local organizations, or even with the traditional partners in the region, which is Internet Society and ICANN, but also with local partners.

For example, in Guatemala we organize it with .gt, in Guatemala ccTLD. And we call it, those events, LACNIC on the Move, with the authorities, the local chapter of Internet Society, the regional Internet Society liaisons and ICANN.

Guyana, same thing, with the Ministry of Telecommunications, CaribNOG and other organizations in terms of ICANN and CTU.

And this year, 2018, we’ll be organizing at least two more LACNIC on the Moves. One in Paraguay. It’s already defined for June 5th to 7th, together with CNC, which is an academy, and COPACO, which is operator, and IXP in Paraguay. And also in Nicaragua to be confirmed and defined, the exact dates, later.

And finally, last but not least, in two weeks we’ll will be having our 29th event in Panama, Panama City. And realizing that this is not the updated presentation, because the updated one, it has the link with the remote participation, but it was – that I included in the last one.

I will share – probably if ARIN help me to upload the newest version, you will see in this slide the link for the remote participation. Those wanting to see what is happening with the global policy related to the global RIR or with the ASO consultation, if you’re interested to follow up our regional discussion as well, it will be webcast as well.

And the other event in the second part of the year will be in Rosario, Argentina. It’s the third largest city in Argentina. Now it’s mainly known because it’s the birthplace of Lionel Messi, the best player in the world. So if he wins the World Cup, then it will be a nice place to visit.

This is my update. Thank you very much. Any questions?

John Curran: Microphones are open. Any questions for Oscar?

Chris Tacit: One remote comment. Brian Jones says: Good to see the kind of growth in the deployment of IPv6.

Oscar Robles: Excellent. Thank you.

John Curran: Thank you.

(Applause.)

John Curran: We’re scheduled for the break now, and I don’t want to deprive of you that. So we’re going to go on break, and we’ll come back and resume at 11:00 with Recommended Draft Policy 2017-10. So we are in recess until 11:00. Thank you.

(Break from 10:37 AM to 11:03 AM.)

Recommended Draft Policy ARIN-2017-10: Repeal Of Immediate Need For IPv4 Address Space (NRPM Section 4.2.1.6)

John Curran: If folks will come in and be seated, we’ll get started.

Okay. Welcome back. I’d like to get started on our second policy of the morning. The second policy is 2017-10: Repeal of Immediate Need for IPv4 Address Space.

I’ll give the staff introduction. This is a Recommended Draft Policy. This policy meets the criteria for inclusion in the NRPM. Meaning it’s technically sound, it administers fair and impartial administration, and defines a clear problem.

So this policy could be, having been recommended, could be after this meeting, sent to the last call on the Mailing List and then sent to the Board of Trustees.

So this is your last opportunity to comment, potentially, on this policy. It could come back because they could revise it. But just think about that. It is a Recommended Draft Policy; potentially would be updating NRPM in the near future.

So I’m going to give the history of it. It was submitted as ARIN Policy Proposal 245 in October, was advanced to Draft Policy in November, and advanced to Recommended Draft Policy at the February meeting. It has not yet been presented at an ARIN meeting.

The AC shepherds are Andrew Dul and Chris Whitfield. It removes Section 4.2.1.6, Immediate Need. This section requires justification to show that address space requested will be utilized within 30 days of the request.

It does mean that customers will no longer be able to request space under the immediate need urgent basis of 30 days of the request. Given that, we have a depletion of the free pool. The requests have been disapproved since it’s impossible for us to provide address within 30 days. The section is effectively inoperative as long as we have a depleted address pool.

In addition to removing 4.2.1.6, the NRPM will also require updates to the following section which reference immediate need: Section 4.3.4, Additional Considerations References, and Section 4.5, Multiple Discrete Networks.

This can be completed as written. There’s no material legal issues.

Resource impact. It has minimal impact. Three months after ratification, it can be implemented with the typical updated staff guides and training, and a small amount of engineering work.

At this time, I will invite Andrew Dul to give the Advisory Council presentation.

Andrew Dul: Good morning, everybody. My slides are coming. All right. This is pretty simple.

As part of the cleanup effort of the v4 section, one of the things that was identified at the last ARIN meeting was that the immediate need section is now inoperative, basically, because the free pool is basically empty. So let’s remove inoperative things from the NRPM and make it easier for everyone to understand. That’s where this comes from.

The staff assessment that we received earlier noted that immediate need was in a couple of other sections in the NRPM. We did an edit to the original text and cleaned up the text so that immediate need now doesn’t appear anywhere in the NRPM.

So we don’t have references to things that don’t exist. That’s always a good thing.

This is the old section for those of you curious. Basically you could get up to a /16 if you could show a need within 30 days. But, again, ARIN couldn’t actually fulfill this request today because ARIN doesn’t have addresses to give out within 30 days. So we have an inoperative section.

These are the text cleanups that were done to two different sections to remove references.

And the discussion points for today are do you support removal of this section, or are there any issues that you perceive that could occur because we do end up removing this?

So that’s the presentation.

Paul Andersen: Thank you, Andrew. I’ll wake you up by moving this mic. They’ve really oiled that thing.

Microphones are open on ARIN-2017-10. Please approach a microphone. Start typing remotely.

Joe Provo: Joe Provo, ARIN AC. Thank you for the cleanup. Yea.

Alison Wood: Alison Wood, State of Oregon, ARIN AC. Support this policy as written. Always in support of simplifying.

Paul Andersen: Thank you. A simple discussion for a simple policy.

Far microphone tested. I guess the microphones got raised a foot. Aaron, did you go adjust all the microphones?

Kathleen Hunter: Kathleen Hunter, Comcast. Support as written. Any cleanup is good.

Paul Andersen: Would anyone like to speak opposed, perhaps, a contrarian view? This is your last opportunity potentially to see this proposal.

We’ll be closing the microphones in a few seconds if we don’t see anyone moving. Chris Tacit, anyone Slacking away?

Chris Tacit: No, sir.

Paul Andersen: Microphones closing. Three, two, one. Microphones are closed.

We’re on a roll this meeting. Thank you, Andrew, for that presentation. Let’s thank Andrew, please.

(Applause.)

Paul Andersen: Our esteemed counters are in position. So this is a Recommended Draft Policy. So I’ll ask the question of those who are in favor/against of the proposal ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space as the text has been presented, would those in favor please raise their hand nice and high. You’ve got some sugar at the break. So that should be – there we go. Getting some response. Remote participants, please participate in the Slack.

Thank you. You may lower your hand.

All those opposed, please raise your hand nice and high. Thank you for your remote participation. Do they vote in Slack? I don’t see the remote that often.

Many exciting updates coming up. RIPE NCC and APNIC still to come, and some exciting IPv6 case studies, I hear. I’m sure there’s some raffle survey that people should be filling out. Just trying to fill the time.

John Curran: Sing.

Paul Andersen: No, you don’t want that. The Maple Leaves won last night. So that’s good news.

All right. On the issue of ARIN-2017-10: Repeal of Immediate Need for IPv4 Space, 81 in the room, nine remote; 25 in favor, 0 against. We’ve got a streak going here. This will be provided to the AC, and we’ll move on to updates. John.

APNIC Update

John Curran: Thank you. Very good. We’re now at the point where we’re going to catch up on the schedule, and next up would be Paul with the APNIC Update.

Paul Wilson: Thank you, John. I’m still feeling a little disoriented, I have to say, by the deviation of our traditional alphabetical ordering. But it could be something more to do with last night’s social.

(Laughter.)

Paul Wilson: I think. Okay. So this is the APNIC Update. I’ve got 30 slides, and I’ll try to cover them in ten minutes.

APNIC stands for global, open, stable, and secure Internet that serves the entire Asia-Pacific community. We report our activities according to our service to APNIC members, our support for Regional Internet Development, and a whole lot of cooperation we do within the global Internet community.

I’ll start with our membership. Our membership at the moment are about 6,500. But when we combine all the members of our NIRs, we have more than 14,000 organizations served by APNIC, projected to be over 16,000 by the end of the year. So our membership is growing in a fairly healthy direction at the moment.

Other activities are slowing down a little. So v6 delegations last year were down on the year before and projected to be about at the same level by the end of this year. Likewise, IPv4 delegations.

IPv4 transfers are increasing in number, but slowly. It’s still a bit early in the year to be projecting forward reliably, but we are fairly active in that area.

That said, it’s only projected to be around 300 transfers total for the entire year, and that’s a much lower level of activity than, for instance, at RIPE NCC and lower than people might expect for the Asia-Pacific region. I don’t really have any comments as to why that is, but it’s been traditionally fairly low.

Moving on to some services. WhoWas, which was mentioned kindly by Andy Newton before, that’s available at apnic.net/whowas, and it’s interesting because it’s a browser-resident browsing interface there. It downloads a bunch of RDAP results in an RDAP extended format that we’ve defined collaboratively with the other RIRs in the ECG, by the way.

But having downloaded that bunch of data, you then get to browse it and see the difference between successive versions of records and so forth. So have a play with that.

Resource certification. Pretty active in promoting the registration of ROAs with our Ready to ROA campaign and T-shirts and so forth. But we’ve only got about 2 percent of allocated IPv4 address space under ROAs at the moment, and that’s just growing quite steadily with – slowly but steadily with the promotion that we’re doing through training and other activities.

Talking about training, very active area of our organization always. We’ve done 16 trainings so far this year in 12 different economies, 500 trainers – trainees, that is.

We’ve got a bunch of community trainers being developed. So we’ve got a network of people out there in the community who are helping us with training.

We’ve got e-learning. We’ve got training videos online which get a lot of views.

We’ve also got something called APNIC.academy, which is our online, self-paced, certificate-based learning platform. There’s three courses on there at the moment.

We’ve had more than 2,000 enrollments and more than 400 people certified through that platform in the last – since it was launched about this time last year.

And we’ve got a fairly active program of new training that’s going to be delivered through there for IPv6 routing protocols, address policies, DNS, et cetera.

Moving on to supporting regional Internet development. We have policy under this banner. You’ve heard a little bit about the regional policies so far this meeting. So I won’t go into those in detail.

But we are trying to increase engagement with the policy process with updating web content, with webinars and promotion of the PDP at NOGs in the region. We’re also translating summaries of policy processes and outcomes into different languages of the region.

And we had a mock policy SIG which was very successful at the recent APNIC 44 meeting, and that seemed to spark more active participation in policy discussions.

Around the community we see NOGs as a very important channel for outreach. Last year we participated in 24 different NOGs around the region. You can see from the red dots there that we do have a stack of NOGs and related activities around the whole Asia-Pacific.

We’re still doing work on root server mirror installations. We’ve got a few MoUs. We supported IXPs in the last year in PNG (Papua New Guinea), and in Fiji.

Fellowships are also an active area of fundraising for us. We had 44 fellows at APNIC 44, and 23 of those were female. We’ve got a new returning fellows category. We sponsored 40 different regional events in 2017 as well, including 19 NOGs around the region.

Some of our budget allocation for root server deployment went last year to ISC to fund them to develop the RFC 8198, aggressive NSEC caching in BIND, and that allows DNS resolvers to discard – well, to cache negative responses effectively and save the load on root servers from those resolvers.

That’s actually launched, and it’s in deployment at the moment. We’re going to be measuring, to the extent we can, the effect of that as well.

Security is a really hot topic in our region. Our regular stakeholder and member survey has directed us over the years to training activities, to providing support from members in IPv6. But for the last few years, security has been the top priority of our members, and also an area in which they ask for our support.

So we had 30 security training courses last year. We delivered training to law enforcement agents in a few cases. We had a bunch of other security-related engagements.

We work with FIRST. Our guy, Adli Wahid, is on the FIRST Board and does a lot of work with them.

We’ve got a second full-time security specialist on staff. And together with guests, we’ve had 65 blog posts about security to the APNIC blog.

So we’re trying to satisfy the need of our members, not for security across the entire range of security topics, of course. That’s much too huge, but it’s about security that relates to our membership in particular. So routing security, of course, would be one of those.

But other related aspects as well, one of those being CERT. So we’ve also helped to establish a couple of CERTs in the Asia-Pacific region, particularly in the Pacific where the Tonga CERT was the first Pacific Island nation CERT. The PNG CERT was also launched earlier this year.

And we actually raised a bit of funding for supporting that activity to make it – to accelerate the support we’re giving to CERTs around the region. That’s something that a lot of people are very interested in, and we feel it’s also something that is very relevant to our membership in that part of the world as well.

IPv6, it is still – although it’s second, it comes second to security these days as a priority, it’s still something that we’re doing a lot of support for. So, again, it’s training, it’s e-learning, it’s providing presentations to audiences who are interested in IPv6 and how it’s going and how to increase IPv6 deployment. And, again, a lot of blog postings on IPv6.

The blog is there. It’s getting about 40,000 views a month these days. We’re getting a lot of guest bloggers who are contributing to it. So the idea is not always to have APNIC staff blogging but also to bring in relevant content from elsewhere.

It’s mostly about IPv6 security, training, NOGs and DNS according to that word cloud that you see there.

Last year we launched something called the APNIC Foundation. The idea of the foundation is to be effectively a fundraising arm for APNIC. So we have been undertaking – we’ve been spending about 20 percent of the APNIC budget historically on supporting Internet development in the region.

So we always find that although we spend quite a bit of funding on training and technical assistance and NOGs and our conferences and so forth, we always find that there’s more demand than we can meet.

So the idea of the foundation is to actually find people who are interested in working with us to increase some of those APNIC development program activities.

Some people interpret the foundation as a way for APNIC to spend money through a foundation. It’s the opposite. It’s the way for APNIC to actually raise more funding to support the work that we’re doing.

Lastly, on cooperating with the global community, we’ve got a lot of research that’s done out of APNIC Lab. You all know Geoff Huston. He’s very busy, 39 presentations at 39 different events last year. A lot of research topics. He contributed to our work with ICANN on the DNSSEC key signing key rollover, a bunch of other stuff as well.

So, again, we did give ICANN some help. We also collaborated with the other RIRs on supporting the KSK rollover process.

Other work with RIRs from APNIC’s point of view includes a couple of staff exchanges with AFRINIC, working with LACNIC on an IPv6 workshop at APEC TEL, and a few other collaborative, cooperative activities there.

I want to spend a couple of minutes – I know I’m blowing my budget here, but I want to spend a couple minutes on the ASO Review. You heard a little bit about the review yesterday so I won’t go into that background, but the latest status at APNIC is we had a couple of consultations already.

We had one last year, and the main result of that consultation was that with guidance and with recommendation from the APNIC EC, the APNIC community agreed that we want to consider – in terms of the ASO Review report, we want to consider the non-status quo options which are provided in the ASO Review report.

So both the APNIC EC and the community agreed that we don’t want to stick with sort of business as usual for the ASO.

The other thing that happened in September last year was to set up a working group for the APNIC community. So there’s a group that’s now deliberating about the ASO Review.

We had our second consultation in February, and at that consultation there was sort of a straw man proposal that was basically to take the second non-status quo option, or Option 3, from the ASO Review report and flesh it out a bit more.

So it was called the two-house model of the ASO that was developed in this proposal. It proposed to have – to sort of rebrand or rebadge the different components of the collective RIR engagement with ICANN instead of being under the NRO EC, which represents registry matters when we go to ICANN, and the ASO AC which represents community policy, to instead badge those two things simply as two councils of the ASO calling them the Policy Council and Registry Council.

There was discussion but no consensus on how many members those councils should have or what the selection mechanism should be. So it was very much a simple sort of direction setting and a straw man proposal that was agreed by the community there.

So that discussion is underway. And just in graphical terms, we’ve got the sort of different interpretations of what the ASO looks like, whether it’s something that is the NRO or whether it’s something that comprises the NRO, what its components are. Always seems to be a matter of some confusion.

But the idea of this new ASO would simply to have – to be – to use this new structure as our interface into ICANN and simply to have something called a Policy Council and something called a Registry Council covering the policy issues and the operational RIR matters.

Okay. Finishing up, APNIC’s latest survey is going to be launched this year. This is something that we do every two years. So from the 28th of May we’ll be asking our community to give us their inputs on APNIC performance and future priorities.

And our next conference is in the Pacific. If anyone would like to join us in Noumea in New Caledonia, it’s a very, very nice place, and everyone here is, of course, very, very welcome. That’s happening in September this year. After that we have conferences coming up in Korea and in Thailand.

We have a blog, and we have a bunch of social network channels there. And that’s all. Thanks very much.

John Curran: Okay. Any questions for Paul and the APNIC update? No. Thank you, Paul.

(Applause.)

John Curran: Okay, next up will be Axel giving the update for the RIPE NCC.

RIPE NCC Update

Axel Pawlik: And so I will. Good morning, people of the ARIN persuasion. Nice to see you again. It’s been a while. I’m particularly grateful to be out here in the sun.

It did bring me a sunburn on my way out to South Beach on Sunday, but we’re now back in the localized winter. So happy to have you for the update from the RIPE NCC.

I will not talk as much and as quickly as Paul. Also I have less slides in an attempt to get you to the next meeting, to the next RIPE meeting, of course.

Membership growth. Up and to the right quite dramatically. It’s not really frightening. We see what is happening. Yeah, it’s more than 18,500 and so many local Internet registries. That’s not our members. That’s the individual registries that give us our income. One member can have several LIRs. But that’s what it is.

So, yes, we have just announced that we ran out of our last /8 pool, and of course we will continue to allocate from what we have, the scraps. And they’ll last us quite a while, probably, still.

But this is now all space from blocks that have been returned to us, which is very nice. So a couple of years to go.

So lots of address transfers over the course of last year. That is interesting. That’s sort of a sharp up. But we don’t really think that was the address market, the transfer market.

There was a lot of business restructuring going on. So we have the remaining, less than 5 million addresses that have been transferred on the market, unrelated LIRs. So the rest is restructuring, of course.

Seeing that, quite a number of people who set up like 10 or 20 LIRs at the same time or want to do that, one number that is sort of related anyways. But, yes, lots of smaller blocks being shuffled around.

We do see more LIRs without IPv6, which is at first a bit of an alarming thought, but it’s not that dramatic. You see the little red line going back up again since ‑‑ where is that? ‑‑ 2016‑ish or so. We do see steady growth in LIRs with IPv6, which is fine, probably all is okay.

We have seen the drop there after we began the IPv6 requirement. We have ‑‑ we ‑‑ after we removed the IPv6 requirement for /22s where it didn’t really make that much sense and some other impact there.

Capacity building. Similar to other RIRs, we reach out within our service region. We will have lots of regional meetings. We find them really, really helpful. Network operator groups and the like.

Next week I’m going off to Tehran and then to Moscow and to Timisoara and corners like that where we don’t regularly go with big RIPE meetings, even with the NOGS of the world, although Caribbean NANOG meeting.

So Network Operator Groups, we find them very, very helpful. It’s great to instigate and push and help locals to come together and talk to each other, but also we find we’re very closely related to those people anyway and they basically bring out our messages there as well.

We do do member lunches. People like to come to our trainings and similar things and events in the region, and occasionally we just pop in a lunch there. Free lunch is good. People do come and meet our folk and can tell us what they want from us and get to learn about us.

We do still the IPv6 Roadshow program. We do the Train the Trainer programs, other training courses. I’ll talk about that in a little while.

We have still country‑focused meetings where we look at the map: Oh, we haven’t gone to Kazakhstan, for instance. So we’ll go to Kazakhstan this year.

We have roundtable meetings for governments still and also meetings for law enforcement and also training courses there. And we have a new staff member in the Caucasus for the Caucasus, so that’s also quite helpful.

I’m very proud to say that since recently we have agreed with the American University in Beirut to incorporate our training material into their course material, and their students can actually earn credit with our material. And of course we want to bring that out to more universities. So that’s a good thing.

Also we’ve done the RACI program. We’re still doing this. We reconnect with the researchers communities and bring them over to the RIPE meetings and the regional meetings. That seems to work quite well too.

Talking about training, we have a new feature, RIPE NCC::Educa, or however you pronounce that. It’s basically a giant webinar of sorts where we have a full one‑day online event when we have to tread really carefully in the office, lest we disturb the guys there.

And we invite external experts in on a particular subject matter and just keep on going for the whole day. It’s quite amazing to see that we do get quite a number of participants. And it’s popular. So we’ll do more of that.

April we have done one on routing security, and the next one again on IPv6, surprise there, next month.

We have quite a number of interesting thoughts about trainings and slightly more formalization of that so we can stick the certificates with the real verified people and roll it out in that way.

I won’t talk much about the policies. We’ve heard about that before. And the Internet of Things is an interesting phenomenon. For quite a while we thought: I don’t know, is that something for the RIPE NCC to be active in or not. Well, number registry, or something else.

So we had quite a number of birds of a feather session in a number of RIPE meetings, just feeling our way with the community, what our community members think our role would be.

And of course I have been told once at a regional meeting, I think that was in Minsk, that I should tell the Chinese government to have those things made properly so that it can be updated and they’re safe and secure.

And I’m honored to say that our members have quite a lot trust in us and see us as great authority. I’m not sure that I have that much influence with the Chinese government, but I’m happy to try.

So, Internet of Things, what are we going to do there? I don’t know really yet. We have started a working group within RIPE. And I take my clues from there ‑‑ my cues from there. Just let them tell the RIPE NCC folk what our role should be, and we’ll be happy to do what we should be doing.

Next working group there. I think it’s the first one as a working group will be in Marseille. We have heard about the GDPR and General Data Protection issues here. I’m happy to say I don’t have to talk about it because John has done it very nicely for me.

Our argument is pretty much the same.

And with that, I will tell you that of course we are doing many more things and many more exciting things. If you want to hear about them, come to Marseille. It’s May, southern France, it should be really nice. Also you can talk to me over coffee if you want to. I invite you to do that.

Also Andrew is here one, of my staff members, and Dima is here, and Dick is here as well. So grab us. But, of course, I’ll see you in Marseille, I hope. Thank you. If you have any questions?

John Curran: Any questions for Axel and the RIPE NCC report? Thank you, Axel.

Axel Pawlik: Thank you.

(Applause.)

John Curran: Okay, next up we’ll have Kim Davies give the IANA/PTI Update.

IANA/PTI Update

Kim Davies: Good morning, everyone. My name is Kim Davies, President of PTI. As I think everyone is aware, PTI is the nonprofit that was created in 2016 to provide you with the IANA functions.

I started in this role on January 1st, and this is my first ARIN meeting. Thank you, everyone, for your hospitality.

IANA functions are typically divided into three areas. So I’m going to focus on number resources.

Just a quick view of our team. Currently we have 15 people that provide you with the IANA services. Probably a lot of our functions are integrated. They’re not really divided into who does number resources, who does naming functions, and so forth. But this is the team behind the services we deliver to you.

Annually we do a Customer Satisfaction Survey. This is one of the key pieces, key mechanisms we have to hear back from our customers to make sure we do course corrections and adjustments to how we deliver services.

The survey is segmented. So we send different survey components to different parts of our user base. In the context of number services, our primary mechanism of surveying is to send an annual survey both to the RIR CEOs and also to the Registration Service Managers at the RIRs.

This past year, participation rate in the survey was 26 percent. This is a little lower than previous years’ average. But that being said, it’s a fairly small sample size. So I wouldn’t read too much into that.

From those that did respond, the satisfaction rate was 100 percent and the average over the past four years was 99 percent.

All five respondents, basically – and I think this was echoed by the report we heard earlier today – indicated there was no customer service-related issues that they received from the IANA functions in the past year.

And as is consistent with previous years, we asked our customers to rank the different facets of the services we provide in terms of what’s most important, what’s least important. And accuracy and timeliness were ranked 1 and 2, what we should focus on when it comes to the numbers function.

We produced a monthly performance report for the number services. This is the report that we just published a couple of days ago from March.

It provides you with our adherence to the SLAs, and you can drill down onto exact time stamps if you want to do more analysis on that.

We’ve met every SLA every time since this was constructed. So we’re batting a pretty good average right now, and our goal is to continue to do so.

Another important part of the culture of how we deliver the IANA services is one of having third-party auditors come and review our internal controls and our business processes to ensure they’re fit for purpose.

We do this by conducting two separate audits. One of particular interest to this community is what we call our registry assignment and maintenance systems. These are the key systems we use internally to provision our service to you, our ticketing system and various other technical systems that are used to publish our registries.

Like I said, we have a third-party audit of this done annually. We passed our 2017 audit with no exceptions. And this year, in particular, was notable because under the new PTI arrangements, it was the first time we explicitly included number resources in scope to the audit.

Another audit that we do, which is of a different level of complexity, is a SOC 3 audit for our root zone KSK. For those that aren’t familiar, we also maintain the trust anchor for the DNS, and that requires the private key for the root zone key signing key to be stored in a fairly secure facility and to go through quite comprehensive procedures in order to use and manipulate the key.

And all those procedures are audited. We have third-party auditors every time we use the key, and that separate audit pertains just to that business process.

One last thing I wanted to note about the audit program. We’ve been auditing ourselves since 2010, and we’ve used PricewaterhouseCoopers in all those years doing that function.

We put out a competitive RFP last year to identify a potential new vendor to provide audit services. After a thorough review, we actually did select a new auditor which commences this year.

The new auditor is RSM, which is not one of the big four, but I think they’re No. 5 globally. But they have a particular practice that specializes in some of the areas that are specific to us. So we’re looking forward to having that special attention on our area of interest.

Just a quick update on the recovered pool allocation. The global policy for post exhaustion IPv4 allocation by IANA essentially states that those IP address blocks that IANA has recovered because they’ve been surrendered by the previous registrant are to be allocated automatically every six months to the RIRs, and the policy specifies a formula in how that is done.

We last ran that formula at the beginning of March, which allocated every RIR eight /24s. As of right now, we have I think 33 /24s left in the pool. Should we not receive any more allocations back to us, this will mean that in September we’ll allocate every RIR four /24s, and we’ll allocate every RIR two /24s in March 2019.

And then at the conclusion of March 2019, we’ll only have three /24s left, which is below the minimums for us to do further allocations. So we will just sit on those either until we receive more or until the policy is altered.

I feel I don’t need to rehash this because it was a presentation that was earlier this morning, but top level is we’re encouraged by the process, and I think the RIR community, much like our other communities of interest, are wrestling with the first-year process of building out the procedures involved in doing these kinds of annual reviews and processes associated with the new Post-Transition IANA.

We’re very pleased with how that relationship went, and we’re looking forward to improving that, if necessary, in future years.

I did want to mention one of the key projects, not just for PTI but for ICANN in general, over the past year has been the KSK rollover. This has been a multiyear process to replace the trust anchor for the DNS for the very first time.

We’re doing a lot of outreach and a lot of engagement on this simply because it is – the process has not been exercised in the past. Because of the way the trust anchor is configured individually in many different appliances and applications across the Internet, we really don’t have a good handle on who the population is that need to make manual – or adjust their configurations as a consequence of this.

But, in essence, there is an automated mechanism within the DNS to update the trust anchor, and we’re really trying to capture configurations that haven’t automatically processed this rollover.

Now, we were planning to do this in October of last year, but we did get some telemetry data fairly late, just a few weeks before that date, that we wanted to study further. So we did delay the rollover.

Now, we have studied the data, and data continues to roll in. Our best assessment is to reschedule the rollover for October of this year. We just had a public comment period to get feedback on whether that is appropriate. We’re now analyzing the comments, and we’ll be producing a response to those in the coming weeks.

And then just a summary of some of our ongoing work within the team of interest. As you would have heard earlier, we’re drafting a revised AS registry that excludes the inter-RIR transfers that have been added to the registry over the years.

This is following discussion with the leadership of the RIRs who requested this. We’re very happy to do it. So we’re just looking at our historical data to make sure the revised registry is accurate.

And we’re going to vet that with the RIRs. Once we’re all on the same page that this is an accurate representation of the historical allocations, we’ll be publishing the revised registry.

We are reviewing our data collection practices in light of the GDPR. With respect to the IANA functions, we have a Whois server, and we have several thousand registries that we publish, and many of them do contain personally identifiable information.

We’re really going through an exercise of working out mapping that to legitimate business need and making corrections if necessary.

The vast majority of those registries we maintain are at the behest of the IETF. So a lot of that discussion will be with IETF leadership identifying areas where protocol parameter assignments have been made and PII can be altered or stripped out of those registries.

Our biggest internal project right now is building a workflow management system for protocol parameter assignments. In terms of how we do our work, this does include number resources. We consider number resource allocation a specialized kind of protocol parameter assignment.

This is mirroring work we did in previous years to support our domain name activity. Today, if you run a top-level domain, you have a self-service portal, you log in, you submit change requests. It’s all processed within that system. You can track it. And all the parts of the business workflow that could be automated are automated. So that’s something we would like to map across to our protocol parameter assignments.

So in close discussion with the IETF in particular, in the beginning we’re modeling all these datasets and trying to integrate them into a system, and then slowly but surely we’ll be building out processing workflow in that system.

I give you awareness because it is a large part of the work we’re doing. I think the net impact on RIRs is going to be fairly small given the number of requests we do per year for RIRs, and we’re already quite timely in how we do those change requests.

But it will have some effects that will improve the data access that we offer. Our new APIs, for example, to access our data, new APIs to submit change requests, abilities to RIRs to do more self-service than they do today.

And also by using automation, we should reduce the possibility of error caused by manual processing. So that should improve performance and accuracy.

One last thing that I wanted to flag is one necessary consequence of the separation of PTI from ICANN is that we have a wholly separate budgeting process from ICANN, but that budgeting process needs to roll back into ICANN’s budget.

And that means that we actually have to plan our budgets over a year in advance, which means that our fiscal year ‘20 budgeting process actually will begin next month.

So for the coming months we’ll be consulting with our stakeholders, including the number resources community, to identify what our priorities should be in fiscal year ‘20, and that will then be then turned into a proposed budget that will be put for public comment which anyone can provide input into.

Once that has been approved by PTI, the top-level amount will be rolled into ICANN’s overall budgeting process that happens towards the end of the year.

That’s all I had today. Happy to answer any questions.

John Curran: Microphones are open for questions.

Owen DeLong: Owen DeLong, no affiliation at the moment. Couple of questions. First, how did the KSK rollover end up in PTI? I thought the split to PTI was so that numbers and protocols went off and did their thing and the ICANN organization was left to the DNS people.

But the KSK rollover is entirely DNS related. So it seems odd that that ended up being saddled onto PTI.

Kim Davies: So PTI provides all the IANA services across all those three areas – domains, protocols, and numbers. My recollection, and I’m happy to be corrected, is the actual split of PTI was at the request of the names side. I think the numbers community, the protocol parameters community didn’t feel as strongly about that.

But there’s various agreements. The ICANN and the RIRs have an SLA agreement. The IETF and ICANN have an MoU. And ICANN has a contract with PTI to deliver the naming functions.

But wrapped up, PTI does all the day-to-day work, just as it did prior to transition. It’s all the same staff doing the same work we did pre-transition and post-transition. Does that clarify?

John Curran: So everything that was being done under the IANA functions contract, all of the IANA functions, all were – effectively became part of the affiliate. The IANA functions contract included nominally the NTIA oversight of a contract with ICANN that provided them to do the central numbers registry, the protocol registries, and the DNS root zone. So all of that went into what became the PTI affiliate.

Owen DeLong: Okay. Stranger every time I ask.

(Laughter.)

Owen DeLong: Secondly, as I understand it, and I’m not – still not clear whether that $675,000 figure that’s talked about is ARIN’s contribution or all the RIRs combined – it’s all the RIRs combined. Okay.

So we’re paying $675,000 a year essentially for the operation of a registry that doles out /12s to RIRs as needed in v6, will be done distributing IPv4 in six months or so, and doles out blocks of 32-bit ASNs for the foreseeable future.

That does not seem to me like it should take almost three-quarters of a million dollars to do per year. So besides number registry, where is that money going, and do we really need to be doing those other things?

John Curran: Just think about the fact that the plane costs a lot to operate even if there’s no one in the seats. And so the fact that our registries are small and we make few requests does not mean that the registry should not have to be appropriately administered at a high level.

I guess can you describe overall how much of PTI’s costs go to various functions?

Kim Davies: So I don’t have those numbers off the top of my head. And I apologize, I’m a little new at this. Sorry. I’m happy to look into that and provide further figures.

But I will say more generally that I think it’s deceptive if you look at just individual registries and the amount of effort just to maintain sort of that file. You could look at the root zone and say, well, the root zone is just a zone with like a thousand entries in it. That can’t be too hard, right?

I think there is a lot of overlay that goes on top of that. I mean, I’m traveling to some RIR meetings to do this kind of engagement, that costs money.

We have – the majority of PTI’s budget is shared services from ICANN, which is providing things like IT support, IT operations, legal support, HR, finance support, all those kind of things.

So I don’t want to speak for the appropriateness of the number. I mean, the number was what was agreed by the RIR community as part of the transition proposal.

But I think if you want to look at the IANA functions at large, we don’t partition our costs per registry. We look at the overall service and all the parts that go into providing service in general.

Owen DeLong: Well, given that the Board of ARIN is now asking us to pony up more money to fund various activities, we’re starting to look at where we might be able to reduce the costs that they’re looking to recover. So…

Kevin Blumberg: Kevin Blumberg, The Wire. Not speaking as a royal we. I have been in a PTI budget discussion, a public budget discussion. They’re lots of fun. There are lots of moving parts, just like our organization has lots of moving parts.

I wanted to confirm that KSK, which is an important role and function and has lots of auditing, which I never enjoy myself, personally, that is a function that is needed for reverse DNS, correct, which is an important function for us, not just doling out IP numbers, there are important other things that PTI does that have benefit to this community, correct?

Kim Davies: Correct. Having the trust anchor for the DNS enables DNSSEC, which in turn protects the reverse DNS string.

Kevin Blumberg: Thank you.

John Curran: Additionally note that the – to my knowledge, the IETF is not paying PTI for the Protocol Parameter Registry maintenance function, yet those protocol parameters are essential to having our registries, our v4, v6 registries, subsets of the entire v4/v6 span, someone has to maintain that.

We’re maybe a portion of that, but it’s still important that those functions get done to have an Internet.

Ron da Silva: Ron da Silva, ICANN Board, also Chair of the Finance Committee. I rise to kind of get clarity from your comments, Owen. I listened intently, and I was trying to understand: Were you asking about the 10 million dollar-ish budget for the PTI function within ICANN, and in the context of some of the comments were directed at budget inquiry and questions regarding ICANN’s budget, or was it specifically towards the ARIN Board and their contribution towards the PTI function? I was a little confused on where your questions were directed.

Owen DeLong: I’m specifically looking at the RIR contribution and specifically what’s going to PTI from that.

Kim Davies: Thanks very much.

John Curran: Thank you very much.

(Applause.)

John Curran: Okay. It is lunchtime for all practical purposes. The next thing up on the agenda is the Internet Number Status – sorry, IPv6 Case Studies is next.

Susan, how long will that be? Five minutes? Come on up. It will just be perfect.

IPv6 Case Studies

Susan Hamlin: Hello, everybody. I won’t keep you too long. So I just wanted to give a quick update or overview of where we are with our IPv6 outreach campaign.

So over, my gosh, a decade ago, we started bringing ARIN IPv6 booths to major trade shows around the country. We brought ARIN staff, we brought Advisory Council members. We were at that point giving high-level educational outreach about what is v6, you should start thinking about it. There were lots of booths and lots of people that walked down the hallways, ignored us, et cetera.

We continued to do that for quite a few years. We stood up a TeamARIN micro site to talk about our outreach activities. We set up an IPv6 wiki where many organizations contribute information in the early days about what they were doing and provided links to resources they knew about to help people with IPv6.

So fast forward five, six, seven years, we continued to look for opportunities to send speakers out, to the ISP community and others, to talk about v6 deployments, talk about coming to ARIN, we’ve been allocating, assigning v6 for a decade.

And here we are today. We have a little bit over 50 percent of organizations with an allocation or assignment from ARIN that also had their IPv6 block.

So last year we decided to shift gears a little bit and we did some email outreach. We started with organizations with IPv6 assignments, and we targeted the universities.

And we decided the best thing we could do or one of the ways we might be able to help the community is to find organizations who have actually deployed v6 or were in the early stages of deployment and see if they would be willing to share information to help others.

So that has turned into sort of the major effort we’re undertaking today. We have on the TeamARIN site now six case studies from universities.

How many of you all in the room have read any of those? I encourage you to go take a look at them.

We very recently started another outreach to ISPs. We looked at those organizations who have an allocation of v6. We’re doing a little research on those organizations whose public websites are v6-enabled, and we’ve been reaching out to these organizations asking if they would be willing to share their v6 experiences with a case study.

So we are trying to make this as easy as possible. Jennifer Bly, who is in the room somewhere in the back, is following up with folks.

We have maybe 10 to 15 organizations that have expressed some interest. So Jennifer is working with them, email, give you a call, chat with you, write up what you’ve shared and send it back to you. So we’re hoping to get some additional volunteers.

Some examples of what we have been publishing on the TeamARIN site here. We have a forward thinker section. These are folks who have early come to us with information to share. Kevin’s in the room. Kevin, where are you? Kevin Pack over here, NTT, a shoutout to one of our earliest forward thinkers.

A month or so ago we started a campaign on Twitter. We thought maybe a case study is too heavy a lift. So we ask if you all had a simple tip you’d like to share about IPv6 deployment.

We got a pretty good response. There’s a blog on TeamARIN about that, and there’s a board in the foyer where we’re asking people who would like to share a tip put it on there. We’ll collect those, probably publish that as another blog.

This is just a look at the case studies and the list of universities who have responded, and we’re working with others currently.

So this is really a shoutout to anyone in the organization whose organization is in the beginning, middle, have already deployed v6 in any part of your network, if you would be willing to share at a high level the obstacles you face, perhaps, the things that were easy, lessons learned, anything that might make a good case study or even a tip, we would like to publish that, and hopefully that will help others in the community.

So with that, any questions, comments, or if there’s any other ways you think we could be collecting/disseminating information that would be useful to you, I’d like to know. Remote participant.

Chris Tacit: Jason Schiller and Jeremy Austin both put their hand up.

Susan Hamlin: That means they’re volunteering? We’ll reach out to both you.

All right. Anyway, see Jennifer, Erin, myself while you’re here. Put a tip out on the bulletin board. It would be great.

John Curran: It would be helpful to have folks who have done v6 to help get that written up because it makes it simpler for other people trying to figure out how easy it is and what possible paths forward are.

Any other questions for Susan? Okay. Thank you, Susan.

(Applause.)

John Curran: Okay. We’re now going to break for lunch. And I’d like to remind people we’re coming back at 1:30. So lunch is outside.

The lunch table topics are set up. NRPM simplification. And NRPM simplification I heard was lonely yesterday. It would be great for people who would like a simpler NRPM go visit the table.

LACNIC’s Global Registry Proposal. They have a proposal for a global number registry. So people want to talk about that. Justifying IPv6 requests and IPv6 implementation tips.

So we also still want tree testers. Again, this is people navigating the website so we can understand how you use the website so as we roll out our updated website, it has good navigation. There’s a link in your welcome email and in the meeting app to test out navigation.

Our Tips for 6 campaign, if you have any good advice on how to implement IPv6 that we should be sharing with others, let us know.

Security. Take your valuables with us. This room is not locked. So if you want to keep it, take it. And that’s it. I’ll see everyone at 1:30. Thank you.

(Public Policy Meeting adjourned at 12:01 PM.)

Internet Number Resource Status Report

John Curran: Welcome back. Our afternoon agenda consists of the Internet Numbers Status Report – the Internet Numbers Resource Status Report. We have a Recommended Draft Policy on the agenda, an update to NRPM 3.6 annual Whois POC validation. We have an update presentation on transfers at ARIN. We have a Software Development Update and then our Website Redesign presentation.

We’ll then go in the second half. We have a Recommended Draft Policy to require new POC validation upon reassignment. We will not have the RDAP update because you already had it, and we have an Open Microphone session.

So busy afternoon. I want to get started.

At the head table we have Paul Andersen and Tina and Leif and Jerry Garcia – no, Joe Provo.

(Laughter.)

John Curran: Okay, very good. First item up will be John Sweeting doing the Internet Number Resource Status Report.

John Sweeting: Welcome back after lunch. I hope you all enjoyed it. I’m going to get started. All right. I’m John Sweeting, the director of Registration Services, and this presentation is going to be on the Internet Number Resource Status Report as of December 31st, 2017.

This is prepared. It’s a conglomeration of stats from all the five RIRs. So we start out with the IPv4 address space, the status of each of the 256 /8s. This hasn’t changed much in quite a while. I would assume everyone is pretty familiar with it.

Available IPv4 /8s in each RIR. The next time I do this presentation, I’m not sure when, which RIR meeting it will show up in, we’re changing this just a slight bit to show not what’s available in the free pool but what’s available to be issued under any type of policy.

So our 0.00 there would turn to 0.3, about, because it would cover the two policies, 4.4 and 4.10 for IPv6 transition under 4.10 and micro allocations under 4.4. Some of these numbers will change a bit based on our new definition of what we’re going to show here as available.

IPv4 address space issued from the RIRs to the customers in terms of /8s by year. As you can see, the heydays there were in the 2008 to 2011 for most of the RIRs, with APNIC leading the way. And it’s slowly, slowly, and then very quickly, going down.

IPv4 address space issued RIRs to customers, total. Nothing much has changed on this. APNIC still at 45-plus percent. ARIN is in there at 32.38 – or not percent but total /8s.

ASN assignments from the RIRs to the customers, how many ASNs have been assigned each year by RIR. Not really – nothing too astonishing there. It’s basically just been trucking along.

ASN assignments total per RIR. Here, RIPE is pretty much the leader here with 37 – almost 40,000. Here in the ARIN region it’s a little bit more than 31,000.

4-byte ASN assignments. The interesting thing here could be that ARIN, you see ARIN, we’re a little bit less than 800. In 2017, we went down from 2016.

Part of that – most of that is the fact that we treat AS numbers in the ARIN region as AS numbers. We don’t have a 2-byte, 4-byte designation for them. So we were – there’s a policy that instructs us to issue ASNs that are available for issue by the number.

So when a bunch of 2-bytes come back that have been – for whatever reason people have returned them, they’ve been reclaimed due to nonpayment or whatever, they come back, we wait until a certain amount of time until we’re sure they’re clean and they’re not being used by anybody, and then we reissue them.

And we basically had a pretty big backlog on that, and so we’ve issued a lot of 2-byte ASNs this year – last year and the beginning of this year.

And this is the total 4-byte ASNs by RIR from January 2007 till the end of December 2017. You can see again RIPE with 9,600 and ARIN, we’re there with 3,447.

IPv6 address space, how much has been allocated to the RIRs. There’s a /3 that’s out to the global unicast, and of that each RIR has been allocated a /12.

There’s also a miscellaneous /12 in there that – from what – it was before my time, but from what I understand, there was some maybe /23s that were given to the RIRs and some other space before we actually went to, hey, everybody’s going to get a /12.

IPv6 allocations to LIRs or ISPs, been pretty steady over the last – 2013 through 2017. As you can see, it’s pretty steady. A little up and down sometimes, but not much of a difference.

That’s the one thing about IPv6 that you’ll notice, even when I give the ARIN department report tomorrow, that IPv6 has stayed steady. Even with depletion and everything else, it stayed steady on what the allocations and assignments have been.

The total since January 1999 to the end of 2017, RIPE again is out there with 14,000-plus. And ARIN, we’re at 3,566.

IPv6 assignments to the end users. Again, this is by year. ARIN has been pretty steady. Most of the RIRs have been pretty steady in there. And the total over time, looks like RIPE, 2700 – but we have 2,791. I don’t know, do we win that one? It’s not a competition.

Okay. So percentage of members with both IPv4 and IPv6. This slide is also changing. It’s going to be broken out to show IPv4 and IPv6 and then IPv6 only. For ARIN, we’re actually – this month we’re up to 57 percent, and it’s like 40 – let’s see, 48 percent is a mixture of IPv4 and IPv6, and 9 percent have IPv6 only.

These are the links to the RIR statistics, for anyone who wants to go and dig deeper. And that is all I have.

John Curran: Any questions for John on the Internet Number Status Report?

Owen DeLong: Owen DeLong, ARIN AC. If you could go back, I think, one slide, two slides – there we go. It would also be useful to know what fraction of that is routed, just as kind of a baseline for usage.

I realize it’s not an entirely accurate indicator of usage, but I’m willing to bet that in some cases the space allocated is tragically unutilized to a much larger extent in – especially in some of the more successful RIRs.

John Curran: I guess, in general, the RIRs don’t deal with the routing of the space, public or private, or – Geoff Huston does a number of very good reports, but that’s not – you know, that’s not something that we systemically track. Are you saying we should show that on this slide?

Owen DeLong: I’m saying it would be nice to have it on the slide, because it’s a better indicator of what’s really going on with v6, even though I understand it’s not something that the RIRs have traditionally tracked.

John Curran: Okay.

Kevin Blumberg: Kevin Blumberg, The Wire. The one thing that might be within – or that is hopefully in your purview to track is how much of the /12s have been utilized between the RIRs.

And the reason I’m looking at it is we’ve spent a lot of time on v6 policy and coming up with more and more cases in if you have a v4 address, then you can get it, great.

But you said there’s a significant number in the ARIN region who have v6 only, and they’re now having to go through these complicated hoops, and we’ve had a lot of discussion about these complicated hoops.

If that number is really low, how many hoops do we really need in policy for the bare minimum, the 32 as an example, until people start – you showed the slide of the 506, five have been given out. But within our region of the /12, if 30 percent is being given out in total, you know, that sort of thing would be very useful for policy decisions.

John Sweeting: I’ll let John talk about it. All I wanted to say, this kind of addresses both of your questions, is we as ARIN can do that on our own and like by departmental update. If John wants to do that, wants me to do that, I can do it easily.

In order for them to go into this slide deck and these stats, it has to be all five of the RIRs to agree and the NRO EC to agree that they want to track those statistics and post them. So we can do it for the ARIN region, I think, no problem.

Kevin Blumberg: So just to respond to that one, that’s why I was asking, because I do believe it’s beneficial for the NRO EC to provide those stats, like they’re providing many of these other stats. It would be beneficial to the communities.

And, yes, if there is no agreement, I’d love to see it in the departmental, but I think it is good for the regions to see this as a whole.

John Curran: Anecdotally, I don’t believe any RIR has crossed into the second /12 of IPv6 space. I believe RIPE will be the first, if I remember correctly. RIPE is sitting at 70s or 80s percent. All of the rest of us are below that.

But we’ll talk about maybe getting a slide showing the usage of the IANA allocations or adding that to the IANA v6 chart that we already have.

Kevin Blumberg: Thank you.

John Sweeting: Okay. Thank you.

John Curran: Thank you, John.

(Applause.)

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

John Curran: We’re now going to move into the policy block. Well, actually, we’re not. We’re going to do that in about 30 seconds. So we’re going to start promptly at 1:45 on the policy block, and the policy that’s up for the afternoon is Recommended Draft Policy ARIN-2017-3: Update to NRPM 3.6 Annual Whois POC Validation.

Okay, now we’ll start. So the history of this proposal is that it was ARIN Policy Proposal 239 submitted in March of last year, advanced to Draft Policy in March. Recognized that it had a clear problem statement at that time. It was advanced to Recommended Draft Policy in February of 2018. It was presented at ARIN 39 and ARIN 40. The shepherds are Amy Potter and Alyssa Moore.

The Draft Policy establishes specific Whois Points of Contact that are required to be verified annually. It identifies organizations that are covered by the policy by the type of resources it holds – direct assignments, direct allocations, AS numbers or reallocation – and it excludes reassignments made to downstream end-user customers.

It defines the procedure to follow so that the POCs are verified annually through an email notification and instructs ARIN staff to mark POC records deemed completely and permanently abandoned or otherwise illegitimate as invalid. It directs action to be taken if the admin or tech POC has been marked invalid.

Staff comments. Quite a few. Section 3.6.5 is unclear regarding the scope of the impact to an organization with nonresponsive POCs.

“Any organization lacking a validated tech or admin POC will be unable to access the full suite of functionality” fails to specify what – the full suite of functionality, what’s the allowed or prohibited subset. We can guess, but we probably need some guidance.

We’ll guess, our interpretation will be – if it’s not otherwise changed – will be that an organization without at least a validated admin or tech POC will only be able to access payment and contact update functionality regardless of the contact used for access.

So they’ll be able to access their payments, because we like payments, And they’ll be able to update their contact information so they are no longer an invalid contact. Presumably that will get them to get to a validated contact to get to the rest of the functionality.

For organizations that have at least one valid admin or tech contact, the organization will be able to access full functionality even if access is via one of its other nonresponsive POCs.

So as long as there is a valid POC on the organization, it will be allowed to have functionality.

If instead the desired outcome is that only validated POCs may access full functionality, we need to have this made explicit to that effect.

The proposed policy does not impact ARIN’s ability to provide ongoing registry services, only the ability of impacted organizations to make changes to their Number Resources.

It can be implemented as written.

There’s no material legal issues.

Resource implementation would take about three months, requiring updated guidelines, staff training, and some engineering work.

I’ll now have someone come up. Amy. Yes, Amy, come up and give the AC presentation on this.

Amy Potter: Thanks, John. So this policy proposal deals with the problem of inaccurate and out-of-date information contained in Point of Contact records.

You’re going to hear another proposal after this one that deals with a very similar problem of ensuring that accurate information is provided at the time when these Point of Contacts are being created. But this proposal deals strictly with Point of Contact records and inaccuracies in those records that are already contained in Whois.

So the current policy text attempts to deal with this problem by sending out an annual validation email to every POC in Whois. Each POC has 60 days to reply, and unresponsive POCs are marked as such in the database.

If staff deems a point of contact to be completely and permanently abandoned or otherwise illegitimate, the POC shall be marked as invalid.

So despite the attempts of the current policy text, there’s still a huge problem with inaccurate POC information in Whois, which is how this policy came about.

We presented the first draft of this policy proposal two ARINs ago. That draft sought to improve the current process by limiting the scope of the point of contacts that were involved in the email validation process. Instead of going out to every POC in the database, it would only go out to the tech, admin, and abuse Point of Contacts for organizations that hold direct assignments, direct allocations, AS numbers, and reallocations. So it does not apply to reassignments.

The first draft also attempted to add some teeth to this process.

So Point of Contacts that didn’t respond to the validation email within 60 days are marked as nonresponsive. After an additional 90 days, and after ARIN staff has gone through thorough research and analysis, they’ll mark these POCs as nonvalidated, abandoned, or otherwise illegitimate, as invalid, and these records would then be taken out of reverse DNS and their associated resources removed from public Whois.

The feedback that we received from the community about this first draft was that it was far too extreme and they wanted us to pare it back a bit.

That brought about the second draft. The second draft maintained the same limitations about the scope of the participants to the validation email as the first draft, but it takes a less extreme approach to providing teeth.

So Point of Contacts that don’t respond within 60 days are marked as nonresponsive. After 90 days, thorough research and analysis, ARIN staff marks the nonvalidated, abandoned or otherwise illegitimate POCs as invalid. Organizations lacking a valid tech or admin POC would lose access to their ARIN Online account until a tech or admin POC has been validated.

There were a couple of issues that the community brought back from this draft. They thought that the first problem statement that was presented was a little unwieldy and they wanted it pared back, and there were also some issues with the language for the enforcement mechanism that was included.

So we addressed the first issue by simplifying the problem statement to say that many of the Point of Contacts listed in ARIN’s public Whois database contain out-of-date and inaccurate information.

We went through a couple of different drafts with the language of the reinforcement mechanism. This current draft actually came about after the staff and legal that John read earlier.

So the current text says that – or the current proposed text says that invalid POC is restricted to payment and contact update functionality within ARIN Online. As a result, an organization without any valid POCs will be unable to access further functionalities within ARIN Online until at least one admin or tech POC validates their information as accurate or modifies a POC to contain accurate information.

So our questions to you now are: Are we satisfied with the current new language? And is there anything else?

Paul Andersen: Let’s get this party started and open the microphones. Come on. Some remote participants first. I think that’s a first. Somebody must have pre-typed that comment.

Joe Provo: From Jason Schiller, Google, ASO AC: Opposed as written. Support if implementation on reduced annual POC validation is delayed until one year after. All new POC creation requires an AC from the new POC. 2017-12 meets this requirement.

Paul Andersen: Okay. Thank you for that. Front microphone.

Owen DeLong: Owen DeLong, speaking for myself, ARIN AC. I’ll first support what Jason said, absolutely. Secondly, I think there’s still problems with the language regarding the consequences, because POCs don’t log in to ARIN Online. Organizations don’t log in to ARIN Online. Individuals log in to ARIN Online. And ARIN Online accounts are associated with one or more POCs and one or more Org IDs.

As I understand it, a POC is only associated with one ARIN Online account, not that there’s no many-to-many correlation there.

Paul Andersen: John, do you want to clarify that’s in fact the case?

John Curran: I know what you’re getting at. The point is that the functionality with respect to that organization would be as restricted in the policy. We can implement it as written. We don’t need policy that represents web user IDs.

Owen DeLong: Okay.

Paul Andersen: I know it’s in the staff assessment. I hear what you’re saying, that’s – it’s a different – don’t log in as –

Owen DeLong: I would prefer to have policy language that explicitly stated how it would be taking effect, because I understand staff knows how to interpret that and translate it into ARIN Online functionality.

I’m not sure when it gets into the NRPM that it necessarily sinks into everybody else’s brain such that the expectation set equals the action taken. And so I have concerns over that.

John Curran: If I could just respond. So the problem with going more so is that you end up with system implementation language in the NRPM, because right now we allow Web IDs and Web IDs of your login. And they’re not necessarily associated with an organization. Therefore, they’re not associated with any POCs.

If we actually try to specify that, then changes to our system could break policy language, which would be unfortunate.

Owen DeLong: Yes, I have a proposal that I think would resolve this.

Paul Andersen: What I was going to suggest is that it sounds like what you’re asking for is could the staff analysis just get a little more in deep on how they would deploy it.

Owen DeLong: No, I’m asking that the language of the policy be modified to be brought more in line with the actual consequences.

Paul Andersen: So, John’s concern would be his concern for sure on this.

Owen DeLong: John’s concern is valid if I wasn’t going to propose what I’m going to propose.

Paul Andersen: Do you wish to propose that right now?

Owen DeLong: Yes. What I was intending to propose is I think it would be more useful if the policy specified that an ARIN Online user associated with an invalid or unverified POC is unable to proceed until after they answer yes or no to whether that POC is valid when they log in.

Paul Andersen: John, I don’t think the remote participants can fully appreciate the shaking of your head. Did you want to respond to that? I’m just thinking about the remote participants.

John Curran: Crafting language here on the floor is an interesting exercise. I would say that what you propose has a lot of interesting implications.

I think it would probably require a discussion, but the short version is whether someone validates that a contact is valid or not doesn’t mean it’s actually valid if all the contact information still doesn’t work.

So we need to tease that out a bit. The desire is that the POC is actually a valid POC and has approachable contact information. You saying number, whatever, 555-1212, an example at domain.com, is valid doesn’t make it valid.

Paul Andersen: Before you respond, to kind of echo that, certainly as the chair I hear the change you’re proposing, while valid, isn’t a simple one that can be done from the floor. I think you’re talking about another cycle of texts if you want –

Owen DeLong: I am talking another cycle of texts, yes. And I’m perfectly fine with that. I’m not in a rush to implement this, as mentioned in the beginning.

What I am saying – and correct me if I’m wrong, John – is that if the ARIN Online user associated with the POC logs in to their ARIN Online account and clicks yes, this is valid, that is no more or less than you get by them clicking yes, this is valid in the email link you send out.

John Curran: The email actually got sent out and was received by someone.

Owen DeLong: If they’re logging into their ARIN Online account and you ask them to review this and say yes, it’s valid, or not, by the way, that email also shows up as a message in their ARIN Online account and they can click on that yes link from that, too.

So, again, I argue that it’s no more or less or effective than the current process.

Paul Andersen: I think the feedback is taken and that you would not be supportive of the policy as written.

We’ll go to our rear microphone. We have at least people at the microphone. That’s good. Sorry. Go ahead, sir.

Hervé Clément: Hervé Clément, Orange, a member of the NRO NC but speaking as the co-author of the RIPE policy proposal Regular abuse-c Validation, and I wanted just to add my support to this proposal as presented.

Paul Andersen: Thank you for that support. Front microphone.

Andrew Dul: Andrew Dul. Question around Jason’s comment. Do we believe that is an implementation item, or is that something that requires a text change?

John Curran: I would – could someone repeat the comment that Jason made?

Paul Andersen: Would you mind repeating the Jason comment, Joe?

Joe Provo: His comment was: Support if implementation on reduced annual POC validation is delayed until one year after all new POC creation requires an act from the new POC.

Andrew Dul: I think what he’s saying is don’t do the lockout until one year from the implementation date.

John Curran: That’s not what the policy text says.

Paul Andersen: So the answer would be, no, that’s an implementation.

Andrew Dul: So it is an implementation question or it’s a policy – we need to change the policy to make it fit Jason’s requirement or request.

Paul Andersen: Part of the policy proposal is the implementation date. So I think if there was a desire to change that implementation date, I don’t think staff – staff would not do that.

They might ask the Board if the policy was proposed, and the Board may delay it if the staff had concerns, but I don’t think staff could just inevitably delay it.

John Curran: We don’t have guidance to delay it. If the AC puts a comment in that says “Please implement this as of this date,” we’ll do that. But by default we implement the policies when they’re adopted.

John Curran: We’ve had implementation guidance from the AC. We follow it when we get it.

Andrew Dul: So the AC, in this case, could make an implementation note that would reflect the desire that Jason has eliminated.

Paul Andersen: And then staff would follow that –

Andrew Dul: And that’s not a textual change to the NRPM text?

John Curran: Right, you could make that change to the policy even after this meeting if you so noted.

Paul Andersen: Thank you to the patient microphone at the back.

Cathy Aronson: The back queue got passed up.

Paul Andersen: I distribute evenly. If there’s a line for a microphone, look for an empty one.

Cathy Aronson: I’m Cathy Aronson. My question for you is, this all originated from the part of our community we call law enforcement. I’m wondering are they still okay with the text? Have you been working with them?

Paul Andersen: There are members here. They may or may not wish to speak –

Cathy Aronson: Okay, maybe they could let us all know how they feel about this text, if they’re here. Okay. Awesome. Sorry.

Paul Andersen: Lovely question.

Alison Wood: Alison Wood, State of Oregon, ARIN AC. One thing I really like about this policy is it does default to the abuse contact, because sometimes the POC is not going to respond or the POC’s email address goes to a certain inbox or special mailbox in their inbox.

And with the abuse, it should be a monitored mailbox, and maybe that’s going to take care of a big part of this problem.

Paul Andersen: So are you in support or against?

Alison Wood: I’m in support of this policy, and I look forward to the abuse piece of it taking care of a big part of the problem of incorrect POC entries.

Joe Provo: Jason wished to clarify. We’ve already covered this, but he said: Response to Andrew, no. I’m thinking an implementation detail. Keep doing annual POC validations for all your POCs for one year until – one year after POC act is required. You can then do the lockout for POCs with direct immediately on passing.

Paul Andersen: Okay. Rear microphone while we process that.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written. I do definitely support the concept of slowly implementing this as part of staff guidance. Given a little extra time, this is a little more – has – a little more impactful, I guess you could say.

So that part of it is fine. The text itself is great. We’ve gone through two ARIN meetings. I think we’ve gone through a lot more ARIN meetings in terms of this general cleanup over the years. We need this policy done. Come up and fix it after the fact, but time’s run out, we need this policy.

My bigger concern is we just had a discussion on RIR features being directly implemented, probably through ARIN Online, and I don’t want invalid Orgs starting to put in validated RIR data.

Most companies, you don’t have valid information, you can pay your bill, you can clean up and – like what this policy says. And I don’t think that is an unreasonable step. So I support this policy as written.

Paul Andersen: Thank you. Just as a reminder, if you wish to speak, please approach a mic. Also, if you want to – you support the text but you have thoughts on the implementation date, I’m sure the AC would like to hear that for their deliberations, so there’s some discussion here at the meeting on that topic. Rear microphone.

Iranga Kahangama: Hi, my name is Iranga Kahangama. I’m with the Federal Bureau of Investigation of the United States. I’ve been involved with this policy for a while now. I support the text of the policy as it’s written.

And I think it would be great to have a quicker implementation time. I think we’ve been working on this for a while and that we realize, if you look at the original text, that we decided to break down some of the problems and take a piecemeal approach.

And I think this is a really good attempt at a good chunk of the problem. So I think it would really be helpful from a law enforcement perspective to do this.

Speaking in a personal and professional capacity, I guess, law enforcement’s kind of facing a lot of issues on the domain side of the Whois. And I know as these issues come up for our management and as they actually realize the differences between the domain and IP Whois, it would be good to have a lot of momentum in terms of working with you guys and improving the IP side of the house. Appreciate the work.

Paul Andersen: Thank you, and thank you for always coming to our meetings to give the feedback. It’s appreciated.

Any remote participant?

Joe Provo: It was requested to be held until after the queue was drained.

Paul Andersen: Okay. Please approach a microphone. I’ll be closing the microphones in about one minute if we start to run out of speakers.

Chris Tacit: Yes, thank you. Chris Tacit, Tacit Law, ARIN AC. I support the policy as written. I think we should implement it to try it out. And then if more tweaking is required, we can do it.

But I echo Kevin’s comments that this is a problem that needs to be resolved sooner rather than later. Thank you.

Paul Andersen: I’ll be closing the microphone after this speaker. So please – and we have the queue already from the remote – so please approach the microphone before this gentleman speaks.

Jason Plomp: Hi. Good afternoon. My name is Jason Plomp from the Royal Canadian Mounted Police. I support the policy. And not to just echo what Iranga said, but from a law enforcement perspective this is an important aspect of our work, and we’ve been involved with this for the last couple of years to try to get this through to certainly help us do our job. So, thank you.

Paul Andersen: Thank you very much for that feedback. The microphones are now closed. We’ll go to the rear microphone then take the speaker that wanted to be left last.

Alyssa Moore: Alyssa Moore with Cybera and one of the shepherds on the policy. I just had sort of a question or response, I guess, to Owen’s language recommendations.

It is my feeling that the language the way it is is preferable and that it go to a mailbox as preferable because part of the reason of having the Point of Contacts validate from the mailbox is because we need to have someone with a mailbox to reach in the event of abuse and someone needs to be contacted.

Paul Andersen: I think Owen’s concern was those messages appear online, so you might not need that mailbox to be broken and you’d still get the message, is what he was saying.

Alyssa Moore: But only if you log in to your ARIN Online account frequently.

Paul Andersen: I think the point was he says that doesn’t validate the email works.

Alyssa Moore: Right, but in the event of a request from law enforcement, for example, if someone isn’t logging in to their ARIN Online account at all times, you can still say, yes, this email address works if you’re logging in to your ARIN Online account and just checking yes.

But if some sort of request were to go to the email address associated with it for some other reason, then that’s still there.

Paul Andersen: Okay.

Alyssa Moore: We can talk about it tomorrow.

Paul Andersen: I think that will be a vibrant discussion at the AC meeting. I look forward to hearing it.

Let’s go to the remote participant. I’ve closed the microphone, so if it’s not in response to her point –

Joe Provo: First, Brian Jones: Support as written. It’s an individual comment.

And the previous comment from Jason Schiller, Google, ASO AC: In previous discussions, there was an idea that a POC could remain valid if there’s a known contact with ARIN; e.g., a user opens a ticket with ARIN, calls help desks, attends ARIN meetings, et cetera.

Paul Andersen: Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire. In response, an interesting services issue outside of the NRPM has really been brought up, which is that unique security-style information is being put into ARIN Online when the purpose of it is to be emailed.

Probably the suggestion is to remove out the unique URL in ARIN Online if the point of it is to validate the person’s email address. It’s a whole. It’s a circle.

John Curran: All right. You should follow up with me after here.

Paul Andersen: Yeah, I do think there’s a side thread to this, but it does sound like it might be potentially an implementation. Amy, any last words?

Amy Potter: No.

Paul Andersen: We thank Amy for her presentation and lively discussion. We’ll go to our poll. This is a Recommended Draft Policy. And I’ll just clarify because since we had a little more vibrant discussion than we had on the other one.

It’s that the question does relate to the text as it’s here, not necessarily some of the stuff that’s come up. That will have to be data the AC takes. So please take that into account when you decide which way you will poll.

We’ll now poll on Recommended Draft Policy 2017-3: Update to NRPM 3.6 Annual Whois POC Validation. Would all those in favor of the proposal as presented please raise your hand nice and high and keep it high. Second to last audience participation of the meeting.

Thank you, you may lower it. And those all opposed as written please raise your hand, obviously, and poll remotely now if you can. Please close off. Thank you. You can lower your hand.

Once again, while we wait for the numbers, if you have comments, suggestions, feedback, Amy Potter and Alyssa Moore are the shepherds for this. Find them at the break or after the meeting, or any local AC member.

Please feel free to have – give any feedback that you weren’t able to give at the microphone in person because it’s important, and they’ll be meeting tomorrow after the break of the Members Meeting to try and piece all that data together.

And here we go. On Recommended Draft Policy ARIN-2017-13: Update to NRPM 3.6, we had 93 in the room, 14 up. So that’s good, the sugar got people back in the room. 39 in favor, and two against. This will be provided to the AC. Thank you very much for your input.

Transfers Update

John Curran: Very good. Okay. We are going to move into our presentations for the afternoon. The first one up is an update on transfer activity, which Cathy Clements will give.

Cathy Clements: Hello, my name is Cathy Clements. I’m the ARIN Transfer Services Manager. And in this presentation I’m going to go through a couple transfer statistics and then some tips to help you prepare for transfers, and save some time for question and answers afterwards.

All right. So let’s begin. Here you can see the transfers completed per quarter from 2015 to 2018. You see there’s a bit of a steady increase. All three types of transfers are represented here, with most of the increase being in the specified recipient transfers, or sometimes referred to as market transfers.

And here we have a slide that represents the 2016 and 2017 completed transfers for the M&A transfers and the length of time that it has taken to complete them, the green being the 0 to 30 days.

And in 2017 you see that we have the – the percentage of completed transfers is greater in 2017, although there was more transfers. So that’s good news.

This is 2016 and 2017 for the specified recipient transfers and the time it took to complete those. And the timeframe has changed, 0 to 14 days, and that has increased as well.

And transfers that have taken over 29 days to complete has decreased in 2017.

These are the 2016-2017 inter-RIR transfer stats for the source transfers. That would be where the IP addresses are leaving the ARIN region and the recipient transfers where they’re coming into the ARIN region.

And until 2017, the number of transfers have increased. And on the other side here we have the number of IP addresses that have been transferred, and you’ll see that in 2017 the number of IP addresses has gone down by about 3 million.

Here we have the legacy versus the ARIN-issued, the total IPv4 networks, from last year at this time at ARIN 39 and until now. And the total IPv4 networks has gone down by 5,798, and it’s broken out into the legacy networks and then the ARIN-issued.

So where did these go? Over 2,977 of them have become ARIN-issued networks due to the specified recipient transfer policy. And 2,821 have gone to either APNIC or RIPE via inter-RIR transfer.

So that’s all the statistics. Now go into a few preparation tips you might want to consider when you’re submitting an M&A transfer.

Be ready to pay your transfer fee immediately. Registration services cannot begin the review of your transfer until that fee is paid. Identify all transactions that take us from the source organization to the recipient organization.

If there’s been multiple transactions, outline that for us, it’s very helpful. And your exact organization name is important. LLCs and Inc.s matter.

Gather all legal documentation for each corporate event. You can go to the SEC.gov for publicly traded companies. That is very helpful in finding that information. And some US Secretary of State sites have some of that information.

Review the ARIN RSA if you need to have that signed or the ARIN nondisclosure agreement prior to this because that could take time.

Press releases are not considered legal documentation. You’ll need to provide your legal documentation. And you can redact any financial or sensitive information that does not relate to the transfer of assets. ARIN is not concerned about that data.

Provide all schedules or attachments, included assets – excluded assets and other exclusion. And you’ll never, ever be asked to return addressing space. And Legacy RSA is an option for recipient organizations if the resources are not currently under a contract.

If you have any questions, call the help desk. We’re there to help you. And escalation is available but it could delay things.

Here’s some tips for the specified recipient transfer on the source side. Verify that the organization name in the database that represents the source is active and in good standing.

If there’s been merger and acquisition, you will need to go through an 8.2 transfer first to get it into the proper organization name.

You will be asked during this process to sign an officer acknowledgment releasing the resources. Make sure an officer signs that and that it’s notarized.

And for the recipient side of a specified recipient transfer, get preapproved for your 24-month need, your full 24-month need. Even if you’re going to transfer only a portion of that, get preapproved for your 24-month need. It’s free. It will stay there for 24 months, so you might as well go ahead, ahead of time, and get it done.

There’s no justification for an initial /24. So if you don’t have addressing space from ARIN, there’s no justification if you’re transferring a 24.

For additional blocks or blocks larger than a 24, you’ll need to provide details about the use of 50 percent of the requested space within 24 months. And if you already have addressing space from ARIN, you’ll have to provide the utilization percentage for the previous IPv4 blocks.

And if you do get preapproved and you’re doing the recipient organization for a specified recipient transfer, you still need to submit the 8.3 recipient request form even if you’re preapproved.

Again, you can always call the help desk. There’s the phone number. We’re staffed from 7:00 AM to 7:00 PM. We’re there to help you. Or you can send an Ask ARIN question via ARIN Online.

That’s all I have for you, and if you have any questions.

John Curran: Microphones are open. Any questions for Cathy?

Okay, thank you, Cathy.

(Applause.)

John Curran: I’m reminded to tell you that you can call the number, but you also, if you happen to be here, can go right outside. There’s a help desk. We have ARIN help desk at our meeting, and sometimes it’s easier if you happen to be here to have an opportunity. That will be open tomorrow as well.

And during the meeting or at a break, feel free to go down if you have problems that you’re working on in resource registration.

Software Development Update

John Curran: I want to continue the presentations for the afternoon. Next up is our Chief Operating Officer, Nate Davis. He’ll give the Software Development Update.

Nate Davis: Thank you, John. Good afternoon, everybody. I’m going to be giving the Software Development Update, as I’ve done usually at every ARIN meeting, just to keep community apprised on our efforts regarding our software and engineering developments.

That was successful. There we go. So things I’m going to cover is I’m going to go over strategic guidance that we received regarding what we should be working on with regard to engineering software projects. Talk a little bit about how work is prioritized within the organization. Talk as well about projects that we’ve completed since the last ARIN meeting, ARIN 40, in San Jose. And then also chat a little bit about upcoming and ongoing initiatives within the software development realm.

So starting first. So every August the Board of Trustees meets, and they review the strategic plan. And in doing that, they review each of the strategic points for the strat plan and revise those according to what they see as far as setting the direction for the organization for the next two years.

Out of that, and this is available online on ARIN’s website, under About Us > Corporate Documents is ARIN’s strategic plan, with the highlights that pertain specifically to ARIN’s engineering function, is, one, overall is to maintain, develop and enhance the functionality of ARIN’s services as sought by the users and supported by the membership.

So clearly the Board has said to the staff, the Engineering staff specifically, work on those things that are important to the communities and the members.

We then further – they then further break down the strat plan into organizational objectives, and that provides a little bit more fine tuning on what some of those items are.

And those are the three that you see here – support community discussions on ARIN’s routing registry role and the global routing table management to finalize specifications for ARIN routing registry enhancements.

So, if you’re not aware right now, we have an open consultation on the IRR through April 25th. We encourage you, if you have an opinion on the routing registry, please chime in.

Next is the support community discussions on Whois evolution, and registration data access protocol, RDAP support. Andy Newton earlier today gave a great presentation on RDAP, and as you can see we’re continuing to evolve that product.

And, lastly, continue to review and enhance online services, including making user interface improvements per feedback and customer survey. So a lot of the work that we do is actually, again, driven by the community, not only through Board guidance, but we get through our communications channels.

There’s a number of things that influence our work. This is a list here. I’m not going to go through each one. But as you can see, like any organization, we can have a number of activities that influence exactly what the Engineering software team does.

We use an Agile process to try to be nimble to actually respond and act quickly on those changes because they’re often dynamic. It could be a policy that’s passed. It could be a request from a user that makes perfect sense. It could be Mailing List ad hoc that comes in from an AC user – or an AC participant – excuse me, an AC council member who is asking for statistics in response to considerations of a policy.

So any number of things that we could actually have input into our engineering process, and these are some of them.

What have we completed since the last ARIN meeting, ARIN 40 in San Jose? We’ve completed a couple of ACSPs, 2017-5, which is to add detail to the invoices. There was a request for us to add additional details to supplement the information we already had there that would provide more detail as far as what is exactly being billed for.

The second one, 2017.18, is an enhancement of the daily ASN delegation file. In that file, if you’ve seen it, we actually would provide a range of AS numbers where appropriate in some instances. The community, somebody in the community suggested that we actually break that out and itemize those AS numbers, which we’ve done.

Both of these, the work has been completed, but it has not been deployed yet. It is awaiting deployment on May 12th where we will have a software deployment on that particular day.

Improvements to transfer performance. It turns out we’ve had a couple of very large transfers hit ARIN recently.

And you may not know, but it’s sometimes not just necessarily moving the registration rights to another organization in the transfer process that Cathy just described.

Sometimes we have to actually break networks and do reparenting. And what we found is in some of the large transfers that we were processing, it took an inordinate amount of time to do that reparenting and that processing work. It was something that our systems were not geared towards initially.

Engineering stepped in and made improvements right away that we needed done. And so therefore, looking forward, we have the systems in place that can support large transfers.

We had redesign of tickets, the ticket section in ARIN Online, specifically listing search and view. And we’ve also improved delete network and delete reassignment capabilities within ARIN Online.

Continuing on, we’ve added some additional security, particularly as it relates to changing security-related items within ARIN Online. We’ve had some improvements to Whois. And we have a framework for a new website which I think Richard’s about to talk about. So I’m not going to steal his thunder.

And also if you haven’t had a chance of seeing Jan and Jesse outside, please do so, because they can give you a preview of the website that we will be launching at some point in the future.

And lots of UI work that’s going on. We’ve had a number of community suggestions over the years for us to take a look at our user experience within ARIN Online and make improvements accordingly. So we’re doing that, and that does take a considerable amount of time because each page has to be looked at, not only from a usability standpoint, but we’re also taking the opportunity to make accessibility improvements as well.

So in doing that, each page has to be visited and analyzed to figure out how to improve it accordingly and then those changes implemented.

So let’s take a look. So here’s an example. At the top – I hope you all can see that. At the top we have an old attachments screen. This is within ARIN Online. If you were submitting a request and you needed to provide additional documentation, this was the feature that you would use to actually do that.

And it looks straightforward, but it actually created problems for some of our users in that it wasn’t very clear, once they had attached the files, that they had actually done that.

So it ended up with a few requests actually sitting, waiting for the customer response because the customer had actually attached the files, or so they thought, but they really were not attached.

So it created some additional time in processing a few requests. So alternatively what the team came up with was a much cleaner interface for the ability to attach files.

We also have a counter that keeps track of the amount of files that you can load, and it’s a much easier process than simply selecting or grabbing and dropping the files that you want to add into ARIN Online for your request to actually submit those. It’s a much cleaner interface.

Similarly, the mergers and acquisitions transfers to which Cathy referred to earlier, you can see on the left you have a screen there where you can select the currently selected IP addresses or those that the user has selected.

But if you look at the improvement on the right, not only does it allow those IP addresses to be selected, it also provides you at the top a little bit clearer navigation as far as organization networks and ASN documentations and review. But at the bottom you can jump specifically to pages of resources as opposed to having to scroll through all of them, which you had to do in the old interface.

So those are sort of an outline or an example of some of the improvements we’ve made. And we’re literally going through hundreds of screens to make those changes.

Going forward, we’ll continue on the user experience work and improve our usability and accessibility throughout the ARIN Online website.

We’re offering test drives, and, again, Jan and Jesse are out in the hallway if you would like to participate in taking a look at our new initiatives regarding ARIN’s website.

We’ll continue work on the Internet Routing Registry as well as RDAP and continue efforts on technical depth such as our – providing upgrades to our development environments internally, and of course that takes some effort as well.

That concludes my report. I’ll take any questions. Center front mic, Owen DeLong.

Owen DeLong: Owen DeLong. If we could go back to Slide 7, that’s not an improvement from my perspective.

Nate Davis: Okay.

Owen DeLong: I would much prefer to have a long list than many pages to jump through to find the thing I’m looking for.

With a long list I can hit command F, type in the one I want, and it scrolls there for me. I don’t have to fight with the browser to figure out which page it’s on.

Additionally, having the rows denser versus sparser is useful, in my opinion. Having even smaller numbers of rows per page because you’ve got a big, wide button on the right side is a step away from goodness, not towards it. Thank you.

Nate Davis: All right. Thanks for the input. Any other questions?

Joe Provo: Anthony Delacruz: I’m, it seems to be, a daily user of ARIN Online, and it’s so much better. Many thanks to staff for the improvements.

Nate Davis: Thanks for the comments. We appreciate that. Any other questions?

Thank you very much.

(Applause.)

Website Redesign Update

John Curran: We’ll continue our presentations for the afternoon. I’ll have Richard Jimmerson talk about our website update.

Richard Jimmerson: Thank you, John. How many people here in the room have gone to preview.arin.net yet? Please raise your hand. Outstanding. Thank you very much.

So, want to talk to you a little bit about the schedule. The staff inside the ARIN organization, together with all of you who have been providing feedback this entire time, have been working on a new website over the last six months.

Back in October, we announced this redesign project that we were going to go through. There were a lot of requirements that we were receiving from the community about what they would like to see with the new website. And the current website just wasn’t working for them.

One of the number one things was responsiveness for mobile devices, and there were a lot of different things. Some people thought that the existing site might be a bit cluttered, and they wanted it to be a little bit cleaner looking with less clutter and more open spaces. There was quite a bit of comments going on.

So the Board of Trustees said you guys should start go ahead and start working on this project. And we did that for you, starting in October of last year.

Now, where we are right now, in April of 2018, is we’re on our first site preview launch. Now, we have three site previews that we’re going to be doing this year. This is the first one that’s currently open today.

It will be open through the first part of next month. And what we’re going to be doing is collecting additional feedback from the community during this site preview so that we can continue to make tweaks. And then we’re going to do a second launch.

In our second launch you’ll see that we’ve made some updates to the site based on the additional feedback that we received. But also in the second preview we’re going to be focusing on what account management looks like on the new ARIN website.

Right now you can’t see account management on this first preview. On the second preview we are going to show you options of what that might look like. And we know that’s very important to all of you because you log in to manage your resources through ARIN Online today, and you’ll continue to do that in the future.

Now, based on that feedback, we will choose a path and we’ll move down that and we will integrate account management into the new ARIN website. And we will work towards our third site preview.

Our third site preview we’ll have a good amount of the content actually copied over from the existing website to the new website. We’ll be going through this migration project through the course of this year. And we’ll have made all of the updates based on the previous previews we’ve done. And it will be like a last preview to the community.

Here it is. Based on all the feedback that we’ve received from the community, based on all the work that we’ve done working together with you, this is what we’re ready to launch imminently.

And it’s just like a last check-in to make sure that we’ve got it right. There’s nothing major wrong with this before we go live. And that’s for all elements of this site – the look, the feel, the usability, how responsive it is, how your ARIN account works with the site, all of those different types of things, the navigation – to make sure that we have it right before we release.

And that last preview will happen in October of this year.

Now, the feedback that’s driving the redesign, we’ve gotten it from all over the place, but we have online card sorting that we’ve done with the community so you can tell us what navigation should look like on the ARIN website.

And a lot of you have participated in that project. We also had the ARIN staff participate in that process, too. Particularly the customer-facing staff inside the organization that spends time every day on the telephone with customers helping them navigate through the site to find the resources they need to request address space or make an update to their records or put in a suggestion or make a policy proposal.

We’ve also done tree testing. Once we’ve got that first set, that navigation set, we ask you to go start using it in tree testing. What does that look like? Are you finding things you would expect to or not? And that tree testing is helping inform additional changes.

We also did some paper prototyping at ARIN 40. We had these little pieces of paper with different elements of the website and you kind of pushed them around and we recorded that – only your fingers, moving the things around to see where things went and where you expected things to be, and that’s where we landed with today’s first preview.

Also we’re doing continuous user testing whenever we do have an opportunity to do that including today in the back of the room. In the hallway back there, we’ve got Jan and Jesse, who can work with you to go through the preview and answer some questions for you and get some additional feedback. And they’ll be here after the meeting closes today for as long as you need them, and back at 8:30 tomorrow morning to continue to get your feedback.

And also we always get customer feedback in surveys, help desk calls, support tickets, the feedback button about elements on the website. And of course we’re very interested in what we hear from you in this preview.

Now, if you haven’t been there yet, if you go to preview.arin.net on any device, in the web, on your PC or your Mac, or if you want to go on a mobile device, you can do that. You can check it out and you can hit this feedback button that’s in the middle of the page here.

But you can hit that feedback button and take a short survey to tell us what you think. And you can take that survey multiple times if you’d like as you go through the site.

This is a side-by-side, but it’s one continuous scroll down the page if I was in a web browser.

Again, we have emphasis on mobile support all the way throughout this project. We often take through this process elements that we want to add to the website, and we make sure that they work first on mobile before we actually put them into the design. And we’ll continue to operate that way through the rest of this year.

Again, as I’m wrapping up here, we’re right in the middle of this process during our first preview. Sometime this summer you’ll see the second site preview with some changes and your ARIN Online integration. And then you’ll see the final preview in 2018 as we prepare for the live launch of the new ARIN website.

So with that, I just want to say that the ARIN staff inside the organization, they’ve been working on this, have really enjoyed this project, being able to do this on your behalf. And we’ve really enjoyed all of the great work and feedback that you’re actually providing to the organizational staff to get this work done.

And together I think we’re going to produce a great website at the end of this year. So, thank you very much.

(Applause.)

John Curran: Any questions regarding the website redesign project?

Kevin Blumberg: Kevin Blumberg, The Wire. Just thank, thank you, thank you. One quick thing. For October, which happens to fall right in the next ARIN meeting, you have the final site preview.

My only ask is that it be functionally equivalent from an NRPM and meeting point of view so that we can actually really have, try, going “here’s all the policies,” they’re in preview.arin for the meeting, including links on pages if you can. Do the duplicates so that I can click on the preview.

You’re going to get the most use, in-person live, if that preview has the live content for what that meeting would be, if you’re populating just a suggestion.

Richard Jimmerson: Thank you, Kevin, that’s great input. We can look to make the new website meeting support functional for that last preview so that you guys can use it that way.

Thank you very much for your time, guys.

John Curran: Thank you, Richard.

(Applause.)

John Curran: Okay. We’re just a touch early for the refreshment break, but I’m going to let you go because we do have more content afterwards. And so break is outside.

It’s slightly longer than usual. Be back here in at 3:30 for our Recommended Draft Policy 2017-12. And then we have one more presentation, and then Open Mic. I’ll see everyone back here at 3:30.

(Break from 2:39 PM to 3:31 PM.)

Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

John Curran: Okay, we’re going to resume our afternoon session, and we’re resuming with the policy development block. This is Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment. It’s a recommended policy. I’ll do a staff introduction to it.

This policy is here in recommended state, which means it could be recommended to last call and sent to the Board of Trustees for ratification. So this might be the last time you see this policy.

History. It started as ARIN Policy Proposal 247 in October 2017. It advanced to Draft Policy in November. Advanced to Recommended Draft Policy in March 2018.

So, the proposal is clear. It solves a well-known problem. It’s technically sound and enables fair and impartial administration of Number Resources.

It has not yet been presented at an ARIN meeting. Policies must be presented in order to go from recommended to last call. But once they do, are presented, they’re gone, potentially, unless there’s revisions that would send it back here.

The AC shepherds are Chris Tacit and Leif Sawyer.

And the staff understanding. The Draft Policy requires that all requests for reallocation or detailed reassignment that will result in the creation of a new POC object be validated by ARIN prior to approving the request.

Validation will be accomplished by contacting the new owner by email. If the POC – contacted POC fails to validate, we will reject the request.

This is a very big change to the current business practices.

In addition, Section 3.8 in the Draft Policy requires staff to formally notify an organization in a simple reassignment either the organization or address is identical to an existing one for the purpose of obtaining guidance as to how whether to approve it or redirect it to an existing Org ID.

Staff comments. One of ten: The problem statement is vague as to actual reassignment process which creates the problem.

Recommend additional wording that more accurately describes how a POC is created during reassignment. For example, the language could be: During reassignment/reallocation some large ISPs create POCs from their customer order form.

This process is automated for many ISPs and therefore the resulting POCs are not validated prior to being created. This unknowingly creates POCs that have no idea what Whois or even who ARIN is at the time of the creation.

It can also create multiple POCs per email address causing the same person to receive multiple POC validation emails each year.

The proposed change represents a very significant change to current operations. The largest impact would be on ARIN Engineering.

It is a major engineering effort, will involve significant testing. The work has been estimated to take at least six months for the planning and development work, which does not include testing and interaction with the community.

When the work is completed, there will be a period of time when ISPs will have to retool their applications that interface with ARIN before system can be placed in production. At the point when it’s placed in production, all current systems developed by ARIN customers will have to be updated in order to continue working with the new states introduced by this policy.

The Draft Policy would not have a direct effect on RSD operations for the processing the requests for reallocations and reassignments due to the fact that they are automated; however, there would be a significant increase in customer calls and tickets.

A conservative estimate would suggest that at least 50 percent of the requests would require some type of manual follow-up from within the person receiving the validation email.

Increase in interaction with organizations that don’t have direct relations, result in the need of additional staffing within the registrations services team.

One possible improvement in business processes would be if the policy text specifies that the Org’s abuse contact would be put into the reallocation or reassignment record and then the request approved.

ARIN would then issue a notification of the proposed new contact, and if the new contact is validated, the new validated contact record would replace the abuse contact on reallocation or reassignment.

This change would result in reducing the number of POCs associated with a single email which would reduce the number of POC validation emails received annually.

Today there are several emails that have multiple POCs associated with it. Here’s the numbers. Email addresses. We have 465,000 email addresses in our database. 15,000 of them are associated with 5-9 POCs. We have 4,000 associated with 10-24 Points of Contact.

We have over a 1,261 POCs that have greater than – sorry, over a 1,261 POCs that have greater than – I did it again. There are 1,261 emails that are associated with more than 25 Points of Contact.

If this policy is adopted, eliminates requirement for annual POC validation for detailed reassignments, that approximately 77 percent of the existing POC validation will be eliminated.

Networks in Whois requiring POC validation. You can see about 4 percent direct allocation, 5 percent direct assignment, 14 percent reallocation, and detailed reassignments are 77 percent of the networks in Whois requiring POC validation.

The wording is misleading. The wording in the Draft Policy Section 3.8 is misleading because a simple reassignment results in a customer identifier versus an Org ID. It’s not a full Org ID.

There’s no contact information associated with existing reassignment other than street address that could be used for notification, thus it does not appear the proposed text was directly implementable.

Also note if notification were possible, the “OR postal address” may cause significant problems since this causes us to match postal addresses, and if companies have the same name with multiple locations, this would require manual intervention.

Cannot be implemented as written, but could be implemented with significant effort if the proposed Section 3.8 was removed.

No material legal risk in this policy.

Resource impact. Major. At least six months and extensive testing with the community as well.

Okay. AC presentation, and I’ll ask Chris Tacit to come up and give it.

Chris Tacit: Thank you, sir, very much. I always get the easy ones. Whoops. What happened there?

The problem statement. Okay. So the nexus for this proposal is that a lot of these POC records are actually created in an automated fashion that doesn’t really allow prevalidation before their creation, and that the people associated with the POCs may have no idea even what ARIN is.

So as a result, the policy proposal seeks to improve the situation for those who are unwittingly or unintentionally inserted into Whois.

Another reason for this is to reduce the amount of time and effort that ARIN staff have to spend and also hope that the overall validation situation will ensure greater cooperation and greater accuracy going forward.

So this is the text of the new proposed Section 3.7. I will give you a moment to read it. I’m not going to read it out loud.

And this is the information that would be sent to the person with the validation request. And the important part to note here is that if the validation is not confirmed within ten days, then ARIN has to reject the request.

John talked about the proposed Section 3.8. We actually revised the proposal to drop that. So that’s no longer part of the current proposal. Right now we’re just trying to keep it simple to the new 3.7 section that you just saw. And rather than repeating the reasons that we didn’t do that, you already heard them from John in his presentation.

But one of the important points to note, though, that part of the challenge with doing something like 3.8 sought to do is that it sort of interposes ARIN down a level in between its customer and its customers’ customers, and that’s not a place where ARIN believes or, frankly, I as shepherd think they should be.

So as a result of that, as I said, the Section 3.8 that was originally proposed was dropped. We did consider this alternate proposal to try and reduce the number of email addresses and so on.

But I think the reality is that if – once this process starts working and people become more careful going forward, that that’s going to have a big prophylactic effect going forward in any case.

And in terms of history that you saw up there, this really isn’t going to fix that because this is – we’re talking about the first-time creation of POC records anyway.

We didn’t want to complicate the proposal by adding this piece to it right now. So just as 2017-3 was sort of neat, clean, one piece, we were trying, as shepherds, to take the same approach here.

There’s enough work to do on the engineering side that we thought that it would be simpler to just keep this streamlined and simple and digestible.

When this was put forward on PPML, there was quite strong support both in principle and with it as redrafted. In other words, the redrafting we did as shepherds was twofold: Was to expand the problem statement to what you saw and to drop that proposed Section 3.8.

You heard about the implementation issues. I thought it was important so I put a slide in, but I’m not going to dwell on it. Again, since John took care of that.

So two questions that I thought of. Do we continue to have strong policy support for the policy as written in light of the PPML support shown, and would there be any reason that if, for example, 2017-3 was passed, would this be viewed as complementary or mutually exclusive to it and so on? Because that may determine how we assess the policy.

So thank you.

Paul Andersen: Thank you. The microphones are now open for this last Recommended Draft Policy of this meeting. So we need the input on this. This may be the last time you see this proposal.

Once again, storming to the mics in person, but the remote is off to the races.

Joe Provo: Jason Schiller, Google, ASO AC: Support, but with great disappointment. We need this policy to ensure new POCs don’t get created without the victim’s knowledge. Today we only find out about these during annual review of all POCs which we might not in the future.

However, it does not, quote, improve the situation where a POC is unwittingly and unintentionally inserted into Whois, unquote, when the chosen victim is a pre-existing POC or pre-existing Org or a customer identifier is created from a reassigned simple.

When the victim is a pre-existing POC or Org ID, then they are only discovered by poking at Whois or ARIN Online. When the victim is a customer identifier, then it is nearly impossible to discover.

I personally have been contacted by others in my Org asking why ARIN thinks they are a POC, and I personally have dug through all the resources of one of my Orgs only to find there are resources that should belong to a different one of my Orgs, and in some cases have been unable to get the assigning Org to fix.

Paul Andersen: Thank you, Jason, for the feedback on that.

Rear microphone to start us off.

Iranga Kahangama: Hi. This is Iranga Kahangama with the FBI. The downstream issue I guess was something that law enforcement had brought to the community as well in the past. So I do appreciate that some of it is being addressed.

So I do support the policy in that I think it’s a good step going forward.

To some of the comments that were made earlier about the downstream issue, I would also support – I’m not 100 percent sure how this would be implemented, but some sort of metrics around today versus a year from now versus further out to see what percentage of the problem is being solved and if and how other downstream issues need to be addressed.

But I do think it’s smart in that if it’s a burden for ARIN to contact these people who are unwittingly put into the database, then chances are that there’s a chance that they’ll also be unwittingly contacted by law enforcement and create similar issues.

So it’s something that we would support in trying to mitigate a problem that we both likely have.

Paul Andersen: Certainly we could flag that for future policy experience reports, if necessary. If adopted.

Front microphone.

Owen DeLong: Owen DeLong, ARIN AC, speaking only for myself at this point. This was an attempt to resolve – or is an attempt to resolve a problem that I’ve observed in a number of organizations, including my most recent former employer, in spades.

Support the policy as written. My biggest concern with the implementation of the previous policy is the fact that this one doesn’t go far enough and that one removes the safety valve that we have on these resource records pretty much completely without having an alternative in place.

Paul Andersen: Thank you. Going to the rear microphone.

Chris Woodfield: Chris Woodfield, Salesforce and ARIN AC. I definitely support the policy in principle. I believe I have some concerns around it as written.

One of those is similar to the fact that the staff and legal have obviously raised some issues that would have to be resolved. I’ll also echo Owen’s comment that I believe that this should be complementary to an annual validation, because POCs do get stale with fairly kind of regularity.

I also want to bring up the potential chicken and egg problem this may create for ISPs where an assigner is in a practice of allocating a sub-assignment at, say, network turn-up time or link turn-up time.

If this proposal is in place, there needs to be a period where the block is allocated, the SWIP attempt is made, but that block cannot be routed or should not be routed by the ISP until that POC is validated.

So that can create some interesting – that can – requiring many ISPs to implement process changes. So to avoid that chicken/egg issue.

Paul Andersen: Thank you for that feedback.

Again, this is potentially the last opportunity to discuss this policy. So please approach a microphone. I am rapidly running out of speakers. So we will be closing the microphones if there is a lack of feedback.

Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the proposal as a baby step. And I think the most important part is the understanding from the community, I think that’s important that many of the people at the mic have said this is a baby step, we want it.

And I don’t want when another proposal comes in to try to deal with this that they go: But you got what you wanted in the first place; why are you asking for more now?

So on the record, this is a baby step, and it should definitely move forward.

The one key issue that I have is I just removed – I had removed 23 reassignments that we had no idea were part of our thing. We finally found it. They got imported into our ARIN Online.

And we couldn’t flag them to ARIN that we don’t believe that these should be with us. We couldn’t delete them ourselves. We had to contact the Org in the first place. And we had a good relationship with this Org. We knew who they were; we just didn’t know they had done this.

We didn’t want to get them in trouble. So we didn’t want to go through the “send it to ARIN and have ARIN deal with it” scenario. We just wanted them to get rid of it and not have added it in the first place.

I think at a minimum, and it’s more operational than policy, I think at a minimum if a POC gets added to something, that POC should get notified so at least they’re aware of it.

This just adding stuff without people knowing about it is just unfair. And I don’t know a better word for it. Thank you.

Paul Andersen: Thank you. I will take a comment from Chris Tacit, if you would like to get in queue, but I would urge, either remote or in person, if you would like to comment on this proposal, please approach now because I will close the mics at the end of Chris Tacit.

Chris Tacit: So I just want to reassure those who are of the view that this isn’t a comprehensive solution that I also agree with that, and I never saw it as an end-to-end solution.

But I guess in my judgment, the way to tackle this without having to go through two or three years of consultation was at least to get something that was small and digestible and was a clear first step that, other than having implementation problems, could at least be put into place, except for the implementation challenges that need to be overcome.

Which can be overcome. We’re not told it’s impossible to do this. And then we can move on to other enhancements and deal with other parts of the problem.

My fear was that if we tried to tackle too much and if we didn’t get it quite right, we’d be doing this for a very long time.

Paul Andersen: Thank you, Chris. We have one remote and one in person, and then the microphones are closed.

Joe Provo: Jason Schiller, Google, ASO AC: Follow on to Kevin. Notify the POCs in linked web addresses, please.

Owen DeLong: Owen DeLong, ARIN AC. I agree the fact that this is not a complete solution is not necessarily a bad thing and this is a definite good step forward. Fully support this policy.

My concern is implementing the previous policy until we have a complete solution to this problem is a step away from goodness.

Paul Andersen: Okay. All right. With the microphones now being closed, thanks, Chris Tacit, for that excellent final policy presentation.

Joe Provo: There’s one last online. Brian Jones: Agree with the others that any POC getting added should be notified. Otherwise, support the policy as a beginning step.

Paul Andersen: Any other remote participants?

Joe Provo: Slack claimed somebody was typing, but then they stopped. So no.

Paul Andersen: Okay. Thank you, Chris, again, for the presentation. And that actually ends our policy presentations after this last vote.

So we will now take a poll on this Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment. I would ask all those in favor of the policy proposal as presented to please raise your hand nice and high. It’s your last audience participation time of ARIN 41. Keep it up a little bit just in case.

Thank you. It’s a very complex process on this counting. And all those opposed to ARIN-2017-12, please raise your hand nice and high for just a moment.

Thank you. We will just await the results. That concludes our policy discussions. I think we just have one more update presentation and then Open Microphone. Stump the CEO.

No more policy until ARIN 42 in lovely Vancouver.

On the item of 2017-12: Require New POC Validation Upon Reassignments, 77 in the room, 14 remote; 30 in favor, one against. This will be provided to the AC, and this concludes our policy for this meeting.

John.

Caribbean Outreach Update

John Curran: Okay. Our final update for the day will be Bevil Wooding – come on up, Bevil – who is going to give our Caribbean update.

As some of you may know, we got ahold of Bevil. He’s now part of the ARIN staff, and he’s doing all of our Caribbean coordination and has been a great addition.

Bevil, take it away.

Bevil Wooding: Thanks, John, and good afternoon, everyone. I’ll give you a sense of what’s been happening in the Caribbean. This is the – we’re now into month four, I think it is, of the start of the ARIN in the Caribbean events, which kicked off in February.

So far we’ve visited four countries, and I’ve been fortunate enough to have over 200 participants attend these events. The graph shows you the attendance has ranged between 45 persons in the first meeting to 75 persons in the last meeting we held in St. Kitts and Nevis.

And one thing that’s been very consistent with the activities is that the talking points have centered around the issue of network resilience, which, as you know, coming out of last year’s hurricane season, has been a big deal for work in the Caribbean.

And we’re using that emphasis on network resilience to highlight the importance of network autonomy and the importance of getting your number resources and building your networks in particular ways.

So each of the events have centered around what is network resilience and why it matters, how ARIN can help, what are the specific ARIN services that can be taken advantage of, and what practical steps can be used to get more autonomous networks in the Caribbean region.

These are some photographs from the last four events that have taken place. And you can see the consistent community feedback that we’ve been receiving. We’ve been serving at the end of every meeting to try and gauge in a very clear way what the priorities are for the region.

And we’re using these survey results to tailor the future events that we’ll be having at both the national and regional level.

You see the top priorities here in this list – network resilience, network autonomy. Big interest in IPv6 adoption. Network security is that constant. Request for persons building out networks. And of course we recognize, and now have confirmed through the surveys, that there’s also a great interest in technical capacity building.

So as the events have progressed, we have been working with CaribNOG and the Caribbean Telecommunications Union and the Organization of Eastern Caribbean States to help ensure that after we do these touch-point events that there is some follow-on activity that takes place in country.

So this has been the development around the ARIN in the Caribbean events. We have had an agreement with the Organization of Eastern Caribbean States to support their efforts in network resilience.

And you may know that the Organization of Eastern Caribbean States covers the territories that were most significantly battered by the hurricanes and the territories that are in line to be impacted in future seasons, because they represent essentially that center point of the Caribbean Archipelago, from Grenada in the south to – I think it’s Antigua and Barbuda and Anguilla in the north.

APEX, a Caribbean agency that was recently formed dealing with judicial, legal and law enforcement technology issues, has also come on board to stand with ARIN and to have ARIN support it in educating judicial officers, lawyers in the areas centering around cybersecurity, cases that impact the Internet, and the types of matters that they’re dealing with that have been, for some of them, challenging where we feel that ARIN support will be also useful in meeting that particular target audience’s needs.

One interesting development as a result of our outreach in the region has been the type of coverage that we have been gathering. And I think it really reflects the interest not just in ARIN but what ARIN is attempting to do in terms of supporting Internet development in the Caribbean.

So this is just a snapshot of some of the headlines, both online and in the print press, that we have had coming out of our activities.

And then supporting partners. We have been making great effort and I would say great advances, as well, in terms of deepening and strengthening our relationships with the organizations that we have been doing work with in the region for the past many years as the CTU, Caribbean Telecommunications Union, and CaribNOG.

And coming out of these partnerships, we actually will be this week officially launching the ARIN Caribbean Forum. And that will continue to strengthen those partnerships and our work with other organizations in the region, Internet Society, ICANN, and LACNIC.

One of the defining characteristics of the meetings we’ve had so far is all of these players, if you will, have been supportive in participating in the events. And it really helps when we focus on the ARIN mission and message that there is these other voices that support the wider issues of Internet development in the region.

This is the ongoing focus, increasing the Caribbean contribution in ARIN policy development. And you would have noticed the incremental but important increase in Caribbean participation at this ARIN 41 meeting.

Would the Caribbean delegates indicate by raising your hands your presence in the room. We have a number who are fellows and we have a number who are returning because they like ARIN and they’re interested in policy development. So that’s the Caribbean posse.

And what we’re also doing and crafting new activities for is for increasing Caribbean participation in the ARIN community, getting persons to participate on the Mailing List to consider the types of qualities that might be relevant to networks and number resources in the Caribbean region and so on.

So participating in policy development, participating in the growing ARIN community. Those are two of the very, very important things that we have.

So this week, on Thursday, the 19th of April 2018, we’ll be launching ARIN Caribbean Forum. And the forum will focus on three areas closely – the technical community group, which will continue activities with CaribNOG at CaribNOG 15, which begins tomorrow afternoon; the Public Policy Workshop, which we are going to be co-staging with the Caribbean Telecommunications Union, and that will be looking at the Internet policy development trends and priorities for the Caribbean; and there’s a new justice sector group, which will be having its first workshop, the Cyber Collaboration Workshop, between North America and Caribbean law enforcement officers and agencies.

So that’s all happening this week. Major step forward and major new vehicle for our engagement to the Caribbean region.

Other events in the coming months. Another ARIN Caribbean event scheduled for Dominica and Antigua and Barbuda the first week in May. Then we have member outreach to the BVI and USVI in June, followed by the Caribbean Peering Forum in Belize, also the second week in June. And then we continue on in July with a justice awareness – justice stakeholder awareness session.

That’s it for the Caribbean.

(Applause.)

John Curran: Microphones are open for any questions on the Caribbean update.

Jose de la Cruz: Jose de la Cruz, Internet Society, Puerto Rico. Is this Caribbean region strictly geographical, or was it made up by some other method? Because I notice you include USVI, but we in Puerto Rico were not aware of this event.

Bevil Wooding: The event in USVI was just announced to everyone for the first time in this presentation. So it will be posted on the ARIN website shortly. And I hope that we’ll be able to come to Puerto Rico in the not too distant future. We actually want to do that.

Aaron Hughes: Aaron Hughes, Trustee, ARIN Board. In that same vein, I actually didn’t realize there was a CaribNOG that was going to be part of this same week here in this same facility, and it would be nice in the future, if we have meetings that we’re aware of in the same destination, to be made aware of them when ARIN is announced.

John Curran: There was some chaos surrounding that, and we’ll do a better job on the next one.

Anything else regarding the Caribbean update or Bevil?

Thank you, Bevil.

Okay. I would say we would now go through the Internet Routing Registry consultation, but we did that, and I would say we’d do the Customer Satisfaction Survey results, but we did that.

So we’re actually ahead of schedule. That’s good. We’ll go to Open Microphone.

Open Microphone

John Curran: And the Open Mic is an opportunity for you to come up and express views on any issues that we’ve talked about – policy matters, how ARIN operates, similar.

So the Open Microphone is open now. You can – ARIN’s operations, open consultation matters – feel free to approach the microphone. This is your chance to have an open floor to discuss issues that you want to raise with ARIN.

We’re an hour early, so we’ve got a lot of time.

It’s amazing how many people want to speak and then suddenly go silent.

So we actually have a number of consultations open. As people might be aware, when we’re going to make a significant change to our operational practice, we tend to open a consultation.

We don’t do it all the time because we need to function as an organization, but we do it for major ones that we think people might have input into.

These are the active consultations. We have an active consultation on the Routing Registry roadmap. We have an active consultation on the – ASO Review consultation on future structure of the ASO. There’s one on securing Whois queries. There’s a lot of discussion about what we do and do we redirect people to more secure mechanisms.

There’s one on expanding the size of the Board of Trustees, there’s one on fee schedule changes, and there’s one general on prioritizing all of the open suggestions for development.

So these get a lot of email, and we’re in a meeting with all of you in a room, and I’m just – I guess I’m wondering: Are we just shy of the microphones?

If someone wants to speak on one of these open consultations, feel free to approach the mics.

Okay. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. You really asked for it, John. But anyway, I guess that was the intent.

I’d like to see us not have us putting in ACSPs and you actually putting them in and asking for feedback more often.

The reason I’m saying this is best common practices of an organization operationally, we should not have to be telling you. The example was two-factor authentication a couple years ago. Mailing List improvements to email deliverability. All of these wonderful things.

And I appreciate that ARIN takes this input. I appreciate that you do it. I’m just asking that you try to look at the stuff yourself first before we are coming to you for some best common practices.

So I’m trying to be generous, but these are things that the kind of organization that ARIN is should be doing before people like myself or others come up and suggest it in the ACSP or this Open Mic.

John Curran: So, for example, redirecting queries to more secure Whois, https?

Kevin Blumberg: Yes. The whole concept of HTTPS. EV certificate, John. You don’t have an EV certificate on your website. Whatever it may be.

John Curran: In this case, for example, we have a lot of suggestions of what to do. But in some cases it’s contested whether they’re best practices.

Kevin Blumberg: I understand.

John Curran: So that’s why we take the ones that aren’t clear and we say: Do you want us to do this? And if so, are there implications?

Other times we’re putting them in front of you because we’re worried about the cost. A feature that only three percent of the community wants, we need to really get validation before we spend money on it.

Kevin Blumberg: I’m not saying don’t have an ACSP process. I’m saying please submit yourself, don’t wait for us to submit, so that we can have those discussions. And that’s fine, I understand things cost money. I understand all of that.

But I think there are a lot of things that you can be doing, that you know you could be doing; don’t wait for us to say “shh” that. Put it up there.

And then, yes, absolutely, I do think there are small things that you shouldn’t need to ask us for when it comes to security of the website, when it comes to those things.

The Whois is a whole different understanding because it breaks things, and I get that, but there are normal things that you can do that I don’t think you have to wait for an ACSP on.

John Curran: Right. It’s not as if we don’t come up with our own suggestions; we just prioritize them lower than the backlog of things you told us.

Kevin Blumberg: I understand.

John Curran: But we’ll try to kick up priorities, and the smaller-cost items we’ll try to push ahead with without bothering.

Kevin Blumberg: Thank you.

John Curran: Microphones remain open. Center rear mic.

Stephen Lee: Hi. Good afternoon, everyone. Stephen Lee, ArkiTechs Inc., member of the CaribNOG team.

I just wanted to give some quick feedback on the recent ARIN on the Road meetings in the Caribbean – or ARIN the Caribbean meetings, especially comparing it to some of the earlier Caribbean sector meetings from before 2010.

Really like the direction in which it is going now. The content is very much focused on where the minds of the operators and technical community in the Caribbean are.

I think it’s answering a lot of questions that people have about getting their number resources and getting themselves set up properly.

So just I was in the one in St. Kitts. Very strong turnout and a lot of meaningful conversations, which I think is benefiting both ARIN and the constituents there.

John Curran: Excellent to hear.

Paul Andersen: Can I jump in? The voice you hear is me, sorry. While we’re on a bit of Caribbean talk, and there is one more community consultation that’s not listed there because it’s a call, but I would note that the Board does have open the call for volunteers of Caribbean background interested in serving on ARIN Board of Trustees. We have put that forward just late last week. There is a committee dealing with that.

I know this is kind of more a Members Meeting. But I know some people are not here tomorrow, so I just want to remind that that’s an item that we are happy to take feedback on.

The Chair of that committee is just down there. So feel free to approach Bill now or later if you have thoughts, comments, or suggestions.

John Curran: Thank you. Excellent point. Center front mic.

Owen DeLong: Owen DeLong, ARIN AC. I’ve stood up and complained about a lot of things this week, so I’m actually here to say: I do really appreciate the efforts being made on the website. I think that’s going in a very positive direction.

I really appreciate some of the changes that have been made to ARIN Online. It has become much more usable in the last six months than it had been prior to that.

And so the staff is doing some excellent work, and I’m very happy about that.

Paul Andersen: We’re not happy until you’re happy, Owen.

John Curran: Based on that feedback, Owen – thank you very much – I’d like you to submit a suggestion. Can you submit a suggestion that says along with first, last, next page, prior page, put a button that says “full list” so we can give you back the whole list that you can cut and paste and all that?

Okay? Because otherwise I’ll forget that, and you noted it as a step in the wrong direction. So we should fix that as well.

Okay. Center rear mic.

Iranga Kahangama: Hi. This is Iranga again with the FBI. I just had a quick question because I know in the past in speaking with Leslie we had circulated – or maybe not circulated, but discussed things such as adding a legal Point of Contact in the ARIN database.

And so I just wasn’t sure if that was just a thought that had been circulating around and needed more action to be formally submitted or if that is actually circulating somewhere.

John Curran: This is the community’s database. We have no view on – the staff have no view on whether we need a legal contact. We have an abuse contact.

If people think we need a legal contact, it’s – you know, there’s a bit of work in editing it and populating it and deciding the default and making sure, and then when we request that from people to be assigned, but it all could be done.

At this time, we’ve never – to my knowledge, we haven’t received a formal request for legal contact. But I think if you think it’s important, you should find people in this room and get together and put a proposal in.

Because it would be easy to add. It can be put in as a suggestion, and then we’ll work on any policy implications and number management.

Iranga Kahangama: Sounds good. Thanks.

John Curran: Microphones remain open. We can switch back to the Open Mic slide. They know where to find the consultations.

Any other input for ARIN? Had a productive day. I want to make sure people have a chance to speak.

Right microphone.

Is it on? We may not have a microphone. We’re getting there.

Cathrona Samuel: Hello. Cathrona Samuel, Antigua Public Utilities Authority. First-time Fellow. So let me just say thank you for this opportunity. It’s been very enlightening and very enriching.

And I just want to echo the sentiments of Stephen Lee. We have not yet had ARIN in the Caribbean in Antigua, but we are looking forward to it.

And being here has made me very much aware of the knowledge deficits that exist within the region. So we’re really looking forward to it next month, and I just want to encourage you to keep up the good work in the region.

John Curran: Thank you. Excellent to have you here.

(Applause.)

Kerrie Richards: Hi. Kerrie Richards, ARIN AC member. I just want to say that the Fellowship Program that led me to being nominated for the AC and how things fell into place, I think it was a wonderful process.

And I think that the AC, as it stands right now, it was a very – as much as it was a bit scary, because it is scary walking into this room being the Caribbean voice, but I do think that the AC and the team, the staff, really made sure that Alicia and I were groomed well, we fully understood – well, we understood, you know. Our level of understanding has increased since we’ve been on the AC, and we just want to say thank you.

John Curran: You’re very welcome, and we’re very happy to have you.

(Applause.)

John Curran: Very good. Microphones remain open. I am closing them shortly. Shortly is coming now.

Paul Andersen: I’ll just add that the list of consultations we had, I really encourage – like everyone jokes ha-ha, you asked for it, but, no, we really do – especially on the Board ones, we need as much input as we can get, the good, the bad. We have some important items before us in the coming times.

So please – either feedback today, we have Open Microphone tomorrow, Mailing List, grab us in the hall. Please give us as much feedback as you can on what we’re proposing. So thank you.

John Curran: Remote.

Joe Provo: Brian Jones: I agree, Owen has a great suggestion about the long list. I’d like to be able to control F and find things versus having to page through sections of pages. Otherwise, I echo the appreciation for all the work on the ARIN webpages. It’s getting so much better.

John Curran: Wonderful. Good to hear. And I’m closing the microphones with our last speaker. Center rear.

Kevin Blumberg: Kevin Blumberg, The Wire. Thank you for reminding me, Paul, the Board consultation on size. Perfect time, I guess, during Open Mic. I’ve been kind of quiet on it on the Mailing List.

Before I look as a community member at making – at suggesting that – or supporting changes like that, I want to understand what the actual problem is, what are the deficiencies of the current Board set that necessitate it.

I’ve been on Boards of the size that ARIN is, and I’ve found them to be extremely productive. If as a community the Board feels – if as a community we need to be told that there is a deficiency, please tell us there’s a deficiency during the election phase so that we as a community can help elect those deficiencies.

And vice versa. The NomCom needs to deal with those deficiencies.

So I’m really grappling with that. I consider expanding the Board to be a last-ditch effort. I would love to see the Board have Board liaisons, Board advisors, whatever it may take to improve, without necessarily improving the core voting block, the core voting requirements, all of those things.

So I’m hesitant, like I said, but please feedback as much as you can, because right now I don’t feel that as a community we have enough information as to what the problem is to be able to accurately help you.

Paul Andersen: I can start, and then John can. There’s a few items, I guess, we see. First of all, are the current Board able to execute the mission of ARIN? Yes. But do we think we could do a better job if we had a wider background or diversity of thought, diversity of backgrounds? Yes.

We have just noted that, given the workloads and some of the issues coming in front of us, having a wider number of backgrounds around the table is useful. Because there are some very key questions every August that John brings to us.

And while, yes, there can be too many and there’s – with large numbers there can be some efficiency challenges, we don’t believe that there will be a challenge the size we’re looking at.

And we’ve all – as for what we’re looking for, we have expressed that to previous NomComs, and, yes, we are looking at a bunch of other improvements. For instance, there’s been a note at least three years running at the bottom of the nomination committee charter stating some of the attributes we’ve been looking for.

And while it’s varied – for instance, last year’s nomination committee put together I thought an excellent slate putting many of those qualifications together, the other thing we were looking for is some diversity of skill background.

It was excellent to have for the first time at least in my group, and I think the Board’s history, somebody with the actual financial literacy background, professional background in Nancy Carter, and the Board has already seen significant improvement in some of the financial matter having that.

Yes, we all had some financial background before, and we like to see that in some of the other skill sets.

And on that, we will be circulating soon a document, because we’ve heard many a time that it would be good to refresh, for lack of a better term, the job description and skills that we’re looking for, and that is right now literally in the last draft stages, and we hope to have that out fairly shortly with some governance items.

I could go on, but I think I’ll give John a shot.

John Curran: I would like to – I’ll go verbatim from the consultation, to be very clear.

So in February of this year, the ARIN Board discussed an additional issue beyond the question of diversity of background or geography or skill set. We discussed the additional issue related to the present size of the Board, specifically the challenge that a smaller Board poses when engaging in strategic discussions, for example, in regard to the long-term direction or relationships with other Internet organizations.

While many of these topics are discussed with the community prior to decision – example, formation of the NRO, support for the IANA stewardship transition – it is often to the ARIN Board of Trustees to decide whether to explore these initiatives when they’re in an early stage.

So there’s a wide diversity of the Internet ecosystem that can be affected by ARIN strategic direction, and this includes Internet service providers of all sizes and Internet online content industry, datacenter and call operators, educational and government networks, commercial firms, civil society.

While the trustees elected by the community often have broad knowledge of the Internet ecosystem, seven trustees is a relatively small group to evaluate impacts across the entire Internet ecosystem.

That’s actually the text of the consultation, and it’s talking about something aside from the actual gender, geographic, skill set diversity of the Board. It’s literally talking about the number of people in the room and the breadth of their individual backgrounds so when you have to discuss something in a strategic level with just the Board, do you actually have enough people who know all the relevant corners of the Internet.

Paul Andersen: One last sentiment, because I hear the number seven thrown around. And from our standpoint it’s six generally. John, two feet away, is the CEO. He has a much different perspective. Generally he’s coming with strategies to us, and he’s looking for input on that. So he doesn’t normally count himself on that.

Yes, we are looking at doing an appointment, but that’s not something we were hesitant to do that and we would much rather the Board come from the elected community.

Thank you for allowing us babbling. I see at least people lining up.

John Curran: Cathy.

Cathy Aronson: Cathy Aronson. I thought about this a lot, and I always try to post something constructive when this comes up, but it’s always been a popularity contest.

And we’ve had a number of unbelievably qualified candidates over the years here and there that had no chance of being on the ARIN Board because no one in this community knew them.

So giving guidance to the NomCom is great. But giving that guidance or at least some sort of condensed version of it to the community to give them guidance as to maybe we don’t want to pick the person whose name we recognize, maybe we want to pick the person who can do the job might be a good idea.

I mean, it’s just the election process makes it really hard to get the people you need. Maybe appointing them is a better idea because at least then the community will see that person for a while and know who that person is, and then maybe they can get elected.

But it’s a really high bar in this community. If we haven’t heard of you, you’re not going to get voted in. And it’s a catch-22.

John Curran: At a minimum, the guidance of the NomCom, while public, isn’t front and center when you’re seeing the slate. At least the slate announcement and maybe in the election process, we should highlight here was the guy who was given to the NomCom. That’s a minimum first step we could do on that line.

Center rear.

Kevin Blumberg: Kevin Blumberg, The Wire. John, I understand what you’re saying. The issue that you brought up is a singular issue around certain topics but not for just the daily running and good nature of the organization.

I truly believe that you can get that input, like I said, what I said earlier, which was through Board advisors, Board liaisons, whatever it may be. I believe that having that core is important, because otherwise – and this is the negative side to increasing the Board size – you start having Board shopping internally on matters.

And I don’t want to see that necessarily become a problem. I’ve seen it on other Boards, and it can be extremely problematic, far more than the problem you’re trying to solve.

So try that first is my suggestion.

Paul Andersen: I just want to comment because you’re calling it the day-to-day running of the organization. Because that’s important, because that’s not what the Board does, and we try to stay out of it.

There’s a large, professional, excellent staff back in northern Virginia that run the day-to-day operations. The board –

Kevin Blumberg: Can I clarify what I meant? What I meant was the day-to-day running that a Board is used to doing. The things like the budgets, the things – all of the things that you have in your action plan that are day-to-day for a Board.

I realize it might be misconstrued as the day-to-day running of the organization. I’m just saying the things that a Board normally does.

This one issue is –

Paul Andersen: Which one issue is that?

Kevin Blumberg: The one that was brought up about diversity for being able to work within other environments that was part of the –

Paul Andersen: We’re looking for it from the standpoint of helping to help form better strategy for the organization with the role of the Board being the management of the CEO, setting a budget and setting a strategic plan.

The strategic planning is by far the most important skill. I would encourage all of you to make sure that that’s what we look for in good Board members; that can help give that guidance to the CEO so he has his marching orders and he takes that off and executes for us.

Kevin Blumberg: Again, you can get that from non-voting advisors. Guys, I don’t know – guys, girls, people, I don’t know what the specific reason is. We had our consultation six months ago. Okay? So there’s more to it, and I understand that. But try something that’s not expanding the Board, and I will leave it at that.

John Curran: I think I heard your point. I think it is possible for the Board when it has a topic, and it’s a well-understood topic, to bring in additional expertise to make sure it has a broad enough base if it doesn’t feel the six elected members are enough.

So the challenge is these are often strategic direction. An example I used in the announcement, the IANA stewardship transition, saying, yes, we do believe that it’s possible for the US government to relinquish its contract and for the community being represented by the collective RIRs.

That’s a decision that you can’t take to this room, it’s the questions you can’t take to the whole audience, because even their consideration affects the dynamics. You have to discuss it amongst the Board because you’ll set things in motion that have implications.

When you do that, if you bring advisors in, depending on who you bring in as advisors, you end up with a skew on the output.

I’m going to tell you I’m the one that’s pushed hard for a larger Board, specifically because our ecosystem – we’re not a normal trade organization.

We don’t function as the association of a particular industry and all the representatives are here. We’re part of an Internet ecosystem with other RIRs operating in an evolving landscape.

There’s a lot of strategic questions. If someone asked where we’ll be in five years or ten years, a lot of that is actually an open question, okay, in regard to how we work, our relationship with other organizations, how the address registry works.

So we can bring in people to help, and that’s a suggestion that I’m going to take to heart and try to figure out one way or another how to use, but I guess all I’m saying is that if we don’t expand the size of the Board, then I’m relying on the six-member elected Board, and you have to have a lot of faith in them that when they send us off looking at something, that is strategic in a direction and it has implications. You have to be satisfied that it was launched by those six people, even if they didn’t have a full view of the landscape.

Paul Andersen: I’d like to add two things. First of all, the Board does bring advisors in. We’ve used people such as Ben Edelman, you may know. We have our external counsel, and in other cases we’ve used that. That’s not a problem.

But we’re talking about the people who are elected by our membership to be accountable who are, in some cases, being faced with large decisions that affect the greater community. So finding the right balance of input is something important.

Last year we did a consultation, which we got good feedback on, and there was questions and we realized that perhaps there was a bit too much focus on it that this one thing was going to solve a problem that was commonly being done.

And we don’t suggest that this by itself solves a problem. It’s this – because it’s a bylaw matter, the consultation, but a lot of other work that the Board’s been doing, both in terms of the nomination committee, the job description, items that we feel will help in that regard.

Kevin Blumberg: I’m trying to say you can have non-voting board members. Call them advisors, elect them, whatever it may be. You don’t need to expand the size of the voting Board.

John Curran: That’s a different –

Kevin Blumberg: That’s what I’m trying to say. Paul, you’ve been, in fact, on a Board where we had a Board – somebody who was a Board advisor who was in every Board meeting who was there to help and provide feedback but was non-voting.

You can elect that person, you can appoint that person, it doesn’t matter. But I don’t want to expand the core voting Board, and I think that’s really all I’m trying to say.

Paul Andersen: I’m just saying, I had that – we’ve come a second time because – and I’ve put on it the agenda. I’m only speaking for myself and on behalf of the Board because we feel very – I felt very strongly, I know John felt strongly, that this is not so much about fixing something that’s broken but increasing the strength of your Board, which is good for the community and the organization.

Kevin Blumberg: Thank you.

John Curran: Rear microphone, yes.

Alyssa Moore: Was there someone remote first?

John Curran: Remote?

Joe Provo: Yes, if you wish to cede.

Jason Schiller, Google, ASO AC: Can we have those added Board seats restricted to the needed type? And if we can’t fill that needed type, leave it unfilled or redefine the type needed.

Alyssa Moore: Alyssa Moore, Cybera, ARIN AC. I am hearing the current Board and the President and CEO say that they would like a larger group of people helping with the strategic direction of the organization, and whether that is in the form of voting or non-voting members doesn’t bother me either way.

However, I don’t think that they should be elected. Unfortunately, direct democracy doesn’t always solve the exact vacuum of skills that may need to be filled on a Board.

And so I am in favor of having them appointed when and if necessary by the current Board. And I know there’s a mechanism for one seat to be appointed each year right now. If there’s a feeling that there should be up to nine, then perhaps that number can be increased and that mechanism can be used where possible.

And, again, whether they vote or not is – doesn’t matter to me. But it still increases the diversity of thought in the room and gets those people that you may need into the conversations, whether they are someone who operates a – with a strong datacenter background. I think everybody on the current Board is from the ISP community or a network operator in some form or another, and that’s not our community. That’s not representative of them.

Paul Andersen: Thank you. If I can just – first Jason’s. I think we’ve been trying – kind of both at times. We’ve been trying to balance two things.

First of all, we’ve heard from the community are strong proponents of an elected Board. So I think that’s why we have always shied away. We have not gone down the appointment road because there has been just concerns that that may not be as accountable to the membership.

And I think, Jason, you have a good suggestion. We have looked at those models for one. There was several where we looked at a few, especially that related to the geographic one.

I think our concern – I’m not saying it’s not workable, is just it’s – and we’ve seen some other systems, is complexity of the voting system sometimes can cause ill effects.

So we’ve tried to keep it in the end a simple system of so many seats, so many votes. But I don’t think we’re opposed to looking at any of that further.

John Curran: Rear microphone.

Chris Tacit: A big part of my day job is actually corporate governance. I actually am Chair of two Boards in Canada, I’m Secretary of another, and I’ve been Chair of other Boards and I advise Boards and organizations on governance. So my observations are sort of colored through that particular lens.

And I really do agree that for this organization, with this complexity and the number of stakeholders that it is part of, this is a small Board in my experience. That I think is true.

I also think that elected directors are the way to go. But I would suggest that you look at this issue in a more comprehensive way than just a Board expansion issue but perhaps more of a broader governance review.

And a few of the things that I’ve observed – and I don’t have detailed knowledge, so if I’m not on point on anything, that may be true because I don’t have the complete visibility.

But, for example, when it comes to the Nominating Committee, I think it would be very good to actually post public ads and not necessarily just rely on community members for the Nominating Committee, and, in fact, ensure that there’s diversity of skill set on the Nominating Committee itself. That’s one idea.

The other is, in a similar vein, that Board members could – that we could try to find mechanisms to actually draw in more Board members who are independent of our particular business.

Because I think as much as we – we can try and cover off internal blind spots, we may not cover the big external blind spots that are completely outside of our ecosystem but could still be the elephant hoof that could crush us one day.

So those are some of my observations.

The last one is probably going to be the least popular, and I may have to flee after I make it.

Paul Andersen: Close the doors! Close the doors!

Chris Tacit: I’m a big believer in Board term limits. And if you really want Board renewal, I think that’s a measure that ought to be considered. And it’s a very tough thing for incumbents to consider.

And by the way, lest anybody thinks that I’m just saying this for the Board, I would be happy if that were the case in the AC as well.

I do think that that’s one way you get Board renewal and diversity, is by forcing people to step away after some specified period of time so it doesn’t become perpetuated by virtue of history alone.

Those are my major comments. Thanks.

Paul Andersen: Thank you, Chris. That’s great feedback.

I think I agree with you. And we’re trying to look at this as a more comprehensive; maybe not as expansive as you propose.

But I know that we, for instance, have looked and we’ve just adopted a more formal adoption – sorry, appointment process, before we had the RIPE; that we’ve actually put some meat on how that process works from a governance that’s transparent, and of course we’re running that code right now.

We’re doing some work with the NomCom. Tried to do a bit more; we got a little too aggressive. So we’ll be doing some more work in August. But we made improvements both in terms of just the data that we’re collecting from those, all the nominees that you will hopefully all read in detail and try and do some digging into the verification for hope of the nominees, so we’ll hopefully be able to get some more potential outside candidates.

Not that those from within the community are not excellent. We’re looking at some Board leadership/mentorship programs that will be adopted. Term limits is something that has been discussed in recent memory as well. So it is something we’ve considered along with the Board size.

So, yeah, we are looking at this as a larger piece of puzzle about just how do we raise the effectiveness and bar on the Board.

And I don’t say that to say – I agree with you on that; that we’re trying to look at many pieces of the puzzle. There isn’t going to be one, because I hear that often that I guess things – people say, well, this doesn’t solve the problem.

I agree in that no one issue is going to solve it. We’re going to have to do a little bit, including the community, all the feedback we can get on hopefully electing these people.

Chris Tacit: And just to say I think that ARIN’s been very good at self-reflection and development and is service-oriented both internally and externally. I have every confidence you’ll figure it out.

It’s not meant to be as a terrible criticism of the status quo, because I don’t think you’re in a horrible place now at all. As you say, I just think it could be even better. Thank you.

John Curran: Criticism is often an opportunity for improvement, and thank you.

Yes, over here.

Joe Provo: This is a follow-up to the phrasing that Jason used. Brian Jones: I think needed types for the Board should be clearly defined and published so the community understands what the needs are before voting or reading over credentials for the nominated members when searching – in search of who to vote for.

John Curran: Okay. Excellent.

I am closing the microphones.

Owen? You were there. Are you sure? Okay.

Microphones are closing shortly. Closing momentarily. Microphones are closed. Thank you for the feedback.

This ends our Open Microphone session.

Public Policy Meeting, Day 2 - Closing Announcements and Adjournment

John Curran: Okay. We are now done for the day, and actually early. Imagine that. Let me do a couple of closing announcements.

So first thank to our sponsors, Webpass and Google.

(Applause.)

John Curran: Okay. Don’t forget the meeting survey. We have a survey that we use to improve our development of the meeting. And so if you go to Survey Monkey and go to /r/ARIN 41 survey, you can give us some feedback. And all the responses will be entered in a lottery for a chance to win an Xbox One.

Reminders. Breakfast is tomorrow. Our Members Meeting kicks off at 9:00 AM. All the materials are online. We’ll hear reports from all the departments – our financial report, report from the Advisory Council, and the Board of Trustees.

That ends our meeting. Have a wonderful night. I look forward to seeing everyone tomorrow. Thank you.

(Applause.)

(Meeting adjourned at 4:39 PM.)

Network Sponsor

Webcast Sponsor