ARIN 43 Public Policy Meeting, Day 2 Transcript - Tuesday, 9 April 2019 [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: Good morning. If people will come in and be seated, we’ll get started.

Welcome to the second day of ARIN 43 in Barbados. I’m John Curran, President and CEO. We have a pretty full day today I’m going to talk about. Let me start right in.

We have remote participants, as a reminder. I’d like to welcome those who have come back in remotely. Everyone has access to the materials. It’s in your online site and it’s in your app if you’re using the application for your phone. You can participate in the virtual microphone and consensus process. So glad to have you. Welcome remote participants back as well.

Get the meeting app if you don’t have it. The meeting app has a great schedule of events, lets you find your way around the hotel, lets you find the attendee list. Feel free to download it, and it’s useful at times.

I’d like to thank our sponsors – Network Sponsor, C&W Business, and Webcast Sponsor, Google.

(Applause.)

I’d also like to thank our Platinum meeting Sponsor, Addrex, and Silver Sponsor, IPv4Mall.

(Applause.)

So, we’re going to have discussions today in the morning about some policies. These policies are part of our Policy Development Process. The Chair of the Board of Trustees will moderate the discussion and make sure everyone has a chance to be heard.

That means you should be respectful. Pay attention to the courtesies in your program guide. And it’s just important when you go to the mic, speak clearly. Speak slowly for the sake of the live transcript we’re building. State your name, affiliation. That will help everyone and let us have a good record of the meeting.

Today’s agenda. We’re going to hear global reports in the morning from APNIC and AFRINIC. We’re going to have RPKI Services Update, which includes an update from the UPENN folks that did a study on issues with deployment in North America. And then I’ll give a report from ARIN about our ongoing risk assessment.

We have the ASO AC Update. We have the IANA Review Committee Update. We’ll give a Transfers Report about transfers in the region and inter-region. We’ll have a LACNIC report, and we’ll start in the policy block and handle ARIN 2019-4: Inter-regional IPv4 Resource Transfers.

We also have a number of others on the agenda. We have a discussion of potential Waiting List policy actions that are being considered.

We have several Draft Policies that are not Recommended Draft but are still important discussions. We have global reports from RIPE and the IANA PTI. And we have a Caribbean update. You’ll hear from our Government Affairs and Public Policy team. We’ll give you an update on our software development and Open Microphone.

It’s going to be a very busy day. We’re going to go straight from now until 10:30, which is our first break.

Again, there’s a policy discussion room around the corner. If you want to talk about ideas, grab a member, people who have similar ideas, and go over there and work something out. This is how we make progress in our policies.

RSD help desk remains open outside, available 8 AM to 5 PM.

And at the head table, same head table: Paul Andersen, our Board Chair; Bill Sandiford, our Board Vice Chair; Tina, our AC Chair; and Leif, our AC Vice Chair.

With that, I’d like to start with our first presentation. And it will be APNIC. Come on up, Tony Smith.

Global Reports: APNIC

Tony Smith: First up for the day, so hopefully this will help wake you up from last night.

Okay, APNIC update. Let’s get underway. So the APNIC region, for those who are not familiar: We cover 56 economies in the Asia-Pacific region, as far west as Afghanistan, all the way through to remote Pacific Islands in the east.

It’s a very big region, multiple time zones, multiple cultures, very diverse.

Our membership has continued to grow over the years. We are now – on this slide here, you can see we’re just under 16,000 end of 2018. We’re now just over 16,000.

We have national Internet registries within our region. Some of those predate APNIC, which is sort of unique amongst the RIRs.

So in terms of direct membership, it’s around 7,000, and membership through the NIRs is around 8,000, all up around 15,000 at the end of last year, but it’s about 16,000 now.

In terms of the delegation statistics, as you can see on the screen here, everything is still to an extent moving up and to the right. We had a dip in 2017 across most of our metrics in terms of delegations.

v4, as you can see, has flattened off a bit, which is interesting. v6 continues to rise. And of course, v4 transfers continue to rise – not as many as in the ARIN region, but transfers are still a big deal in the APNIC region as well.

In terms of the resource holding across our members, the good news here, there’s probably a stack. The highlight is the v6 number continues to grow. 62 percent of our members have a v6 allocation, which is great. And we continue to work to make sure that they actually announce those allocations.

The survey, just want to touch on this quite quickly. We do a survey every two years of our membership base and the community to find out what they think of us, how we’re going, how we’re performing, but also to get information from them on what we can do to serve them better and what are their challenges.

We had a really good response last year with more than 1,200 responses. A third of those were in languages other than English, which was great.

The survey results themselves, I’m not going to go through them today because obviously it would take forever. But if you go to that link, APNIC.net/survey, you’ll find all the survey materials there in the reports.

There’s some interesting stuff in there. Probably two of the biggest findings – well, a good finding was that the members actually were pretty pleased with our performance, which was nice.

But more importantly, we found out things that they want us to continue to invest in. Security and training were two of those areas. And I’ll talk a little bit more about what we’re doing in those areas in a moment.

Policy. So this is probably the most boring slide of my whole deck, but it’s actually got the most information in it that you’ll probably be interested in.

So, of the proposals that have gone ahead to the members in the past year and a bit, probably the ones to talk about are prop-125, which was validation of the abuse-mailbox and other IRT emails. I note that this is a proposal – a similar proposal has been put forth in the ARIN region.

This reached consensus at APNIC 46. We’re now in the process of implementation. That will happen over two phases to occur by the end of this year. But most recently, at Daejeon in Korea, at our most recent meeting this year, three policies reached consensus, but two that are probably of the most interest to you is that our minimum allocation size from the final /8, 103/8, has been reduced to a /23. Used to be a /22.

And alongside that, we maintain a Waiting List where all of our recovered IPv4 space is put. And that Waiting List in the APNIC region can request a /22, a maximum /22 from that Waiting List.

And what that – that Waiting List has been abolished – well, not yet. It will. The implementation period for that policy will be within three months as per the PDP. However, the maximum delegation for 103/8 has been immediate, so that’s enforced now.

What this means is that in the past an APNIC member could have one allocation from the final /8 and one allocation from the – sorry, to a maximum of /22 from both the final /8 and from the Waiting List.

With the Waiting List now going to be abolished, it will mean that they can only get a – one allocation from the final /8 of /23. Most of our existing members have actually done that. So realistically speaking, this is mostly now new members would get that allocation.

We do a lot of work in the region, a lot of external engagements. I’m not going to go through this slide. I’ll talk through them in a moment. We try to spread our activities across four sub-regions, which are South Asia, Southeast Asia, East Asia and Oceania, in a number of areas.

Training is a big one. We do a lot of training in the region, both face to face and actually online as well. Training is a big deal for our members. It’s something that they’ve requested constantly in our surveys. It’s something they want us to continue. So we try to get around the region and try to provide as much training as we possibly can, as humanly possible with our resources.

We also participate quite a lot in the technical community obviously within our region. We participated in 21 NOG events this year. I think there’s – from memory I think there’s about 17 or 18 NOGs in our region. So they keep us busy.

We also invest our staff time providing advice and also sponsoring equipment for root servers and IXPs in the region.

We also have, this year have, been spending a bit more time building a closer relationship with the research and education community. And we did some training for the first time at the APAN meetings and have been working closely with them.

On the security front, so when we say “security” for APNIC, it means that most of our work is done in forms of training and advice and technical assistance that we provide.

So we also have made sure that we’ve been including more security content in our conferences. We’ve done that in partnership with FIRST, which is the Forum for Instance Response Teams. For the past few years, we’ve made sure that they hold a one-day conference as part of the APNIC conference or the APRICOT conference.

That content is now being embedded into the main program, which is good. We want to make sure our members are exposed to that information and are getting that input.

But at the same time we are doing a lot of training in the region. We’re contributing to the establishment of new CERTs in the region. Tonga was the first one that we had a hand in providing advice and technical assistance with. Papua New Guinea and Vanuatu were the other two last year.

We also did a lot of work in PNG ahead of APEC meeting, which was held there last year, in terms of providing training and technical assistance to make sure that they felt ready for that meeting.

And security continues to be a big focus for us. We continue to invest in it, and it’s something that our members want us to keep doing.

The conferences. I’ve mentioned them a few times. The last two were – APNIC 46 was in Nouméa, New Caledonia, an island paradise not unfamiliar to this one. And the last one was in Daejeon, South Korea, which was much colder, earlier this year.

The attendance has tended to be strong, continued to be strong actually at the conferences. Our remote participation numbers continue to rise as well, which is a good thing. That’s something we’ve tried hard to grow because we obviously understand that our members – it’s a big region and they can’t travel to all of our conferences.

RPKI. I probably won’t go into too much detail on this slide apart from the fact just to say that RPKI continues to be a focus for APNIC. It’s something which we’ll be doing a lot more on this year in terms of training, education and encouraging our members to basically certify their resources and get their ROAs.

We’ve had a campaign going for a few years called Ready to ROA, with the old tiger down at the bottom there. But if you’ll see from our numbers, it is growing in our region, which is good, albeit from a low base. And we want that to continue to grow, and we’re already seeing that this year. So it’s something that it’s going to be a big focus for us this year and into the future.

I mentioned training before. APNIC Academy, I just want to call this out. This is an online learning portal where you can do self-paced training.

We relaunched it in August 2018 with all HTML5. If you haven’t had a look at it and you’re interested, there’s plenty of courses on there. It’s free. It’s self-paced. There’s a mix of technical courses, also a policy PDP course, if you’d like to learn about the APNIC PDP.

We’ve had a number of people enroll, a good number. 1,500 last year. There’s also virtual labs there where people can go and test out what they’ve learned on some virtual labs across different vendor equipment. And new courses are coming soon.

So this is another one of our investments that came via feedback from the APNIC survey, where our members were telling us that they needed to have access to online training as well as face-to-face and be able to do it in their own time, which is the reason for the academy.

The blog. I’d like to just quickly mention the blogs. It’s close to my heart. We started the blog in August 2014 as a way to better communicate APNIC’s announcements. But it also – one of the other main reasons why we started it was to make sure that we provided a place for the community to share its news and reviews because there wasn’t really a place for that to happen.

And it has been a raging success. We’ve been extremely happy with it. We publish every day apart from weekends.

We have a mix of posts that are from APNIC and from the community, around 50 percent from the community. And when I say the numbering community, I don’t just mean the APNIC community, but globally.

We have authors from all around the world. If you haven’t been to the blog before, I recommend you go and have a look. I’m sure there will be something there that takes your interest.

And if you have story ideas or anything you’d like to share, then get in touch because, as I mentioned, this is – we still see this as a global resource rather than just a Asia-Pacific APNIC resource.

Finally, to touch on the foundation. We established the foundation two years ago. As I mentioned before with our training, we have a lot of demand for training, and we can’t necessarily meet that demand for training through member funds and through our own resources.

So the foundation was established to help us increase our development activities without having to rely on our member funds.

There are two staff who have been seconded to the foundation from APNIC, which is Duncan Macintosh and Sylvia Cadena. The Board was appointed last year. We have appointed two new members, Michael Malone and Danish Lakhani.

We now have a full Board – actually not a full Board; we’ve still got spaces for two more. But the first AGM was held last year, and the second one is coming up.

It’s been a success so far. The foundation raised over a million dollars Australian in its first year for projects, and we’re hoping to continue that success to help us fund activities that we’re doing.

Most of the activities so far that have been funded have been in the Pacific, which is great. But we need to continue this to make sure that we’re meeting the demand for the training and development activities in our region.

And the last thing I wanted to say was join us. Our next conference will be in Chiang Mai in Thailand in September. The dates there, the 5th through the 12th. The actual conference week or conference days are the 10th through the 12th of September. Chiang Mai is a beautiful place, as you can see – lots of lovely temples, great food, elephants, all sorts of good stuff.

And you can also go to a conference as well and talk about Internet numbering stuff. And you can fit that alongside the rest of it.

But please do come along. We’d love to see you there. It should be a great conference. And that’s all for me. Thank you.

(Applause.)

John Curran: Any questions for Tony?

(No response.)

Thank you very much. Next up we’ll have the AFRINIC report, and I believe Patrisse is – very nice.

Global Reports: AFRINIC

Patrisse Deesse: Good morning. Happy to be here. I’ll give you a quick update on the AFRINIC region. A small, short intro.

Service region. We’re the fifth RIR that was created in 2005. It’s headquarters in Mauritius.

We’re serving 55 economies in Africa and the Indian Ocean region. We have just about 50 dedicated staff with a couple of them working remotely. And it is believed that this might increase further in order to cater for the needs of the – the growing needs of the region.

Quick look at the membership evolution. That’s growing, as you can see. Not as much as in other regions, but we do have our own growth, which is part of our own reality. And we do anticipate the growth to continue in the foreseeable future.

Quick look at the graphs with the IP distributions. You can see it’s per region, actually, it’s per the countries. And South Africa seems to be taking the large chunk of it, especially in IPv6. And the other continents, the other part of the continent is fairly equally distributed.

We are the last one to be hitting the exhaustion. We are approaching that very fast, and we only got to about .4 of a /8 remaining. And we’re about just over 4 million /32 before we hit the last /11. And then we hit the softlanding, phase two.

So that is – given the current rate of release of IP addresses and demand, we should be getting there probably in the third or fourth quarter of this year.

Couple of initiatives. We’ve adopted the AFRINIC IRR following RIPE NCC’s decision. And it’s working quite well. And at the same time, we implemented the Lame Delegation Policy, which is working well. And there’s been a decrease in the number of lame delegations over the past month, from 40,000 to 13,000 by the end of 2018. Seems to be working quite well.

Quick look at the policies, which are at different stages of the process. We’ve got a couple of them which have been completed and implemented. And we’ve got a meeting coming up in two months’ time. And there’s going to be quite some excitement having to deal with those policies.

There’s quite a number of them, as you can see, still under discussions, which hopefully will be carried through to the next AFRINIC meeting which will be held in Uganda in June.

Still some more policy under discussions, as you can see. Hopefully this is really going through the discussions on a Mailing List and what have you at this very moment.

Initiatives. As part of our commitment to the community, we conduct a lot of training. This is a very important aspect of our participation with building capacity. For 2018, 700 engineers and managers were trained in 21 countries.

This will continue to be our focus. And we have also developed webinars and online training. And there’s a slight shift in the training approach, moving it more towards IPv6 deployment.

We’ve created an IPv6 help desk. We’re having quite a few – the focus has really shifted to the IPv6 deployment and moving with the governments and managers of the importance of deploying and actually hand-holding, if you want, the various organizations who are willing to be part of it.

We also have the research and innovation initiative. We have got some five RIPE Atlas sponsored and deployed. We have conducted a couple of measurement workshops, including an academic workshop at AFRICOMM. And this continues to increase in importance as well and become a popular initiative which we have created.

We have the FIRE program, which is probably equivalent to what APNIC has got. It’s actually – the aim is to provide some assistance to the community members who are willing to start projects but do not have the funding.

So far in 2018, we’ve supported five projects, to the total of $31,500, bearing in mind that some of those funds are internally generated. And also we get funding from outside donors like IDRC and other generous organizations.

It’s been a very popular program, and it’s really attracted a lot of attention on the region.

As I have mentioned earlier, our next meeting is in Kampala, Uganda, from the 9th to the 21st of June. It’s actually the AIS meeting, which is a combined meeting with many stakeholders and partners like AFNOG and older Internet-related organizations. It’s quite interesting sessions, and we’re hoping to see all of you there.

Thank you very much. And that is all from me.

(Applause.)

John Curran: Any questions?

(No response.)

Thank you for coming. Okay. At this time we’re going to go into an RPKI Services Update. I’m going to ask Chris Yoo to come up from Penn Law, and he’s going to give a summary of their recent study, and then I’m going to give an update on the status, ARIN’s analysis and risk management. So come on up, Chris.

RPKI Services Update

Christopher Yoo: Thank you for inviting us, John, to present on this, and frankly for being such a great partner in what has been a very interesting exercise in terms of how to make the Internet routing more secure.

In a nutshell, for those of you who don’t know what RPKI is, I guess I owe a great thanks to the APNIC presentation immediately before to highlight that this is something that’s growing.

This is a way that we can actually make routing more secure. As you know, we create routing tables by having BGP partners exchange routes. That information becomes basically unauthenticated. You have to take the word that the person you’re sharing routing information with, that they’re in fact giving you a valid route.

There are two technologies that can make that more authenticatable. One is BGPsec, which is actually to make sure the entire step of the route, all of them are validly followed.

RPKI is the one – is a much more modest technology, is called origin validation, which is you can verify that the last step that the route is pointing to is in fact the authentic location for that website.

So there’s two steps to RPKI. The address holder has to sign – use a public key given by their RIR to sign a certificate, and that places in a certificate authority generally hosted by the RIR.

And then the ISPs have to access those libraries to do something called route validation, route origin validation, to actually screen on the basis of that information. And every time they get a route, they should double-check it against the certificate authority and say they think that UPENN.edu is located here, according to the route being advertised by my BGP partner.

You can then look it up in the library, in the certificate authority, the certificate library, and make sure in fact that’s pointing to the right address. And that will make the Internet considerably more secure.

Not a complete solution. Although, with edge providers building closer and closer to the customers, if it is a one-hop route, it can actually be a complete solution.

But what we see is a growing interest – on the other hand, it’s fairly easy to do and would guard certainly against misconfigurations, but in fact would provide some degree of protection against route hijacks.

There’s been a bunch of things in the news lately, some very conspicuous hijacks of Cloudflare’s DNS and Amazon’s DNS, as Cloudflare has begun build – committing to RPKI, beginning to filter on this basis and is developing their own validator software.

Interestingly, though, if they deny the route, it will simply migrate through transit some other way. The biggest news are people like AT&T who are starting to actually filter routes based on RPKI information.

Google is starting to do the same. They’re in fact flagging routes, and they announced later this year they’ll begin actively filtering on it.

And what we see is, interestingly, NTT is doing something else, which is using the certificate library to clean up their IRRs, to actually look at how they’re configured, combining it with other information to improve the routing quality information.

We hear from APNIC that they’re in the process of pushing RPKI. And David Wishnick, who is my colleague at Penn, just showed me a posting from the NANOG list yesterday that three African ISPs began filtering on the basis of RPKI on April 1.

So this is a technology that’s increasingly growing in importance. And one of the things we will talk about more I think when John talks, operationally this has some implications for you if you want to make sure your networks flow smoothly and all this works properly. That’s really the domain of technical experts like yourself.

We were actually approached by the National Science Foundation to solve a particular problem, which is generally RPKI, like many of the technologies, has been deploying relatively slowly.

But the big mystery is it’s actually been deploying much more slowly in the ARIN region than it has in other regions. RIPE has now hit 43 percent of its addresses or have signed certificates. And you see in the LACNIC region, it’s roughly 23 percent.

ARIN is at 4 1/2 percent. And most interestingly, the others are growing slowly. The ARIN region has been roughly flat across this time period in ways that create some concerns.

The question is what is – is there something about what’s going on in the ARIN region that is preventing it from being more widely deployed? That’s the who’s signing. If you look at ISPs, how many are filtering, there is an APNIC resource that is actually looking at ISPs and how many of them are filtering.

Again, RIPE, the number of ISPs in the RIPE region is significantly larger. And in fact among those who are deploying route origin validation, 80 percent of them do not include the information from the ARIN region, including the ARIN TAL.

So we were asked by the National Science Foundation to do a study to investigate whether there are legal barriers that are at play in ARIN that did not exist in other areas.

And in fact one of the – this is on the basis of several conversations that people have had at different conferences.

And in fact they focused on certain clauses within the contracts that ARIN asks different users to sign. As you know, most ARIN members are resource holders, so you signed an RSA to have the address.

There’s also something called the Relying Party Agreement which other people who build on information, who are not themselves address holders but are building on the information, need to sign.

Our methodologies. We’ve done analysis of the contracts on a comparative basis with both ARIN’s and in other regions. We’ve done a broad scale of interviews with stakeholders and engaged them very actively and very cooperatively with ARIN. And I think it’s been a positive dynamic and one that I deeply appreciate.

We’ve been at the last three NANOGs. We released a report at the end of the year which we’re happy to share with you. I apologize in advance. It’s a lawyer-length report – it’s about 30 pages – as opposed to a technical-length report. But it’s one of the things that’s appropriate for the subject matter.

And to me, I really welcome the opportunity to engage the ARIN community because this is something of vital importance to the ARIN and all of its members. And this is the first presentation, first opportunity we’ve had to talk about this here today.

Okay. So if we’re going to think about the key issues involved in this study, we’re looking at the Relying Party Agreement, particularly the fact that other – the four regions do not in fact require a Relying Party Agreement, and there’s certain clauses within it also that we’re analyzing about the indemnification clause about allocation of liability.

The – there’s a – talking about how we’re going to style the acceptances – and this is an area where ARIN has already made changes to its policies in response to what we’ve learned through the study.

And a possibility of another way to managing liability is the – and this is a topic which is just now beginning, and we’d love to get the feedback from the community – is whether we should separate the RPKI function from the numbering functions provided by ARIN and create another entity to handle that.

There’s another provision in the RPA called the prohibited conduct clause, which we’ll explain, that causes some problems.

There are other vectors for possible diffusion beyond law involving procurement policies. We’ll talk about best practices because part of this is about implementation, not just liability, and that’s where this is going to affect everyone in this room.

And there’s a series of other smaller recommendations which are mentioned in the report, which I’ll just flag for you.

So starting at the beginning. So as of now, the primarily most widely used validator software – this is the thing that ISPs run that accesses the library and determines which routes are valid and invalid. To get to the library, you need to access something called the Trust Anchor Locator, or the TAL, which tells you where the library is located for the five RIRs.

As of right now, the leading validator software is shipped with four TALs preloaded, but not ARIN’s. And this is one of the primary reasons that 80 percent of the people who are validating routes do not have ARIN’s TAL.

What’s interesting is the reason it’s not distributed is, by policy, ARIN requires that everyone who wants to access the TAL go to ARIN’s website and click through to get access.

And the reason that is, is there’s an aspect of US law that makes it much stronger to say that by clicking through, you create a contractual acceptance of the terms and conditions of the access to the ARIN TAL.

And because that is a different step that is not required by other RIRs, it makes it more complicated – it leads the validator software distributors to believe that they cannot distribute their software with a TAL preloaded.

What’s interesting is: Why is that? There are aspects of American law about why we would want to handle this through a contract as opposed to through general principles of law of negligence liability.

But it’s interesting, as a matter of contract formation, the contract is much more likely to be found and found valid if someone clicks, actively clicks on something.

There is precedent that if you put terms and conditions nearby or if the customer, the person is aware of it, the US courts have found people bound by those terms.

But that’s not entirely clear and it does create some risk. And there is a much stronger authority that says if the terms and conditions are in the visual field of the person who is accessing the resource at the time they accept the resource, then it’s more likely to be found to be a binding contract.

So we actually analyzed all the alternatives. There are people in the community who would like to abolish the RPA altogether. I suppose another option is to keep the RPA unchanged.

And a third option is to keep the RPA but to make some modifications, and particularly focusing – the primary focus we’ll initially focus on is the indemnification clause, which requires whoever is accessing the resource, if any legal problems or any liability happens, they have to cover any liability or money that ARIN has to pay as damages.

So in terms of dropping the RPA, this is a serious proposal pushed by a number of people in the community. It has some advantages.

If you have no contract at all, it would promote the widest possible distribution of the TAL because it’s very easy to preload it in all the software.

It has some downsides. As we said a minute ago, it does create uncertainty as to whether the contractual terms will be binding. In the absence of contractual terms, you go to general principles of negligence under US law, which are quite uncertain.

It’s hard – they work functionally pretty well, but there is overhanging risk and uncertainty that exists that is greater than under contract law.

And the nice thing, we usually handle these things is through some sort of warranties in the contract. You represent what the product does, and you can actually allocate risk explicitly instead of after the fact by a court.

And this does take into fact that the US environment is much more litigious than other environments, and that partly explains the differences in policy.

The other alternative that I’ll talk about briefly is it is conceivable that ARIN could keep the existing RPA unchanged with blanket indemnification.

Our analysis suggests that that would be inappropriate, because if you – if you as a relying party are forced to indemnify ARIN against any liability, any problems that come up, that could include indemnifying them against problems that fell within ARIN’s responsibility.

And a general principle here is everyone should be responsible for the things they control. You should not be held responsible for things outside of your control.

And to ARIN’s credit, I think in our conversations with them, they’ve recognized that they probably need to – they’re open to rethinking this provision and it is part of their active discussions to try to find out exactly how that provision and that liability should be reallocated.

And there’s where the devil in the details come, when we start to change that, finding that proper allocation becomes much more difficult.

The other alternative is to keep the RPA but instead of an indemnification where the relying parties agree to compensate ARIN for its liability. The way we handle it in many areas of software is you sell the software as is, like you sell a used car. No warranties. You make no representations, and everyone understands they take it on their own risk.

This is how we do open source. It’s how we do a large number of software distributions of different kinds.

And in fact we did this partly by comparing it to the policies of the other RIRs in addition to other types of software and to see how it’s fared under those regimes.

And the other possibility that we talked about in the community is, if you download the validator software from RIPE, who is the primary provider of this now – although there’s another one by Dragon Software that’s not really properly supported at this time – it’s interesting, generally you’re going to have to click through some form of acceptance of that software.

You can also configure that so that you’re accepting the ARIN TAL contract at the same time. And this is a functionality which ARIN has already agreed to change its policies to support, and I think to much of the credit of the organization and how this discourse has gone.

But that would allow them to get the acceptance of the contract done. The question is what are the terms of the contract are you accepting, and can we shift from an indemnification clause to an as-is disclaimer of warranties.

So we did a very – an analysis comparing ARIN’s policies to the other RIRs. ARIN does include a disclaimer of warranties, but they also include a provision requiring relying parties to indemnify it against any losses, but also giving them a duty to defend and hold harmless, which means that they have to pay for the lawyers and litigate – the relying party has to litigate through it.

And it also applies to actions taken by not only the relying party but downstream users of the relying party who were actually not part of this contract.

I understand the reasons why this was put in, but if you compare it to the others, APNIC – if you look at all the others, they have no explicit agreement.

If you look at AFRINIC and LACNIC at the back, they actually have no relevant terms and conditions whatsoever. RIPE NCC has a disclaimer of warranties but no mention of any indemnification or hold harmless or duty to defend.

And APNIC has no agreement, but their term indemnifications do mention indemnification but do not talk about a duty to defend or hold harmless.

So ARIN does have policies or contractual terms here that differ somewhat from the existing RIRs, and they differ in the fact that they have an RPA.

So this led us to really seriously consider the approach taken in RIPE where they’re actually seeing broader scale distribution of whether a disclaimer of warranties would be sufficient to protect ARIN from liability, in much the same way ARIN seeks to do based on the indemnification clause.

So as-is disclaimers are widely used. It would – I think – would be a fairly good defense against liability for ARIN, because if you sell something as-is, you can’t go back and go after them to say, well, it didn’t function properly.

There’s an interesting question, though, I think. There’s somewhat, I would think, procedural risk. There are ways to get rid of cases very, very early in the proceedings. There’s sometimes you can get them later but before trial, and sometimes you have to go all the way to trial.

An as-is disclaimer would probably require ARIN to go through at least to the middle step of litigation most likely instead of getting rid of things at the very beginning, which does create not so much overall liability risk, but some litigation costs inherent in shifting from a disclaimer – from an indemnification clause to an as-is disclaimer of warranties.

There’s an interesting thing that we studied, which is to try to see has there been litigation against RIPE under its as-is disclaimer. Has there been litigation under other forms of security based on – that are governed by as-is disclaimers.

And the answer is there really are no cases. This is sort of a wonderful Rorschach test that you can make of this as you will. Some people would say that the risks are – this tells you the risks are low. Other people would say the risks are unquantifiable because we don’t actually have evidence of how these would come out.

I think that deciding things in the face of uncertainty is something this community will have to directly confront in thinking about how the benefits of deploying – of simplifying the deployment of RPKI against this data we have here which shows that the risk is going to be hard to quantify and hard to understand. And the question is what the significance of the lack of cases really is.

I will note that the RSA does include an indemnification clause, and there is always the caveat that past performance does not predict future results, in the sense that this information is – it’s the best information we have about the future, but there’s always possibilities that things are going to vary.

There is another radical solution to limiting ARIN’s liability here, which would be to stand up a new company or a new organization that would hold the RPKI certificates and be responsible for maintaining the library.

There is a debate about whether this would be just for the ARIN region. It could possibly include other RIRs or other NICs that are doing this sort of registration.

And there are precedents of standing up organizations of this in the past. There are a number of pros. It would in fact make it more acceptable for this organization to take on risks and be able to carry it on for the community.

And in fact they would be entirely focused on RPKI implementation and deployment as opposed to the many responsibilities that ARIN bears.

There is some history here against setting up certainly a worldwide organization. I always think that there’s nothing more revolting than to say we had that fight 20 years ago. It’s a very different world, as we all know now. That’s a conversation worth having again.

But the more serious question is standing up an organization require membership, it requires a certain amount of support, it requires organizational support beyond financial.

You would have to have a Board and some governance. I always envisioned this would be organized satellite meetings like ARIN in the beginning, but at some point it would have to have its own way to figure out what its destiny would be.

There are actually other ways to facilitate risk management, the first I mentioned about making people click through when they load the validator software into accepting the ARIN TAL. There’s another thing that we’re discussing, which is individual contracts don’t need to be signed for every individual instance you’re actually setting up.

And one of the things that – the concern that we got from some of the open source community is they want to be able to just deploy instances automatically.

As it turns out, you don’t need a contract every time you put a new build in. If it’s – an enterprise as a whole has agreed to it, basically if you think about it as a site license basis, you do not need individual acceptances. We were thinking about ways to facilitate that sort of agreement to make that work.

And in fact, there’s some things that the RPA could include inside such as making sure that liability does not include things we call consequential damages. So, if your phone call fails and you’re paying, whatever, $50 a month for service, the worst you’re out, I’ll pay you back the 50 bucks; I didn’t give you the service.

You’re not liable for the deal that fell through because the phone call fell typically in the telecom space. Those are called consequential damages. They’re almost never honored.

Putting that explicitly in the contract would be an effective way to shed liability. But our hope is really to stimulate a much broader conversation in the ARIN and the larger RIR community about the right way to handle this and the right way to manage risk, because I think there’s more than one reasonable option.

We have, you’ll see in the report, a belief leaning towards one particular set of options. But it’s something that we’re open to considering all possibilities.

There’s some other minor points – or not minor points, but other aspects. One is ARIN’s RPA continued something called the prohibited conduct clause. It forbids the sharing of RPKI information or information derived by RPKI in a machine-readable format.

Anyone who has deployed security knows that – looking at other organizations, other – four other – three other RIRs have no provision. RIPE prohibits marketing/advertising the use of this for those types of purposes.

What we’ve learned is that you need reporting and research anytime you look at new security, and that’s best done in machine-readable format. And ARIN has already agreed to modify, to waive that for non-realtime, non-operational uses.

What we’re seeing now is people want to integrate this with IRR data for real-time operational uses.

In fact, no set of information is perfect. And taking multiple sources of information of different provenance, no matter how hard you try, actually would probably make routing better.

We’d like to facilitate that kind of combination in real-time data, but to do that would require some adjustment to the prohibited conduct clause.

There is another way that you can try to get RPA adopted more broadly, but we’re discovering is the primary obstacle is many operators just aren’t demanding this. And until it does – sorry, the customers aren’t demanding that. Until that happens, the operators are less inclined to deploy it.

If security is important to a customer, they can begin including it in their calls for proposals. They can do it into their contractual terms as a requirement. And think about this as a partnership – we want to work with people who are committed to making the security environment safer.

This is not just governments. It can be any private company as well. And in fact, I think it solves sort of the chicken-and-egg problems. And it fits nicely with an initiative being led by ISOC called MANRS, the Mutually Agreed Norms for Routing Security, which includes filtering and refers to RPKI specifically as something that partners should do. And this clearly has 144 participants.

The other thing that we’ve learned in the process very much in dialogue with John is that it is important to understand this isn’t just a legal matter; that, in fact, this is an operational matter that every operator that deploys RPKI has to take into account.

No RPKI cache, nothing even at 5.9, 6.9’s reliability, there’s always going to be a possibility of some downtime. And we’ve seen outages, admittedly brief, in RIPE, in ARIN, and most recently in AFRINIC. And they’re going to happen.

And like any environment you’re in, you need to plan for that and figure out how you’re going to fail over. And there are best practices that make it important to say that if the cache becomes unavailable, you have to fail open, not closed. If you fail closed, you will disconnect part of the Internet.

So there are things that – outages that can happen with misconfigurations on the operator side if they don’t adopt best practices. The RFCs give that guidance. There are people who can provide that information.

And in fact there’s – that’s the application on the operator side. The RIRs will have to take on some additional responsibility, providing clear information about refresh cycles, updates, uptimes, response times, all the things that you need to know to operate how to work with an organization or new service.

And, in fact, we really think there needs to be a dialogue here. And in fact it’s going to put obligations on ARIN to support things beyond what they did before.

The other two small issues we talked about. There is some reports – I mean, government agencies are unable to sign documents that include indemnification clauses and choice of law clauses. ARIN has already indicated its willingness that if there’s a legal requirement that the government agency cannot do that, they will waive those. And that in fact is, I think, a helpful reform that’s already been implemented and, I think, is an example of ARIN’s cooperation.

There is a recommendation, some legacy address holders are unwilling to sign the – can’t get the services they had before when they were legacy holders without signing an LRSA. But if they want additional services, they have to sign.

RPKI is an additional service. And so in fact their objections are to other aspects of the LRSA, not the RPKI aspects.

RIPE has created something called a non-member services agreement that decouples these two issues because the broader issues of the LRSA are independent of RPKI. We’ve suggested to ARIN that they at least consider that.

Although, I will say that I don’t believe that is a complete solution. First, the problem is vanishing as more and more legacy holders look to sell some addresses. They do sign the LRSA.

But the other real market to me is all resource holders signed an RSA to get their IPv6 addresses. We do not see broad-scale RPKI deployment in IPv6 either.

And so what strikes me is that even if you solve this problem, it ultimately would not be a complete solution to the RPKI deployment problems.

So, potential next steps. ARIN should consider RPA changes that we’ve discussed here about the liability provisions under the prohibited conduct clause. This community needs to start a discussion about its interest in supporting a new nonprofit to hold the certificate libraries.

There is a lot of education both on the network operator side and the RIR side about best practices and how to deploy this properly. But in fact this is a – and the last thing is I think this is a change that’s coming, increasingly significant partners are getting involved.

I think that it’s been around for a few years, but it’s time for this community to start engaging with the reality that many of the major partners you deal with are going to start filtering and using, expecting their partners to be deploying RPKI.

Thank you.

John Curran: So at this time I’m going to ask Chris, you can stand or sit, whatever you want. I’m going to give ARIN’s presentation, and because it might answer some of the other questions and save us time, and then we’ll take questions jointly at the end.

RPKI service risk analysis. This is an ongoing document. As we learn more, we update it, but I want to give a high-level overview.

I have to talk about what’s the risk we’re managing, because to some extent, when we talk about the legal terminologies, it’s all about making sure the right thing happens when the wrong thing happens.

And so we have to talk about what’s the worst case. What could happen if ARIN services are unavailable? How do we protect the organization from being held by – inappropriately being held for damages that aren’t necessarily our cause?

And so I’m going to talk about that, including the potential for inadvertent service providers creating dependency on our service. And I’m going to talk about the ongoing analysis framework we’re using for looking at the risks.

This is based on the Board’s direction to me after looking at the UPENN report, and talking about what we need to explore – legal, contractual operations, operational options – to try to figure out can we evolve to something that addresses some of these concerns without creating undo exposure.

And I’ll talk about where we could potentially come out at the end.

So, I think Chris covered a lot of this. I’m not going to go through it in detail. But RPKI allows a second – it’s a second service, an optional service that allows resource holders to declare which networks can actually announce routes for them.

And this is done through ROAs published by those who are address holders. And the act of listening to those ROAs is route validation, ROV.

And the fact is that, the way it’s set up, when you’re doing route validation, if you lose access to this information, it shouldn’t be a problem. You should fall back to the routing that you’re doing today without route validation. That’s the theory.

And that’s actually specified in the IETF operational guidelines for RPKI. RPKI protects customers with published ROAs from having people inject routes that don’t match the listed information.

And it doesn’t provide any – it shouldn’t provide any impact. If that service is unavailable, well, then you’re not protected from route hijacking, but the loss of the service shouldn’t impact your network; you should be exactly where you are today.

We call the people who rely on our information to do route validation relying parties, terminology in PKI. And we actually provide the information in our repository encrypted, as everyone else does. You access it via an encryption key called a TAL, a Trust Anchor Locator.

And we found an interesting problem, which is what Chris was talking about earlier. In order to make sure we had an agreement with the people using this data, we have to be able to show that they’re aware that there are terms and conditions.

We originally started out with something very onerous; you typed in your email and you clicked “I accept the terms,” and we mail you a link and then you take that link and click on it.

We evolved over time to the acceptance on a webpage where you click on it and you download the TAL that lets you get access to this information.

Now we just say download the TAL. After a lot of analysis legally, we’ve gone through three iterations, and we’re at the point now where all you need to do is, when you’re installing your software, go out, take ARIN’s TAL – all the packages direct you to the page; it says here’s ARIN’s Trust Anchor Locator, which will give you access to its repository – download it.

And we say on the page, prominently in the line of sight: If you download this, you’re agreeing to our Relying Party Agreement.

That’s unique to ARIN. The other four RIRs actually provide you access to their repository without you consciously doing anything, as was highlighted in the earlier presentation.

US law is pretty clear. You don’t get bound to agreements that you don’t have some way of knowing that you’re entering into. So we have to do it differently if indeed we want an agreement.

And that turns out to be an issue. Some people object because it’s an extra step. Literally you can’t take the software and say launch, build, done. I actually have to go get this document and do that conscious acceptance.

Reality is that the act of actually safely paying attention to this information and inserting it into your route determination in your network is a technical task and it’s not trivial. It’s going to take people work. It’s going to take people hours of planning and work to do correctly if they don’t want to get shot in the foot.

And so to that extent, even if it’s only an hour, the act of getting one file is not a technical hurdle. It is a hurdle to automation because, again, inherently automated software installation is incompatible with your knowing acceptance unless you’re aware that running the whole package makes you bound to terms and conditions.

So, we have a pretty hard conflict here. If we want to have an agreement, then we pretty much have to have a way for someone to consciously get the TAL. And that’s a pretty hard situation.

Note that the reason we need an agreement – the reason when we rolled out our services, we said, yes, we’ll have a Relying Party Agreement, not to say that we’re unique in that. Other RIRs put terms and conditions on the relying parties; you just don’t see them.

You’ve already agreed to them because you’re using their RPKI data; they’re just not in the United States. So they put it on their website and you’re in theory bound to it, depending on that law and jurisdiction.

So, for example, RIPE has terms and conditions that limit the damages you can claim against RIPE. That’s what we were worried about with ARIN, but again the different legal regime says we need a more clear contract acceptance.

The concern we have is that RPKI is complicated. And we already have people out there using RPKI to announce ROAs for their network. They’re announcing information about which ASes are acceptable based on their network prefixes. And we already have misconfiguration.

You can go out there and look and see a number of announcements which are invalid based on – because RPKI has some interesting length issues with match. RPKI has some other issues in terms of complexity of setup.

So we have people using this information on the publishing side who are already making configuration problems. We don’t know if someone on the relying side is going to fail open, as was discussed.

If our service goes unavailable, we honestly don’t know if every network will fall back to pre-RPKI routing. That’s what they should do. But even if a small percentage of them don’t, we’ll be in a world of hurt.

So let’s talk about the world where we’re successful with RPKI, okay. If we’re in a situation where we have global RPKI adoption, 30 to 50,000 networks are looking at our information and validating routes.

Based on the error rate of configuration we see on the publication side, based on the error rate we see on other issues, like when they did the DNS key rollover, the first time they went and looked at who didn’t have the new key, numbers like 2 percent are quite reasonable. 2 percent of 50,000 providers is a big number.

We could have hundreds of service providers who fail to do appropriate validation when we fail. Now, again, IETF says best practice you should – if you can’t validate the RPKI information, you can’t get to the repository, you should go to not found, and that shouldn’t be a problem.

But, again, even if 2 percent of people misconfigure that and drop those routes, that means that you could have a hundred, 500 providers who lose North America because ARIN’s RPKI CA is off the air.

Now, there is some issues, which is that if our RPA CA goes off the air, it doesn’t happen immediately. People have cached this. There’s timers that apply. They’ll go back and refresh. It’s only when they go back and they’re getting to the expiration that they really have to be able to reach us.

Even if we’re off the air for whatever reason and even though service providers should fall back appropriately, it’s not a knife edge. It’s not like the 200 or 300 misconfiguring providers, when RPKI is fully deployed, they’re the ones that are suddenly going to disappear. They’re going to disappear a few every hour for the next few days until we get our service back online.

Now, you’d say, good answer, John. Don’t get your RPKI service offline. Just have one that runs reliably.

We all try to do that. But so far RIPE’s had an outage; we’ve had an outage. And I can say this week, AFRINIC’s had an outage. So you have to expect the fact that this is going to happen.

But what we don’t want to do is we don’t want to add a service to ARIN that makes the Internet more secure but actually creates fragility for ARIN and the organization and endangers the registry as a whole.

That shouldn’t happen, but we’re not in other legal regimes. We’re in the United States. There’s a bit of litigation in the United States. People like to sue.

And so the issues we face are somewhat different because if we have an outage and there’s several hundred providers, because RPKI is being paid attention by 40,000 providers, and there’s a couple of hundred that can’t get to North America, yes, we will face the question of why we went down and what is the consequences of that.

Now, again, every one of these parties, every one of them has made a mistake. They shouldn’t have a dependency on RPKI data. They should not. They absolutely should not.

They have what we call unclean hands. They don’t have the right to complain about our service being down because it shouldn’t matter to them.

But I would have to talk to a jury about the technical responsibilities of the people trying to sue and talk to them about how their routing configuration wasn’t right.

Now, you understand now, I’ve got 12 random people off the street, which I’m now talking about route waiting to and RPKI states of invalid and found and not found. It’s going to be a great time, okay?

And if I have to do that a couple hundred times, oh, I’m going to have a great adventure.

So what we do is we have a contract that provides for indemnification. When someone comes to us and says, We’re going to litigate with you because you were down, we go, You’re not because you actually agreed to cover the expenses, the liabilities associated with your use of our service.

If you suffered damages or someone else suffered damages because of your usage, you’re the one responsible. We put the responsibility on the people using the service, because it really is their responsibility. All the legal agreements do is say that.

Okay. So this is what we’re dealing with is that we could have a very significant issue if we go down when RPKI is well-deployed worldwide.

And despite the fact that it’s not our issue, because there shouldn’t be a dependency, it could be a very significant – again, for ARIN financially, it could actually endanger the entire organization.

We do what we can with the agreements to prevent us from being inappropriately held by someone misusing and misconfiguring this data.

Now, here’s the issue: We have to look carefully at how we can mitigate this. And our past solution works great. Actually it’s wonderful. We have a Relying Party Agreement which we know we can say anyone using the data has agreed to because they couldn’t have gotten our TAL. You’re not allowed to redistribute our TAL or embed it in software.

Everyone who is using our data I know has agreed to the RPKI Relying Party Agreement, and every one of them has indemnified us. And we sleep well at ARIN. Okay, we sleep well at night, but as Christopher’s report says, it could be impacting RPKI deployment.

So, what are we doing? We are looking at all the options from mitigation to see: Can we put together a tapestry of solutions that would allow us to relax our approach.

The Board’s directed myself and our general counsel, Steve Ryan, to do this. We started this process. The report came out at the end of last year. We started this process after meeting with the Board in January.

There’s going to be an ongoing thing. It’s going to take – took a year to put the report together. It’s probably going to take us a similar amount of time to run down all these ends.

We have made some incremental improvements on the way. I want to talk about some of the risk strategies we’re looking at.

So one of them is that all of our ARIN customers actually don’t need, per se, a separate RPA, a separate acceptance, because they are bound to the RPA because it’s the service agreement terms and conditions.

When you say you use an ARIN service, if you already have an RSA with us, then by reference the terms of that service you’ve agreed to, including indemnification.

So everybody in North America who is our customer with an RSA, the 6,000 members and another 15,000 end users who have an RSA or LRSA, they’re already bound by this agreement, even if they don’t take an explicit step.

And that actually means the parties who might be misusing the data and wanting to litigate, we don’t have to worry about that center spot.

And that removes some – some – of the parties that we might have to look at if we’re going to relax our measures. Luckily, what we do for relaxing our measures doesn’t actually change our status with respect to the big part of North America.

And that’s good because many of the people who want to litigate us are people in North America and may have address space. So even if we change the RPA or change how we do the agreement, these folks already have an agreement indemnifying ARIN for the services we provide.

It’s possible we can rely on the RSA and its terms, and that gives us some leeway because, if you think about it as a donut, the North American hole in the middle has been carved out.

If you’re an address holder, you’re probably not someone who can successfully litigate because of the RSA that you already have.

So that we need to consider further. That allows us a little wiggle room, but it doesn’t handle multinational companies that have address space elsewhere. It doesn’t handle large organizations internationally that don’t have number resources from ARIN. It’s not a silver bullet, but it does reduce the number of parties that we have to think about.

Relying parties, as we said, the situation we face presently is that the risk mitigations require that we look and try to have a balance in the Relying Party Agreement.

Right now we have a very complete Relying Party Agreement that includes limitations of damages and disclaimers and indemnification.

It may be that’s overly robust. There are some folks who have looked and said, I can live with this except I don’t like indemnification.

It’s interesting, some of those people have signed an RSA that contains indemnification. So I have to scratch my head and go, well, you already did that, but that’s okay. Let’s take it on good faith. Some people have a problem with an indemnification clause who may be able to move forward if we took that out of the RPA.

So some of the things we’re looking at. We’re almost certainly going to strengthen and make sure our existing RSA terms handle the ARIN region relying parties resources.

It’s possible we can look at something like insurance. It is possible to get insurance, particularly in a case where you go and explain this is insurance to handle the case of the litigation expenses.

Now, there’s two problems with this, and I just want to be very blunt. We actually have insurance now that covers some of this. And when you try to get insurance, you have to explain in detail the scenario you’re insuring against, the same relying party and route filtering and someone misusing the data, which means you have to find an insurance agent who – an underwriter who is actually capable of understanding this.

I actually have better luck with the 12 jurors, by the way, because random people off the street might be better than those insurance people. Really sorry about that. Sorry if you’re in that field.

We have actually done a lot of insurance work. We actually have reviewed our policies – a few years ago we did an extensive review. We actually know how to use our policies. We’ve made claims and realize that even when insurers say, Okay, you are covered, they say, You are covered to…we think, right now, from what we can tell, but here’s three pages of why you might not be covered if we learn more later.

So insurance isn’t a silver bullet because even when they say, Yes, we’ll cover you, it’s, We’ll cover you with these exceptions. So we’ll look at that. May not go a lot of places.

Operational failure testing. The best way to make sure no one has a dependency that’s inappropriately configured, improperly configured on the ARIN repository, is to take the repository down every now and then.

And the people who are impacted will go, “What did you do?” We’re like, “We took it down so you shouldn’t have an impact. If you had an impact, you did something wrong.”

We can minimize the risk associated with our repository being down by proactively taking it down and letting people correct the problems. And this actually makes RPKI more reliable because it means when it’s up, everyone’s appropriately configured. You don’t have people who have these misconfigurations.

Downside. You announce a date where you’re going to take down RPKI repository, you might as well send it to certain hacker mailing lists and say, Hey, we’re leaving the Internet unprotected for these four hours Sunday. Do your route hijacks in this window.

So you may not be able to take it down in a way that you announce in advance. And if you don’t do it in advance, how do you do justice to your customers, because you’re like, Oh, we want to take it down, but I can’t give you a warning because if I do, I’m warning the bad guys that you’re exposed. Some fuzziness we may have to work out on that.

And then of course the other suggestions, separate RPKI services affiliate.

I’m not going to go through these in more detail because we’d be here all day. But, as I said, we’re going to rely on the RSA for ARIN region parties, make sure legally that’s all ticked and tied. We’ll look at the insurance issue, but it’s complicated.

We’re going to look at operational failure testing. We’re going to look at timers. We have timers in our repository and we have timers in our underlying PKI infrastructure. We need to look at those, see what they are and what makes sense.

So possible outcomes. Let’s talk about some of them. One of the other outcomes we’re being asked to look at is reduced indemnification clause. We’ll look at that.

Indemnification allows you to, very early, the possibility of saying the party trying to litigate ARIN and hurt ARIN for its harm isn’t an appropriate party. They don’t have standing because they have indemnified us.

And you can do that before early in this legal process, if I understand it correctly. So the good news there is that that allows you to preemptively do something.

Without that, you could end up going through a lengthy trial, even – as I said, even if it’s not our fault, it’s their fault – just to get to the end to be able to show that your contract and your damage and limitations apply.

So we like indemnification because it provides a very clear first opportunity to take someone who is litigating against us based on their misuse of the data and remove it. Giving it up definitely will cause increased costs if we ever have to defend one of these.

On the other hand, it’s a tradeoff. It’s the type of tradeoff that I have to look at, counsel has to look at. We have to come to a recommendation, give it to the Board. And the Board ultimately has to make a call, what’s best for you because you elected them for that.

It’s one of those heavy Board decision matters where – the weighty work of the Board is making decisions like this.

A revised RPA. We’ll look at some other aspects of the RPA. As I said, looking at disclaimer and limitation in liability. If we have an RPA, we really need to have some sort of protection.

So we might be able to look at indemnification. I don’t know if that’s going to work out. But we would still end up with some disclaimers and limitations in there because we have to. We don’t want to endanger the organization.

We’ve been told to provide access without any RPA. I’m not sure this is responsible. It increases our legal risk materially. We are going to look at it. We’re going to actually formally advise the Board, is what it comes out to.

But for people who say we’re going to get rid of an RPA, or we’re going to have an RPA that you don’t have to accept – which is the same thing, effectively, very hard for us to prove an RPA you never saw as binding – it’s almost the same thing if we have an RPA that you don’t accept.

So from that regard, if we don’t have you consciously accept it or we have none at all, we’re in a big opening. And I’m not sure we can do anything. We might be able to look at the language in it.

It’s possible, looking at the full balance – insurance, relying on the RSA for the people in this region – we might be able to look at this, but it’s going to be a very difficult call in terms of risk management.

So that’s where we are, looking at the full suite and the response. Chris is here. You can stand there. Questions? We’ve got to allow a couple minutes for questions. We’re out of time, but this is a very important topic. So let’s get it out now.

Front and center.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC, and most importantly not a lawyer. I can download CentOS, Debian, any number of free operating systems and install them.

Somewhere in that distribution there is a copy of the GPL. On the download page, there might be a link to the GPL. At no point am I required to read and acknowledge the GPL or whatever licenses.

I can think of a number of other examples. I can download web browsers and run them without having to click through a license agreement.

ISC BIND has a list of route server IPs that I’m not acknowledged to disclaim any liability if one of those gets changed to the address of a malware server.

I’m really curious what is unique about the TAL that other examples of these types of freely available software information –

John Curran: Let’s break this down because it’s pretty simple. You’re talking about software usage, GPL. You get software, you use it. Software licenses are well recognized.

Our repository is not software. Our repository is an information service.

So from that respect, when you go and get those software packages and install them, you’re using the software under the license terms and that’s well accepted.

If you’re using services like a DNS root zone or you’re using a certificate for SSL certificate, if you’re using those services, it’s up to those organizations to decide what terms they offer their services to you – as-is, with no agreement, with an agreement.

So you have to ask them why that’s a reasonable risk strategy. It’s not that we’re unique. It’s that we’re actually thorough and we’re looking at managing ARIN’s risk. I don’t know – you’d have to ask ICANN what they have as risk management.

Some of these organizations are unique and colorful and may have interesting strategies for how they manage the risk. But it’s really a question not of what’s different in this regard; it’s go ask them why that’s not necessary.

Chris Woodfield: Right, and that’s exactly my suggestion. This appears to be a problem that other organizations have dealt with some way or another. Is it possible to accept those lessons?

I’m talking about software, but a lot of these software have services behind them. I download Google Chrome, I’m going to be hitting a CRL list. Is there no liability if Google puts a –

John Curran: The high-level answer to your question is for the unique case, like the DNS root zone, it’s a historical artifact. And there are actually contracts that involve parties that – like the US government involved in publication – that they may have a solution, but it’s a solution that would not necessarily be reproducible. It may be, by the way, when we talk about a separate entity, that might be a way to reproduce solutions there.

In the case of things like SSL certs, the question is you’ve got a lot of SSL cert providers, if one goes down, it’s not the end of the Internet.

Loss of an RIR for an entire area, North America is a very large coverage area. So whether or not a particular SSL provider goes out of business – and we’ve had that happen – is up to each SSL provider’s decision.

But for the unique one, like the root zone, it’s not that – it’s not that we haven’t talked to them, it’s that you have to recognize it’s so unique we’d have to reproduce it probably by the separate affiliate option.

Chris, do you want to comment?

Christopher Yoo: To give you the lawyer’s answer, software is different. It’s protected by copyright. Copyright creates rights that are good against the world even if no one signs anything.

Why don’t we ask ICANN how they do it? We did. And it’s in the report. Both me and David Wishnick, who is here at the front, are happy to talk about the details of that. But our general take is their solution probably doesn’t provide a solution path for ARIN.

John Curran: Next microphone. Go ahead.

Joe Provo: Also not a lawyer, Joe Provo, Google, ARIN AC, legacy resource holder, random cantankerous hijack hunter, just speaking for myself.

I just wish to urge continued pursuit of angles to allow us to drop the RPA. I don’t think a new Org would necessarily be the right thing, because the T in TAL is for “Trust,” and I’m not sure how we reestablish that in a brand-new stood-up thing, in addition to all the other issues you identified.

With my service provider hat on, I like RPKI for provisioning, not even just the ongoing route validation, but preventing the LOA-based hijack is a good thing.

And in the BYOP cloud universe, we’re going to see it come back in force. We’re already seeing policies in this sphere being proposed to bleed resources away because of the lack of TAL adoption.

I understand ARIN wishes to continue to exist and to service its customers, but if all the customers go away, what happens?

And I understand we have really good lawyers. So hopefully we won’t ever actually go to trial, but we’d actually prevent that situation.

John Curran: Understood. Thank you.

Michael Casadevall: Michael Casadevall, NARALO. I’m also not a lawyer. I want to bring up multiple points.

You actually may have the inverse situations by making access to the TAL difficult. ARIN may actually become liable for creating security issues, because by having part of the RIR infrastructure not there, you’re knowingly creating a situation where security is being weakened for BGP, and that in itself could be cause for liability. So in an attempt to protect yourself from liability, you may actually be creating liability.

Furthermore, I see the TAL much similar to the way root stores operate where Firefox, Microsoft and other browser vendors collect root certificates and distribute them.

And they in themselves are not liable for how the SSL certificates ship, are signed from those various root stores. I mean, essentially you could see the five RIRs as a root certificate and then boil down from there.

While the situation is different with the chain of trust, I would say that the TAL itself is essentially a public key, and I’m not completely convinced that there is a liability issue here.

Now, lawyers may say otherwise, but the final issue is that if we’re going to live in a world where the RPKI servers are not 100 percent reliable and soft failure has to be the default, we’re not doing any better than SSL where relocation is a wonderful word we talk about and doesn’t actually work in practice because the soft failure mechanism.

So are we essentially building a lame duck here; that if we cannot trust that RPKI is going to work and we’re going to soft fail if validation fails, are we actually buying security, or are we buying a feel-good thing? That’s where I want to boil it down to.

John Curran: That last one is probably a question for the IETF since they’re the ones that give it as their best practices for deployment. It’s their document that recommends that.

Center front. Go ahead.

Steve Feldman: Steve Feldman, CBS Interactive. Not a lawyer, but I do have to talk to lawyers whenever I want to buy anything that has a contract associated with it. And that in itself is a process.

So even though, as you pointed out, we already signed the RSA years ago, it took 10, 11 months to convince our lawyers to sign it again when we had to update it for some reason a while back.

We can in fact get an indemnification clause signed if we can convince them that it’s worth it. But that’s hard to do. We have to do that all again if we want to sign the RPA as it is.

For me, in my particular role, it doesn’t make a whole lot of sense to go through that work. It would be easy if it could be covered as part of the RSA, could be easy if there were another way to accomplish it. But as it is, it’s not worth the effort for me. I’m not going to adopt it at this point.

John Curran: Understood. Okay.

I’m going to close the queue, keep going.

Kevin Blumberg: Kevin Blumberg, The Wire. On the light side, I did stay in a Holiday Express last night.

(Laughter.)

On the serious side, ARIN isn’t the dominant RPKI player in the regions. As such, we’re not in a position to make much dictation when it comes to things if we want to see successful deployment of RPKI.

There’s a lot of personalities at play here. A wrap-around click-through should not be a issue. But because we are the nondominant player in this region, in some respects this is personality as to why this is not being used.

There was just a post to the Mailing List. Two RPKI players that turned up in another region specifically excluded ARIN. Not because they consciously wanted to, because they’re making a point. That’s what’s going on right now. And it is devolving.

The most important thing, John, as far as I’m concerned, is this needs to be expedient. And another year is not expedient. So that’s the one thing I did take from a lot of this stuff.

And I am not trying to get into the specifics of it because it is way beyond my pay grade. But it took a year to do your original report. And you said it’s going to take probably another year to get somewhere.

And this is going to devolve. Between the NANOG in October and now, this has already devolved significantly. And another six months or 12 months it’s going to continue to devolve.

All I can suggest to yourself and the Board is expedience, expedience, expedience.

John Curran: I want to respond, to be clear. We’re moving really quickly. We really are. But recognize that the Board has to make this call. This is truly that level decision, and they’re entitled to have good analysis.

Some of these options, we literally – like I said, we just got these reports a few months ago. Some of these options, like separate affiliate, insurance, require detailed work in order to be able to give the Board the answer or the choices and the risks involved in each.

You don’t want to make a half decision while one of those is pending, because one of those options could significantly influence the balance of the scales on how you go.

So I don’t know how long it’s going to take. We’re aggressively doing it. But I do not recommend the Board making decisions with incomplete information. And so it’s just a question of us doing the work as expeditiously as possible.

I want to bring up one more point just to be clear. So we’re actually – we have more parties doing route announcements now, more networks doing it. We are still growing. Not just in terms of percentage, but in terms of count, in terms of objects, and networks covered, we’re actually moving up slowly but surely. We are now No. 3. Used to be No. 5. It’s not a percentage issue, but then we’re also a very large area.

When you say we’re not the dominant player, we see a lot of RPKI activity going on in America, and this – Canada, US and the Caribbean, we see a huge amount of activity.

The slope doesn’t necessarily match other places, but that doesn’t mean it’s not growing even right now.

Kevin Blumberg: No, the issue is that other regions are using what’s going on and turning off ARIN, or not turning it on in the first place, which is not going on elsewhere.

And we are not, by numbers, the number one, right?

John Curran: Sure.

Kevin Blumberg: I’m not asking you to do a poor job. I’m saying throw whatever you can at this because it’s going to get worse fast. Thank you.

John Curran: I actually closed the queues earlier. So everyone after the remote monitor, I’m not sure what you’re doing here. We’re well beyond time.

I said everyone after the remote monitor.

Go ahead, Owen.

Owen DeLong: Owen DeLong, ARIN AC. You talked about announcing an outage ahead of time being a recipe for the hackers.

Couldn’t you have an authenticated list of people that want to be notified that have somehow authenticated themselves as being relying parties and announce only to that list?

John Curran: Could.

Owen DeLong: Thus mostly avoiding notifying the hackers?

John Curran: There are options, and we need to tease these out. That’s a great idea.

Go ahead, Andrew.

Andrew Dul: Remote comment from Jason Schiller, Google, ASO AC: Thank you for this presentation and your continued work to reduce the gap and barriers to usage of RPKI in the ARIN region as compared to the other four.

Please continue this work and increase my fees if that’s what’s needed to make appropriate progress. Can we please get this presentation and updates of this progress at the next NANOG meeting?

John Curran: Next NANOG meeting, understood. If the program committee honors me, sure. Yes.

Joe Provo: My apologies, because even writing down, I forgot something. Joe Provo, Google, ARIN AC, speaking for myself.

In addition to fees, since there were concerns about insurance – and my apologies if it was in the report – have we explored – has the Board explored discussions with the other RIRs for increasing the Joint Stability Fund to cover this sort of eventuality?

John Curran: A Joint Stability Fund is a very small number compared to our organization. If we see a damage that’s order of magnitude a year or two worth of our fees, order of magnitude our reserves, there’s insufficient water and there will never be enough to sustain us.

So unfortunately we would take down the Joint Stability Fund and the other RIRs in the process. That’s really the issue we face, is that the problem is that in a litigation like this, if you face that from several hundred parties, you actually – the uncertainty of the outcome combined with the length and the process to get clear encourages settlement. And even that could be debilitating to our organization.

So I guess the work that we’re most likely to end up, if we do anything with the other RIRs on this jointly, would be look at, for example, maybe there’s joint publication possibilities.

And that’s not unheard of. I’m not sure we’d incur the risk and then share the risk with our RIR brethren. Seems to be rather cruel in a number of ways.

So microphones are closed. Anything from remote? Chris, only one question for you, if you want to say something in closing.

Christopher Yoo: Only that I’ll be around lunch, if there’s other engagement you’d like to do. We’d be open to it because this is a process and a dialogue.

And thank you for allowing us to inform and engage the community.

(Applause.)

John Curran: At this point we have a couple of presentations before break, but I am not cruel. So we are going to take the scheduled break at this time.

And so, folks, go outside, and we’re resuming here promptly at 11:00.

So take your break and I’ll see you back here at 11:00 AM.

(Break from 10:32 AM to 11:00 AM.)

ASO AC Update

John Curran: Welcome back. If everyone would get seated, we’ll get started. We ran a little late because of the active conversation.

We’re going to take the presentations that did not get done before the break and we’re going to resume with them. We’ll have the ASO AC Update and IANA Review Committee Update.

Come on up, Kevin Blumberg.

Kevin Blumberg: Good morning. I’m Kevin Blumberg, the Vice Chair of the ASO AC. I promised John I’d run through it quickly because we lost a lot of time. And the clicker is not clicking.

So you’re going to hear two terms quite consistently: NRO NC, which is the Number Council, and AC.

For laymen, they’re the same thing. We sit on the NRO NC when we’re at RIR meetings. When we’re at ICANN, we’re called the ASO AC from an ICANN perspective, but it is all the same people. They’re interchangeable, by and large, without getting into any complexity.

The ASO AC is made up of 15 people – two are elected by the community, one is appointed, times five regions. So we’re a body of 15 people, two elected and one appointed. I’m actually the appointed person from the ARIN region.

We have a number of observers. We have ICANN staff, we have the ICANN Board members, and we have RIR staff that join us regularly.

The terms of office in the ARIN region are for three years. But they do vary quite significantly between the regions.

What we do: Every once in a while, when it comes to number policy, the ICANN Board will ask us questions. And we’re there for the ICANN Board to be able to provide them with feedback based on information we received from the communities, et cetera.

We select two ICANN Board members, and we’ll talk about that a little bit later. And we do appoint some people as part of our responsibilities under the various agreements that we have between ICANN and the RIRs.

We do select a number of things, like the NomCom within ICANN. We have a monthly call. We have a yearly physical meeting. That just was a couple weeks ago.

Each year we elect a Chair and two Vice Chairs. And the important thing is that the Chair and the Vice Chairs cannot be from the same regions. So we’re very diligent about making sure that there is regional representation among the RIRs in all of the things that we do.

And we have a list of all the members for the different regions. For ARIN, I’ll mention it’s Jason Schiller, Kevin Blumberg and Louie Lee that are the members for that region, for our region.

We also provide participation records. So for 2019 we’ve had four meetings. And as you can see, we keep track. It’s on our website. The link is there. And we feel that this is very important for transparency so that people, especially when it comes down to elections, know what the participation is when it comes to their representatives on the ASO AC.

The ICANN 10 Board seat election just concluded. We had three candidates. One of them withdrew on February 18th. I’ll leave that up there. Just move to the next.

And on March 27th we announced that Maemura Akinori was selected for Seat 10 to serve for another term, as he’s the current Seat 10 selection.

We’ve nominated Brajesh Jain to the NomCom. And just recently I was asked to sit on the Multistakeholder Ethos Awards, which is a small, little ICANN project that awards to somebody who deals with all of the different stakeholder groups within ICANN in a positive way. It’s a three-month sort of thing.

And lastly, I wanted to talk about the ASO review which happened in 2017. On the NRO’s website, there’s a full list of all 18 recommendations and the current status of those recommendations. Many of them have been completed.

The ASO AC is nearing completion on all of the tasks that it was given by both the NRO EC and the direct requests out of the recommendations.

And the two things for this community that are important: One, our Mailing List will become an open archive. So historically the Mailing List has been closed, and really only the announcements list that got used once in a while for global policy would call. But our day-to-day sort of work that goes on will be open, and that’s happening in the next 30 or so days.

And the same with audio conference calls. We’re going to be switching platforms to allow any community member who wants to join in to the audio conference calls to be able to join in, to make it less of a black box in terms of what the ASO AC does.

We’ve got a website. One of the recommendations was to redo the website. That is coming this year. But in the meantime, everything that we do is on the website at aso.icann.org.

If there are any questions? And I’ll be around for the rest of the conference if you do have any questions about the ASO.

Thank you.

(Applause.)

John Curran: Next up, Louie Lee to give the IANA Committee Update.

IANA Review Committee Update

Louie Lee: I’m Louie Lee. This is Louie’s hat. New hat. Whoo. All right. If you want to go back to your email, go ahead. 90 seconds. Go.

This stuff is boring because the IANA operator, as long as the IANA operator is doing what they need to be doing for us, there’s really nothing to get riled up about.

I’ll talk about the formation, the role of the Review Committee, the members, current work status and the transactions that have happened since last update.

A little about the 2018 report. It’s been published. Nothing big going on there. And then a little bit about the community engagement and input. That’s the one you should look up from your emails.

Now, the Review Committee was chartered by the NRO EC, formed a few years ago. This was based on the CRISP recommendations that we have a community group to make sure that the contracted services from IANA to the RIRs are happening and the work is good and they’re staying with the SLA.

The role is spelled out online and shown to you. We had also put this in the preamble of our operating procedures, and the new operating procedures should be posted soon. The link to the current site is below.

Now, who are we? We are 15 members, three from each of the RIRs. Now, in the ARIN region, the two elected members are the same that were elected as the NRO Number Council.

So just a slight change from what you heard from Kevin in that the elected members from the ARIN region for the NRO Number Council also act as Review Committee members.

We have some changes. The ones highlighted in bold are the new members for this year.

So you see Richard Jimmerson listed. He took over the seat for Nate Davis who retired last year.

Current work status. We are still refining our operating procedures and continually seeing what we need to update for the changing environment. We have not all that many changes, but we see some gaps in places like – for instance, we added a process for expedited performance report just so that we can produce a report for out of cycle, in case something happens there where it needs to be done.

We clarified the RC member and community engagement piece to scope it down to just things that are related to IANA services performance to increase communication with the community.

So by the end of this year, we’ll begin to prepare for the report for this 2019.

Since our last update, there has been one reported transaction on the IANA website. This is related to an ASN request, and that has been met with 100 percent reliability, and everything good.

Now, there was one more piece of activity that happened but it’s not yet recorded on the website. This is related to the /22 v6 that was assigned to RIPE back in March.

The 2018 report, yes, has been published, back in March 5th. If you want to read the report and read the full conclusion, the link is right there in my presentation.

Now, the conclusion really is just that there were two v4 allocations, three ASN requests. There were no indications of failure or near failure by IANA under the SLA. No concerns from the communities. And we perceive there had been sufficient community outreach and involvement.

We did receive zero comments during our open comment period. However, two came in after the report was published. They were related to formatting and accessibility. So we will include those comments as improvements in our seeking to improve the report for next year.

So here is where you look up from your email. The community engagement part. We want to make sure that we are still doing what you need us to do. If you read the report and you find that there are questions you have about what activities have been going on, please reach out to us.

We do have the open comment period for when the annual report comes out, and we’re coming to these meetings. We’re online. Please do reach out to us for that.

With that, are there any feedback, observations or questions?

(Applause.)

Thank you very much.

John Curran: We’re now going to have Kevon Swift come up and give the global report, LACNIC.

Global Reports: LACNIC

Kevon Swift: Thank you very much, John. Good morning, everyone. I’m very cognizant of our time so I’ll try to be a bit quick, a bit swift. I have a lot of information on these slides. But, please, if I gloss over something, feel free to approach me at any time. If you would like more information, I’ll be happy to help you out and point you towards further details on what I’m about to present.

So today’s presentation is going to focus on three topics. We’re going to talk about excellence in Internet number resource management, covering some of the results from our Customer Satisfaction Survey, we’re going to talk about our resource administration platform, Mi LACNIC.

Also going to touch about our continued strengthening of a secure, stable and open, continuously growing Internet – what we’re doing in terms of security, stability and resilience, IPv6 deployment and our training activities.

And last but not least, I’m going to talk about some of the community things we’re doing to promote that inclusive, bottom-up Internet governance model.

Moving right along. So what we saw here in 2018 is that we stand at a current rate of 90 percent satisfaction from our members. That has been quite consistent over the years, as you’ll see between 2014 and 2016. And of that 92 percent it’s actually about 68 percent are actually very satisfied with our services. So we do get this favorable feedback from our membership.

Our membership. We are now at 9,000 members. And what is interesting to note is that a lot of that growth is attributed to two main categories that have been opened up since 2017.

You’ll see them right there at the bottom of the list. They’re the Nano and Micro categories. And Nano and Micro categories are really for those very small entities requesting anywhere around a /20 or /22 resource space.

So we have seen thousands of those grown over the last couple of years. And one of the reasons why, as you may be well aware, given the current policy that we have for exhaustion, which is our new members policy, or some of you may know it as our new entrants policy, existing members can no longer get v4 space from us. We only give fixed allocations of either a /22 or /24 to new entities.

And as a result, you do find that a lot of huge corporate customers are deciding not to rely on their main service provider and come to us to become members directly. So that accounts for all the thousands of Micro and Nano providers at this point.

The current pool is about 2.3 million addresses. That includes about 1.3 from the free aggregate pool plus 1 million in terms of revoked and returned addresses.

And initially we had anticipated that we would have enough resources, v4 resources, to run from 2017 straight up to about 2022. And at that point we will have absolute exhaustion.

But at the current rate at which the Nano and Micro members are growing, we foresee that we’ll be completely out of v4 resources by mid 2020, by August 2020. That’s the new projection, and that’s because of that growth we’re having in our membership scheme.

Resource transfers. So there was the implementation of the policy, the change to Policy 2.3.2.18, a policy that is well known. It deals with allowing intra-regional transfers outside of mergers and acquisitions. And I would say quite honestly in the LACNIC region we haven’t had as much – we’ve had an insignificant amount compared to the ARIN region.

One of the things that we do to support those transfers, to support this secondary market is that we have a listing service available for all members.

And this listing service you can either sign up either as a buyer or seller or an intermediary that can serve as escrow for any of these transactions.

So 33 transfers over the last two years, not a lot. But it is something that we have. And, of course, we are going to see at the upcoming LACNIC meeting more discussions about inter-regional transfers and, of course, conformity with the three RIRs that do allow this.

With our Board of Directors, we’ve had re-election of one of our directors, Mr. Alejandro Guzman, who is in the audience. And we have also had for the first time the election of two new directors, Esteban Lescano from Argentina and Evandro Varonil Brazil.

Mi LACNIC is the resource administration platform that I referred to earlier. And it’s really an in-house solution that we developed. It shows a lot of information, well, various information that are relevant to our members – IP/ASN, reverse DNS, account statements, et cetera.

It also hosts the listing service, and it gives information on our training and events. So it’s really a one-stop shop that we’ve created to really just facilitate that members experience that we have within the LACNIC region.

Strengthening security stability and resilience. So a lot of outreach being done on resource certification. As some of you may be aware, there’s a project at LACNIC called +Raíces. And +Raíces is basically a facilitation service to allow for the implementation of copies of DNS root servers.

So in 2018 we’ve had five such applications for the +Raíces program. And the latest two are Monterrey, Mexico, with an installation of an I-root server, and Panama City with the K-root.

In terms of the ASNs, the visible ASNs in our region, 7,868, we see about 40.65 percent announcing v6 traffic, which tends to be one of the highest of the regions. And these are the real movers and shakers in terms of the IPv6 economies in our region.

We have Uruguay standing on top with 34 percent with respect to their total Internet traffic; Brazil is closely behind; Mexico; T&T; Ecuador; Saint Martin, the Dutch side; and then others like Peru, which has been there for a long time but they’re a bit – their growth seems to be flattening out a bit or remaining constant, or stagnant somewhat.

Argentina, Bolivia, Guatemala, between 5 and 7 percent. And then slightly over 1 percent, Dominican Republic and Belize.

And some of the interesting things about this information is that just one or two years ago half of these countries were not on the list. We only had about four prominent movers and shakers, which would have been Brazil, Peru, Argentina and Ecuador – sorry, and Trinidad and Tobago.

And many times it could be attributed to the actions of a dominant operator in the country. In other instances, we’ve seen where things such as IPv6 task forces have been really, really relevant to getting people on board doing standardization and informing the – your stakeholders, your digital entrepreneurs as to the importance of deploying v6.

Online training. We have webinars. We have reached up to 4,871 people through our webinars last year. You can see here the variety of subjects that we discussed, the most popular, of course, being IPv6.

And we also have from our online training platform 1,517 people being trained on IPv6 and 496 on BGP.

So our online training platform, our LACNIC campus, we offer three types of courses – basic IPv6, advanced IPv6, and BGP RPKI. We’ve seen a significant amount of growth, about 10 percent, compared to 2017 in the use of the online campus.

And I should not be saying this, I’m sorry, Gianina, we’ll soon be offering our IPv6 basic course in English just to make sure we reach our entire membership and just reach out as much as possible everyone who needs to have this information.

And why is it important? Because it’s a well-known fact that LACNIC members, some of the record-makers in the world for having both v4 and v6, about 92 percent, but what we realized is that despite the availability of IPv6, many members were slow to implement it.

And looking at statistics, it doesn’t give you a fair assessment as to what really is happening. So for that reason we decided to take it at a national community approach, national technical communities, and identify who were the decision-makers within each community responsible for promoting v6 adoption.

And with that in mind, we started conducting these IPv6 for Decision-Makers visits. They’re high-level visits involving our CEO, Oscar, and other CEOs and other decision-makers in other countries.

We typically tend to target ITT ministries, regulators, ITT associations, IXPs, large operators. Those are the types of stakeholders who we reach out to. And we try to create this very intimate space where we can ask them and have them ask in confidence some of the questions that may seem silly at times.

But it’s really about creating this intimate space for them where they can ask in confidence some of the questions they have about v6 deployment.

A lot of things tend to focus on training opportunities and knowing how to operate in a v6 world, how to move away from scarcity management. But we have found this to be very useful.

So, 2018, we went to four countries – Guatemala, El Salvador, Belize and Honduras – and we intend to continue this type of engagement, talking about v6 for decision-makers.

One of the things that is in here is that we also have from my department, the Strategic Relations Department, a lot of requests from public entities wanting to know what is the best way they can talk about v6 deployment within public administration.

Many times they’re coming up with Public Policies, directives, et cetera. One of the biggest messages that we have for them is that you cannot force v6 deployment among ISPs, but where there is control within public administration, where you do have operators of public infrastructure, we do have a couple of recommendations that they can use.

And thus far we have been engaged by a lot of regulators and ministries across the region, and we do provide that sort of feedback and input for that.

Routing Security Project. Recently through the Open Technology Fund we have a project between LACNIC and NIC Mexico, and this project deals with RPKI validation. As it stands, LACNIC relies on RPKI validation from RIPE.

There is one exchange point in the region. That’s the map of Ecuador. That does RPKI validation but is not something that is quite common as yet. But we hoped to see this really take off soon.

FRIDA, the Regional Fund for Digital Innovation in Latin America and the Caribbean. Last year our FRIDA fund had two special categories in mind. We were looking at closing the digital gap through community networks, something that we’ve been doing in partnership with Internet Society, and we are also looking at closing the gender divide in technology, which relates to a host of other issues that we see across the region and is showing that there’s fair and equitable access to technology use and creation across Latin America and the Caribbean.

So FRIDA is about awards, grants, subventions, and scale-ups for existing ideas. What you see here are the FRIDA awardees from last year. For community networks, we have awardees from Argentina; community networks established in Brazil and Colombia.

And in terms of the gender divide, we have Wikimedia looking at removing bias in Wikipedia content. So it deals with eliminating machismo influences that you find on public information and increasing the presence of more female editors for Wikimedia content across the region.

And we also have an initiative from the University of the Republic of Uruguay for encouraging women in careers in technology and other grants in Chilé and Colombia.

Ayitic Goes Global is our flash initiative in Haiti. It is the successor to our first project in Haiti called Ayitic, where we are trying to show off the skills of the Haitian community. We go in and we ask the community what are their real needs. And we initially trained the community in topics regarding v6 deployment, Internet security, wireless networks, network management in general and the like.

So with Ayitic Goes Global, we decided that we are going to change the direction slightly. We’re still going to work with the Haitian technical community, but we’ve identified another key target audience that can benefit from some form of intervention.

And this target audience deals with women and girls, school-leaving girls from Haiti who have limited choices and options in terms of being employed.

What we’re doing is that we are training up to 300 young women and girls in data processing and related topics so that eventually they’ll be able to support business operations remotely for companies founded in Haitian diaspora. Most of them we have identified tend to be in North America, in France and in other regions.

So the goal is 300 women and girls being trained in addition to about 150 Haitian technicians that will work on the infrastructure issues.

We have encouraged the creation of a cluster, where they identify security issues and small mini projects. They can work on resilience of Haitian infrastructure. And we are hopeful – at this point, we do have an employment coordinator in place to have the girls secure contracts to do the remote work.

LACNIC Google workshops. So last year we conducted three workshops focusing on IP traffic management and also on digital entrepreneurship. And I would say that these workshops are quite successful.

They were undertaken in Trinidad and Tobago, Guatemala and the Dominican Republic. So, for instance, in the Trinidad and Tobago leg, there were up to 120 professionals that came out.

It’s all in all been a really successful experience that we’ve had. And we look forward to more engagements and collaborations in the future.

I’m looking at the time. I’ll be really fast. Two more slides.

We’ve had an increase in the number of proposals at our meeting. So in 2018 we’ve had a record 14 proposals being presented.

And you can see what the reference is compared to the other years on that slide. And in terms of community building, participation, we have huge numbers of remote participants at our meetings.

We have another series which is called LACNIC on the Move, which are more in-house, community-based engagements with local Internet communities.

So the LACNIC on the Move last year, there was one in Paraguay. There was another one that was paired up with the LACNIC Google training in Trinidad and Tobago. And this year we intend to go to Curaçao to have that one-on-one interaction with the Curacaoian technical community.

And last but not least, we were voted second best place to work in Uruguay. It’s the seventh year in a row that we were voted quite highly and favorably in terms of a great place to work.

And, please, come to LACNIC 31 in the Dominican Republic. We’d be more than happy to have all of you there. It’s, again, in the Caribbean. You have no excuse; you already know what you’re in for – rum, sunlight, sunshine. Please do come along. Thank you very much.

(Applause.)

John Curran: Any questions for him? Just want to make sure.

(No response.)

(Applause.)

Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

John Curran: Okay. So it is now – it’s right on time. How wonderful. We’re going to go into our policy block for the morning. And this is ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers.

David Farmer is going to come up. This is a Draft Policy. This is just an AC presentation.

David Farmer: Okay, here’s the problem statement. Basically there’s an operational need for inter-RIR transfers of IPv6 and then focuses on RPKI Trust Anchor issues that we’ve discussed already today.

The policy statement here is here, and basically it’s effectively adding IPv6 to IPv4 and ASNs in Section 8.4.

Some discussions so far. Wouldn’t it make more sense to increase the deployment of RPKI in the region?

I would prefer to keep the v6 blocks cleanly in the RIRs, their each RIR. This policy seems nice. It removes the weird and, I think, unnecessary distinction from that commenter between the address families. And finally why is v6 different, essentially?

So there’s been some additional use cases discussed, because, as it says here, the current problem statement almost exclusively focuses on RPKI issues.

And there seems to be some other reasons why one might want to transfer v6 exclusive of RPKI. And a couple of those are stated here. They’re basically around reorganizations on a global basis.

Issues with the policy statement. Currently it’s basically changing 8.4 which was originally sort of the specified recipient’s transfers to other inter – on an inter-RIR basis.

Yes, you can transfer to yourself and the other RIR by designating yourself, but that’s more of a side effect than an intended result of the policy.

So, as a result, IPv6 resources can be transferred to other organizations in other RIRs. But we don’t have – because 8.3 isn’t also modified, we can’t do that in the region. So this creates a disparity between what you can do inter-regionally and within the region.

So there’s also some significant opposition to specified transfers, maybe a little less for transfers to yourself in a region. But there’s even opposition to that.

So transfers to the same Org. There’s in current policy – effectively that’s what 8.2 is about, for M&As and other kinds of transfers or reorganizations and various things.

Maybe a way to solve – if we want to do IPv6 transfers to the same organization in other RIRs, maybe the way to solve that is to change Section 8.2 to include inter-RIR transfers to yourself instead of adding v6 to Section 8.4 which is fundamentally about specified transfers.

Here is some proposed alternate text just so that people have some ideas of how this might be accomplished. Basically the idea is add reallocations to the title so that it makes kind of sense, and then add an “or” clause at the end of 8.2 that basically says if the resources are being transferred to or from an administration of another RIR in the name of the current registrant or an organization under common control.

This is where it’s kind of like an M&A because depending upon – sometimes when you are transferring – sometimes when you’re doing a multinational, you actually have multiple legal entities in the different countries. They’re under a common control, but they’re different legal entities. They’re not the same registrant per se.

So IPv6 transfers in the other RIRs. Currently AFRINIC, APNIC and LACNIC basically only allow M&A transfers of IPv6 within their region.

There are policies listed here to change that. The policies are all in flux. But basically a couple of them seem – my read of APNIC’s proposal is that it’s to allow sort of this M&A kind of transfer, not what we call specified transfers.

And I’m having a hard time interpreting LACNIC’s proposal, and then AFRINIC’s proposal seems to be going to more like a RIPE-based solution where it’s allowed for M&As and other Orgs, both in region and out of region.

So a few questions. Should the other use cases be added to the problem statement? Are there additional use cases that we need to consider and be added to? Are there use cases for transfers to different organizations that we need to consider in region or out of region? Should IPv6 transfers be limited to effectively the same organization but allowed for inter-region, or do we want to allow specified transfers as well?

And do you support the proposed text or the current text? And does anybody have any other suggestions?

It’s now time for you to get up here and talk. I’ll leave the questions up so that people can –

Paul Andersen: Okay. Good morning. Let’s get in it. Who would like to be the first to comment on this Draft Policy? Microphones are open.

Alison Wood: Hello, Alison Wood, state of Oregon, ARIN AC. David, in your research on this policy and the reciprocal policies in the other RIRs, is this a hot and heavy thing? Are there a lot of IPv6 address spaces that are wanting to be transferred, in line to be transferred? Or is this more of a future type policy?

David Farmer: I haven’t had a chance to dig too deep into this. We just got this a few weeks ago. And so I really can’t answer that question too much.

I wanted to review the other policies because I knew those were out there. But I haven’t had a chance to actually review comments on any of the other policies or to see how – I don’t have a sense of where they’re going in the other regions yet, nor how much v6 transfers. My gut tells me that the v6 transfers are fairly negligible, but I will work on getting those details.

Alison Wood: Okay, thank you. And I do support this policy.

Paul Andersen: Thank you very much. Front microphone.

Michael Casadevall: Michael Casadevall, NARALO. I’m currently neutral on this policy. While I can see a valid use case for mergers and acquisitions of bringing all IPv6 under a single umbrella, I’m somewhat wondering about the need and logistical overhead, given that most of the IPv4 transfers, especially across regions, is to deal with the fact that exhaustion and moving of v4 blocks – the v4 blocks are a very valued commodity while we have lots of v6 address space.

So I’m looking at this and I’m trying to see if there’s a real upside versus being able to consolidate because it means that then when you look at the blocks allocated to each RIR, you’ll have IP addresses within those blocks that then exist in a different RIR, and it sort of muddles which IPs actually belong to which region. And I worry of opening Pandora’s box here.

Paul Andersen: I know you’re neutral on the policy, but do you have a view on the problem statement, whether it’s a problem that should be solved?

Michael Casadevall: I’m currently neutral because I’m not hearing a strong use case. I’m not against it, but I’m not for it either.

David Farmer: So, hearing you, I think I hear you saying probably those other use cases are important if we’re going to further consider this?

Michael Casadevall: If it’s strongly important that v6 resources need to be transferred and those use cases are valid, then I would support the policy as written.

I’m hesitant that the use cases are valid. I’m not sure that type of consolidation really is all that important. And you deal with the risk of basically carving up the / – I don’t remember the size of R1 has, and their allocation to /12 becomes very messy instead of having it in the nice organized blocks that we currently have it in.

David Farmer: Thank you.

Paul Andersen: Next speaker.

Owen DeLong: Owen DeLong, ARIN AC. I’m opposed to the policy and I’m opposed to the problem statement. The result of this policy, if it were adopted, would be to enable RIR policy forum shopping and essentially eliminate the territorial exclusivity intended in ICP-2.

It’s not a good idea to do that for a multitude of reasons. The problem statement is indeed one which should be solved. However, v6 transfers are not the way to solve it.

The way to solve it is to either enable the use of alternate Trust Anchors or for ARIN to solve the Trust Anchor problem that was discussed in the previous session.

It is not – it’s a valid problem statement, but the solution does not apply to the problem statement. The solution is a workaround with dire, unintended consequences.

Paul Andersen: Can I clarify if you think the problem statement is valid or the problem statement is valid as it relates to the policy process?

Owen DeLong: The problem statement is valid as it relates to the policy process. But the policy proposed is not a valid solution to the problem stated.

Paul Andersen: Okay. Thank you.

Same microphone, please.

Kevin Blumberg: Kevin Blumberg, The Wire. I’m opposed to the policy, and I want to split it into two sections.

I do not believe the – I believe the problems are real, but I don’t believe that they are actually within the policy process, and I’ll explain why.

In the case of RPKI, it is either a technical issue not relevant to policy, or the solution should be a global policy that addresses this for all regions at once and brings uniformity among that through possibly moving to IANA as an example to handle RPKI.

This is not a valid thing that can be dealt with by just shunting off from one region to another. If our region feels that we’re dealing with it in the right way, then that is fine. But this is not a policy issue that can be resolved. It needs to be done elsewhere.

In regards to the M&As, the entire reason for allowing the v4 and AS transfers was scarcity. That does not exist with v6.

The communities, not just our community but all the communities, spent years grappling with inter-RIR transfers to finally allow them based on the scarcity and the immediate need for those number resources, specifically, in other regions.

There is no scarcity issue with IPv6. And the entire model with specified transfers, specifically, had no concept of mergers and acquisitions and the idea of forum shopping.

Again, if you want to do that, look to ICP-2 and look to changing that and look to changing the whole way that we’re dealing with things. But this is not the place for it. Thank you.

Paul Andersen: Thank you. Microphones are still open. Please approach a microphone. Or, of course, remote participants, please type your question and it will be read into the record as it will be right now, as an example.

Andrew Dul: Speaking for Jason Schiller, Google, ASO AC: I think there are three real issues we need to address. One, support M&A when the new legal entity is not in the ARIN service region.

Two, support M&A where a new legal, perhaps more strongly rooted in another region, entity prefers to be serviced by a different RIR.

Three, support of M&A where ARIN region stuff is divested and the remaining bit no longer meets Nexus requirement.

I also support removing barriers to RPKI. I hope that everyone agrees that solving that issue is urgent.

Paul Andersen: Thank you for that. Microphones are going to close in a minute if I do continue to have a lack of people at the microphone. So please approach a microphone quickly.

Rear microphone.

Mike Burns: Mike Burns from IPTrading. There was a question about the demand for IPv6 transfers, whether it’s a now thing or a future thing.

I took the opportunity to look at the RIPE transfer list for IPv6, and there have been 1355 IPv6 transfers processed at RIPE, which leads me to infer that there’s a need, absent the scarcity argument for these transfers. So I support the policy.

David Farmer: When you looked at that, does that distinguish M&A transfers from transfers to other organizations?

Mike Burns: No, you’d have to go through and look at –

David Farmer: So that could very well be 1300 M&A transfers.

Mike Burns: It’s doubtful that it’s all M&A transfers. When I glanced at it, it looked like there were several specified transfers that were not matching the Org. But in either case, you can infer there’s a business need for these transfers.

Paul Andersen: Thank you for the comment. Microphones will be closed at the end of this comment. Approach microphones quickly.

Michael Casadevall: Michael Casadevall, NARALO. I want to just append my previous comment that for reasons of RPKI, this is not the way to fix this; that I consider that use case invalid. It slipped my mind when I said it originally.

The other question I need to ask is for entities that end up with ARIN IP blocks that don’t exist in the United States because of mergers of acquisition, is there a real need to have them transferred to other regions?

I’m looking at this and I can understand wanting to only have to deal with only one RIR, but I’m wondering if, once an IP block is assigned, it should live with that RIR and stay with the same policies throughout its entire lifetime until it’s released back and a block is received from another vendor, because, as mentioned by Owen, IPv4 block transfer became out of necessity, not because it’s necessarily something we wanted to do.

Paul Andersen: Thank you for the comment. The last comments will go to the remote participants and/or Andrew if he has his own.

Andrew Dul: Remote participant, Brian Jones from Virginia Tech: I don’t have enough information to make an informed decision about this policy.

I do feel like it may open up problems with understanding where a block of IPv6 addresses are located as opposed to who supports them. Therefore, I am leaning toward not supporting this proposal with the information at hand now.

Paul Andersen: Thank you for that. The microphones are now closed. I’ll thank David for the AC presentation.

(Applause.)

Thank you. All right. Small change from standard process. The AC Chair, just so you know, has the ability to ask me to ask polling questions on any topic. And while not normally on a Draft Policy, they’ve asked me to ask the question: Does the community wish to see the AC to continue to work on the policy statement, so specifically the policy as it is written?

So I will ask for those first in favor and against, remote participants obviously in the channel.

So seeing that my pollers are ready, I will ask all those that are in favor of the Advisory Council continuing to work on the policy, 2019-4, please raise your hand nice and high.

Thank you, lower your hands.

Those that are opposed to continuing to work, please raise your hand nice and high. And of course on the remote, please indicate.

Thank you. You can put your hands down, including Kevin, I think, has his hand up.

Let’s just wait for the result. Didn’t look like a lot of hands. It’s that lovely social, that every time, without pause, staff always put on an amazing social. So, hopefully you all had a chance to get out there yesterday on the beach. They had to shove people out at eleven o’clock, so that’s always a sign of a good social.

Will we be breaking early, John, or are you going to try to squeeze one in with our 10 minutes, a presentation? Well, if we do the presentation earlier, it means it might end earlier. That’s all.

John Curran: Well, we do have a transfer update.

Paul Andersen: We have 10 minutes.

John Curran: And it could be done in 10 minutes, the transfer update. John? About 10 minutes?

Paul Andersen: Why don’t we get the transfer update queued while I get the results.

All right, for the show-of-hands result on the matter of 2019-4, we have 110 people in person or remote.

We have seven in favor and nine against. So these numbers will be provided to the AC for their input into their thing. Thank you, and we’ll turn it over to John and to John.

John Curran: Come on up, John, and give the transfers update that we didn’t do earlier.

Transfers Update

John Sweeting: Good morning, everyone. We’ll get this done and get you off to lunch.

So these are just some statistics on transfers that we always feel are interesting to the community. And we’re going to do the number of completed transfers, transfer processing time, number of IPs transferred and the size of the blocks that are being transferred.

So much to everyone’s surprise, transfers are increasing. The number of transfers are increasing. Here you can see the – it’s a pretty steady increase.

The in-region through the last two years have stayed pretty much steady.

M&As have gone up, but a lot of that is because there’s M&As required to then go and do the specified transfers. So that’s what – a lot of that is legacy space that has to be updated to their legal successor so they can actually do the specified transfer.

Processing time is decreasing. We’re getting better at processing transfers, which should be good news to the people that are involved in that. I know Mike’s shaking his head back there. So that’s good.

Inter-RIR transfers, number of IPs. Over the three-year change, there’s been 15 million IP addresses involved in the inter-RIR transfers from ARIN to the other two regions that we’re involved with for inter-RIR, which would be RIPE and APNIC at this time.

You can see the difference there, 2016. If you remember in my last presentation, I don’t know what it was about, but in there I told you that the number of IPs within the transfers depends on some of the larger transfers get – get – happen during certain years.

So in 2016 we probably had a very large transfer. In 2017 we probably didn’t – we probably missed those larger transfers. And then in 2018 we had significant number of large transfers. So that’s the difference in the number of IPs.

In-region transfers. You can see it was pretty steady, 2017, 2018, even though the number of transfers did increase.

M&A transfers, as it indicated on the couple of slides back, 2018, we have a significant number of M&As. And, again, that’s due to the legacy space that has to be merger – the 8.2 merger and acquisition process to get it to the legal successor that can then do the specified transfer. Almost exclusively that’s the reason for that.

So most specified transfer blocks are small, as you can see. Contrary to what I think is the belief, there’s a lot of /24s being transferred. As you go down and you look through it, the next significant – well, there’s /23s, /22s – but then you go down and you see /16 is the end of the larger block; /16 is the most prevalent block size that is transferred.

I guess I could make one comment on it. As you see, there’s four /10s. Sometimes that is a larger block that’s sold in increments or transferred in increments over time.

So summary. Number of transfers are increasing. Processing time is decreasing. The transfer activity is increasing the LRSA coverage. That would be the 8.2s that are increasing and the number of IPs that are coming under agreement with ARIN.

And most specified transfer blocks are smaller blocks. So it’s not just the – the big effect on the market is the big transfers, but there are a lot of small players going out there and getting their required resources on the transfer market.

That’s it. Questions?

Kevin Blumberg: Kevin Blumberg, The Wire. Really quick. Is it possible to get statistics at some point for ISP and end user separated on the percentage of ARIN users that are doing transfers both out, completely out, and as well taking in resources?

Because I think it would be useful to know 8 percent of ISPs are getting new resources through the transfer process, and 48 percent of end users are getting them through – or whatever the numbers may be, and 14 percent of all end users have transferred space out, things like that, those two sort of in-and-out scenarios in terms of the total number of members.

John Sweeting: Absolutely. What we want to do here is provide the community with the statistics that they’re interested in in accordance with the transfer market.

So if I could ask you or anybody else a favor that anything you would like to see reported on at the next meeting, see me or shoot me an email, give me a call, whatever, and we will make sure we get those statistics and we present them to you at the next meeting.

Kevin Blumberg: Thank you.

John Sweeting: Anything else?

(No response.)

Okay. That’s it.

John Curran: Thank you, John.

(Applause.)

Okay. Let me now wrap us up so we can get to lunch. Okay, brief announcement. There’s lunch table topics. So when you go out there, if you want to talk about, oh, things like transfer policy or IPv4 Waiting List or joining the AC or PPML participation or Whois database cleanup or training at ARIN, find a table. There’s people interested in that topic.

The RSD help desk remains open. So if you have questions for RSD, registration services, go out there. They can help you resolve whatever process you’re trying to do.

Take your valuables with you. This room is not locked, and we’re going to have – we’re all going to be eating so there will be no one here to watch anything.

So we resume promptly – it’s a quick day – we’re resuming promptly at 1:00 PM. See everyone back here, 1:00 PM.

(Public Policy and Members Meeting adjourned at 11:59 AM.)

Potential Waiting List Policy Actions

John Curran: If folks will come in and be seated, we’ll get started. Welcome back, for those who made it back. I have a funny feeling I’m competing with beach chairs.

So I’d like to welcome everyone back from lunch. We’re going to continue with our policy block. The next discussion is about a range of policies all having to do with Section 4.8.1 and the waitlist section of the NRPM.

To introduce this, I’m going to have Rob Seastrom come on up. Come on up, Rob.

Robert Seastrom: Hi, everyone. So for a little bit of background here, for anyone who hasn’t been paying super close attention, the ARIN Board of Trustees suspended grants from the Waiting List at their meeting in January.

This is a really unusual action. The Board is not given to undertaking emergency actions lightly. In fact, I can only remember them doing it twice before.

The point of concern here is that there was action unevenly distributed through the different ranges of blocks, where larger blocks seemed to get mysteriously sold on as soon as they were eligible to be transferred at a much greater rate than the smaller blocks.

At its annual face-to-face, the ARIN AC was advised of this suspension, and the minutes weren’t out yet, but we immediately set to curating a list of potential things that we could do about this through the policy process.

Nothing was considered off the table or too out there. It was basically a brainstorming effort, and then we distilled it from there.

The Board published its minutes, and as early as February 8th, there was a proposal from the community. The AC published its menu of policy actions on March 7th, and there were subsequent and complementary proposals that came from the community.

So this is not a Policy Proposal. This is a bunch of possible policy actions. But for the problem statement – we figured that we needed a problem statement anyway – what can we do, what is the best action or combination of actions to take in order to minimize opportunities for windfall profits and incentives to manipulate or make misrepresentations to Registration Services related to the Section 4.8.1 Waiting List?

I have a slide here for each of the potential policy actions. This is basically a restatement of what we posted to PPML in March. Actions that have a policy in play that is in that space are color-coded green, and they have a plus next to them. Actions that the AC considered suboptimal are blue with a minus after it.

But one of them got changed based on feedback on PPML. It is now green. Actions that have not gotten support as far as a Policy Proposal and have not gotten the hairy eyeball are black and white.

Are we ready? Let’s go through the list. Overarching concern here. If we change the criteria or how much you can get or other attributes of it, what happens to the organizations that have already justified space through Section 4 and are now on a Waiting List?

And there’s a bunch of things we could do with that, and there’s no firm answer that’s made itself clear yet. There probably will be once we figure out which policy proposals get traction.

Here’s one of the possible policy actions we could take. 4.1.8 space would go to the replenishment pool for critical infrastructure or transition space.

There were comments to the effect that this was a good way to serve new entrants and that it would create a larger pool of small blocks for this. Unfortunately, it does send the wrong message about the future of IPv4.

Another possibility, since we’re trying to get rid of windfall profits, one of the things we could do is take away some of the money on the input side, meaning ARIN would charge a fee involved with these blocks at issuance time, and after that it would be under a standard RSA.

We considered that possibly more fair than just putting the space on the market. But there were multiple folks on the AC and privately who said to me, you know, if this Policy Proposal change that we do favors anyone or creates an uneven playing field, it really ought to favor those who are otherwise unable to participate in the market in a meaningful way. And this would certainly pull the rug out from under organizations that had no money.

Another possibility was to make 4.1.8 space untransferable. Unfortunately, we considered this to be bad in terms of Whois accuracy, because it would basically put something – it would potentially give rise to just backdoor transactions and not being reflected in Whois.

But it does reduce the incentive for fraudulent application with the notion of profiting on it. If you can’t pass it on, certainly the value is reduced if one’s just signing an LOA.

Other folks have told me that, you know, you probably are painting the devil on the wall here with this underground market. And it may not be as high as you think it is.

A more gentle version of this is to create a longer hold-down period after receiving 4.1.8 space. Currently you have to hold onto it for a year before you’re eligible to transfer it on.

There is a Policy Proposal that proposes a hold-down period of 24 months, which is 2019-6. So that is currently in play. Another possible policy action was only one 4.1.8 application per applicant.

The big difficulty to this is that spinning up new corporate entities is something that I sometimes think that the business side of my organization does just for fun because they’re bored.

It’s $150 to (indiscernible) a registry, and you’re off to the races with a new set of corporate papers. So it is a higher impact on folks trying to game the system. It sends a good message about new entrants.

Unfortunately, it may not actually have the effect that we would like it to.

Another possibility that was floated is no 4.1.8 resources for any existing IPv4 number resource holder. It’s a variant of no getting back in line. The Waiting List is for new entrants.

Another officer attestation at the time of being placed on the Waiting List. This is not something that we can say via the Public Policy process, but we can certainly suggest that the Board consider implementing and discuss with counsel. If this creates friction or a sticky surface for things that rise to the level of fraud, then that could potentially be a good thing outside of the Public Policy process.

Another possibility, this one is in play. This is the general action here. I have slides for the specific prefix lengths after this. Generally everyone I’ve talked to and all the discussion on PPML suggested to me that this would be part of any comprehensive solution. Right now we don’t nail it down, and there are folks in line for up to a /16 on the Waiting List.

What’s the particular implementation? Why don’t we just make it a /24? After all, APNIC just made it a /23, right? A /24 serves the most organizations, creates more grant events for registration services to be able to discern a pattern. Gee, all these organizations have the same P.O. Box. Gee, is there something weird about that? RIPE is discussing doing this.

Unfortunately, it also maximizes the number of organizations that get less space than they could otherwise justify. How about make it a /22?

There are no or substantially no questionable applications at this size under current policy. The fixed costs of doing the transfer are sufficiently high that they eat into the project margin for selling /22s onward.

This would serve a greater diversity of organizations than just a /24. Everybody brings up RIPE using /22s and the externalities they’ve had there. I’d like to point out we’re not talking about getting rid of needs basis.

We’re not saying anybody with a corporate entity who says I want to be an LIR, you’re going to be an LIR and get a /22.

I don’t anticipate that to be a problem if we go to a /22. This is proposed in ARIN 2019-2. Well, how about a bigger chunk then? /21 or a /20.

There’s still no or substantially no questionable applications under today’s policies. That’s 16 times the payout for selling it on, but it’s a cut of a factor of 16 for – compared to a /16 if somebody was justifying the space with the idea of selling it on.

The AC talked about this and said, you know, this only moves the goalposts, and cutting it down by a factor of 16 is not sufficient to keep a lid on gaming the system.

So there’s some things that the AC thought, gee, bad idea; we’re just not going to do this, or we’re not going to suggest this, is no longer issue 4.1.8 space. In other words, continue the 4.1.8 suspension indefinitely.

This is basically equivalent to eliminating the Waiting List except it’s on the output side. You could continue applying for Waiting List space as long as you want to. We’re just not doing it.

This would have the bad effect of, you know, ARIN gets back a lot of space. They get it back primarily from organizations that don’t pay their bills.

If you’re out of compliance because you haven’t paid your membership fees, space goes back.

Oddly enough, there’s some organizations that hand back the space. And nobody was more surprised to hear this than I was. But some organizations said, well, you know, yeah, sure, we know we could sell it on, but it’s – getting the money would create a problem for us, so just please take this back. ARIN gets enough space back that this is really not where we want to go with this.

How about on the entry side? We fill the applications that are already in and then we’re done. Close down the entry side of 4.1.8. This is basically the same thing as getting the entry of the Waiting List – still the same problem, the stranded space problem.

How about if we prioritize not-for-profit organizations? They’re all doing God’s work, right? Well, the problem is that that status is an artifact of national tax laws wherever you happen to be.

Not-for-profit and good work shouldn’t be conflated, and it says nothing about your size or budget. And it would be difficult to implement across the entire service region.

How about we go back to business as usual? Maybe we as the AC just say, well, you know, Board, do whatever you want here. Maybe the Board should just unsuspend it and keep on going.

We didn’t think this had legs for obvious reasons. So distributing 4.1.8 space via the transfer market. This is a little bit of a surprise to me.

AC members and folks outside the AC who have been in the community a long time that I talked to said, man, the optics on that are terrible. Everybody is going to think that ARIN has an incentive to yank back address space. The community will never support this.

And yet when the discussion of the /22 came along, what was the number one comment I saw? It was, “why are you doing this at all; you should just be selling this.”

There’s a transfer market. Sell the space that comes back. So distribution of reclaimed addresses in an orderly fashion via the transfer marketplace is proposed in 2019-7.

Another possibility which we rejected because it was even less a wobbler than the /21 was a /19 or a /20. This would just move the goalposts incrementally and probably not result in any kind of serious reduction in the number of questionable applications.

So here’s a summary of all the possible things that we’ve discussed. No doubt some folks in here are looking at some of the black ones and saying, you know, I think that sounds like a good one.

AC members, hands up. AC members. Look around you. If you don’t know how to submit a Policy Proposal, we are around. We’re all around you. We’re at your service. We can help.

So that’s the end of the slide deck.

Paul Andersen: So this is technically a policy block. But I would note that one of the complications we have is that while the AC has done great work, and the Board thanks you and the entire AC for doing this excellent summary, there have been other proposals that are on the agenda today that have been injected by members of the community.

I guess if there are questions, it would be best if they were left at high-level concerns or support, noting that we don’t want to get into the specifics of policy text that we’re discussing later, if that’s possible to wait to that point.

Robert Seastrom: All right. Owen, go ahead.

Owen DeLong: Owen DeLong, ARIN AC. Stop accepting applications for 4.1.8 is actually worse than no longer reissuing 4.1.8 space, because it doesn’t trap the space at ARIN.

Instead, it creates a timing lottery where if you get your application in first right after ARIN gets the space ready to re-issue, you win. If you don’t, you lose.

And I think that would be substantially less fair than trapping the space at ARIN actually. So I would really hate to see that happen.

Both of them are on the nonstarter list so that’s a good thing. I would actually like to see a combination of reducing the maximum issuance and increasing the hold-down timer. I think that’s probably our best bang for the buck without doing too much unintended damage.

Robert Seastrom: Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire. I’m not going to talk to the proposals that are there. We’ll do that at that time.

I want to talk about policy versus RSA because I think it’s critical to this overall discussion. If somebody gets space through policy that is accepted and then two years later transfers that space, the fact that the space was not used for its intended purpose really, the space can’t be returned. They thought about using it for the right reason and then they decided not to.

You can’t really prove it was fraud. So the RSA doesn’t have a revocation for policy abuse. It has some very specific requirements.

And that is a problem because there was one policy that I want to use where we looked and envisioned this abuse scenario, which is the TPIA policy.

If you look at the TPIA policy, it says that an M&A transfer may not occur unless it’s for intended purpose of what that block was in the first place, because, quite frankly, a /22, or whatever size it is, it doesn’t matter the size, it’s irrelevant, if I can get space from ARIN, wait seven days and decide my business model has changed, lease that space out for two years, I am going to make money at it.

And then I can turn around and sell it on top of that and make money on it. And whatever numbers you have here are not relevant.

There will always be a way to make profit. So unless you can take that away through either the RSA or through some teeth in our policy manual that directs staff to use the RSA to treat something as what is equivalent to fraud from the RSA’s perspective, none of this is going to make a matter because we’ve gone through this in all the other regions.

Paul Andersen: John would like an opportunity on that.

John Curran: So, if you would like to make it so that people do not use the space issued via the waitlist queue except for the purposes intended, then you can tell them, tell us in policy: This block is to be issued and is nontransferable and, if not used, must be returned. And that will solve the problem. People will not monetize those blocks.

If we catch people doing it and we have people who do creative, like, cross-lending of address space, we take it back. It’s easy enough to take back.

And people will know they don’t want to be on that address space because we’ll take it back and reissue to someone else waiting for it, because there’s a queue of people waiting for it.

So you can create the issuance of address space which is nontransferable, and it will be nontransferable. And it doesn’t need anything in the RSA, and it’s 100 percent enforceable.

Be careful, if you’re going to do that, that you’re very clear these blocks being issued are nontransferable.

Kevin Blumberg: That’s not what I’m looking at. What I’m looking at is the concept of as long as the block was used for its intended purpose originally, after X time, if things do change, then that’s fine.

But this issue is people are getting the blocks, using them – and we’re seeing this in the other regions and that’s why their policies changed – leasing out the space, not using for its intended purposes and then waiting the three years or whatever and flipping it.

John Curran: So the problem is if you want to decline an M&A transaction.

Kevin Blumberg: Right.

John Curran: The M&A occurred – we’re back to record-keeping, okay? Other company bought your company. They may have bought you for the address space, but they did buy you. And so us not recording that is very difficult to do because you’re consciously saying you don’t want to record what is an actual transaction.

The rights almost certainly legally have transcribed. If we get into a situation where that subsequent entity goes bankrupt, I am going to be facing a bankruptcy judge who says, I bought A, he had these resources; show me why they did not transfer.

And so you’ve got – we don’t have perfect insight into requesters, the state of the mind and the state of their business.

When they come back and say we used it for a while and then there were changing circumstances, ARIN is generally flexible in this regard because the alternative is bad record-keeping.

I’m not sure, unless you’ve got – if you want us to polygraph people, I’m not sure we can go back retroactively and say you did this entirely to get address space.

Paul Andersen: Could we do that? Could we polygraph people?

John Curran: I can do whatever the Board likes.

(Laughter.)

Kevin Blumberg: I think that’s the message for the community, is ultimately once this space is given out, there’s a clock ticking or not depending on what the community wants, and we need to make that decision.

But once that space has been given out based on the policy, if we allow a transfer in two years, then a company is perfectly, legitimately allowed to do that.

Paul Andersen: So we have about five more minutes in this block. If you want to approach a mic, make a comment, please approach now. And if those that are at the mic could be as succinct as possible, thanks.

Michael Casadevall: Michael Casadevall, NARALO. From where I’m standing, from this list, the only way you’re going to prevent gaming of the list is by disallowing transfers and then looking a very critical eye at mergers and acquisitions and basically be at a point where you’re going to reclaim space if M&A happens and so forth and so on.

I know it’s really easy to make multiple corporate entities trivially. But the 4.1.8 space is basically what’s left of v4. We should still be able to issue it without people having to go to the secondary market.

And I think we need to look seriously at what we can do from a legal point of view to limit how address space can be abused in transfer or mergers or acquisitions.

In saying that, the address space must be returned to ARIN and then granted a waiver to be returned during M&A, may be the way to do. That would help reduce the gaming quite a bit from this address space, by putting restrictions on it in addition to nontransfer.

Paul Andersen: Who’s next? Kerrie.

Kerrie Richards: This question is from Jason Schiller, Google, ASO AC: Can ARIN staff pull together stats for all Waiting Lists larger than a /21 that are still waiting; choose to take less and are not waiting, how much less – half quarter, one-eighth; took a transfer and are not waiting; withdrew from waiting; or got what they asked.

Paul Andersen: I was just wondering, because obviously – maybe we could just provide that comment to John Sweeting, and he could –

Robert Seastrom: I was going to say, indubitably, John can get some sort of statistics and have Jason sent over the specifics so he has that in front of him. You got it? Perfect.

Paul Andersen: Microphones are closing soon.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. So going back to the 4.1.8 allocations that were flipped, that were recognized, that resulted in the suspension in January, in retrospect, obviously you probably aren’t able to say anything specifically about those transfers, but is there anything in retrospect in those transfers that looked kind of hinky?

Has there been any retrospective to figure out, okay, is there something that we can look at in the request that may or may not allow us to better catch these types of requests in the future? And could this just be solved by increased scrutiny?

Paul Andersen: John?

John Curran: There was a number of tactics used that we cannot overcome. They involve fraudulent representations, well-crafted, and next to impossible for us to detect.

And so in that regard, no, it’s a problem, and it’s a significant problem. There’s costs involved in doing it. Those costs are relatively high.

And so very large address blocks enable that type of fraud in a way that’s very problematic. Akin to someone coming into the meeting with plastic surgery who looks like me moderating the mic, you might have a little problem overcoming that if someone wants to put a year’s work in of preparation.

We have some very advanced people who have decided to do some very aggressive schemes. And so we’re dealing with it.

There are other lessons learned from other cases, and we do incorporate better scrutiny, but recognize if there’s a large financial incentive, people will do things that you would think not reasonable to attempt to pull one over on ARIN.

Paul Andersen: Last call for microphones. Microphones will be closed after this comment. Approach the microphone immediately, please.

Kerrie Richards: From Brian Jones, Virginia Tech: I support 2019-6, at least in principle, for increasing the length of wait times.

And I have another question from Jason Schiller, Google, ASO AC: Can we get a sense of how?

Paul Andersen: How…

Kerrie Richards: Yeah, I’m going to ask him.

Paul Andersen: I’d ask Brian, if it is possible, if he could make the comment during the 2019-6 block, and any chance you’re getting more –

Robert Seastrom: Can we get a sense of how? The answer is clearly “maybe.”

Kerrie Richards: “How long a wait time the community would tolerate. Is it different if it only includes specified transfers?”

Paul Andersen: Could you read the whole thing together?

Kerrie Richards: Right. He said, “Can we get a sense of how,” and then he followed up by saying, “how long a wait time the community would tolerate? Is it different if it only includes specified transfers?”

Robert Seastrom: I did not manage to get the discussion of that into there. There was a question of 8.2 versus 8.3 transfers and what ought to be done. And I don’t see – I personally, as sort of the curator of this pile of possibilities, see them as two very different things –

Paul Andersen: Owen, directly to the point just raised.

Owen DeLong: I think there’s definitely a distinction between what we would want to accept in terms of rules regarding 8.2 transfers versus 8.3 or 8.4 transfers. And I would strongly suggest that the 8.2 transfers might incur a shorter waiting period than 8.3 or 8.4.

Paul Andersen: Thank you. Microphones being closed. Over to you to finish off.

Robert Seastrom: I have nothing further. Thank you very much.

(Applause.)

Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

John Curran: Okay. We’re going to move into the next policy on the list, which is ARIN 2019-2: Waiting List Block Size Restriction. And Alison Wood will come up and give the presentation.

Alison Wood: Hello everyone. I’m Alison Wood, and this is Draft Policy 2019-2: Waiting List Block Size Restriction that you heard just a little bit about in R.S.’s talk.

So, shepherds on this policy are myself, Alison Wood, and you can recognize him by the bitmoji, Andrew Dul. There he is.

I do want to give a shout-out to my Copacabana volleyball team. We fought a good fight last night. Wendy stacked her team with some professional volleyball players. I don’t think that was fair, but we’ll move on.

So, as you all know, the waitlist has been suspended, and this proposal is an attempt to minimize the abuse in the free pool.

I know there’s a lot of waitlist experts, free pool experts in the crowd, but we did have a lot of newcomers. So just forgive me while I back up a little bit and talk a little bit about the free pool.

So an organization can apply for IP address space from the free pool. They’ll be put on a Waiting List, and the minimum that we dole out is a /24. Today, as R.S. mentioned, there’s no maximum. So we do have people sitting on the waitlist, waiting for a /16.

They are granted that IP address space when it comes available. So people requesting smaller blocks usually get their space before the people who are requesting larger blocks. But they still get their space.

So the summary of this Policy Proposal or Draft Policy is that the maximum size that we dole out on the free pool is a /22. If an organization comes in and requests a smaller size than that, then obviously we would go with whatever is smaller, the /22 or what they qualify for under the ARIN requirements.

So this is the current text with the update in blue and underlined. And, again, so what it says is today an organization can come to ARIN. If they meet requirements, they get the address space that they request over time.

And the update to the policy would state that the most that they can get is a /22 if they meet their requirements.

This I pulled directly from the PPML. These are comments that came back from you, the community. And I hope they will instigate some discussion.

So pretty much limiting the maximum block size to a /22 will decrease the financial incentive by the bad actors out there. The majority of Waiting List requests are for smaller block sizes, so by eliminating the fraudulent activity and also reducing the block size, that should allow people asking for smaller blocks to get their IP address space quicker.

Okay. So what we learned today is that APNIC does dole out a /23. So my slide is incorrect. But RIPE and LACNIC will give out /22s out of their last /8s. If we switched our policy to be a /22, we would be in line with RIPE and LACNIC.

And let’s see, organizations that generally need larger blocks can obtain those blocks on the transfer market.

Oh, I turned it off. That’s okay, I have it memorized. Practiced after volleyball. Thank you.

So for discussion, please feel free to come to the mics and discuss anything you’d like with this policy. Happy to answer all of your questions. However, I’d love to know if you support the suspension of the Waiting List, if you feel that a /22 is the appropriate size block or if you would like to see different sizes. And I don’t know if other restrictions that should be applied are appropriate in this policy block, but I’m more than happy to answer and address your questions and comments.

Paul Andersen: A little preface as the guns line up at the microphones. If you’ve looked at the agenda, you’ve seen that there is several policies that are all related to this waitlist. So I’d ask the comments be directed to whether you’re in favor or against this policy and try and avoid other policies when the block comes up.

We do have some Open Microphone later. So if after, later you want to try to bring back some items, we can always address it there. But we generally, for the idea of a fluid policy discussion, try and deal with the matter on the table, which is 2019-2.

So with that warm-up preamble, I’ll ask if there’s anybody who wants to speak. Wait, look. There’s tons of people. Just to throw it off a little bit, we’ll go to the side microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I support the policy as written. I believe that suspending the Waiting List was the right thing to do under the circumstances.

I believe that this policy would not be the only mitigation I would like to see be put in place before the Waiting List allocations are resumed.

Paul Andersen: Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the suspension of the waitlist. That’s the first thing. I support the intent of this proposal. But this proposal is not enough unto itself to then allow for the waitlist to be brought back.

The /22, I believe, is the right size. It’s very consistent with other regions. I don’t think right now it makes a difference whether it’s a /22 or /23, but I think that’s fine.

In looking at the other regions, the disincentive financially has been because of their fees yearly for these services. As an end user, once you’ve gotten it, the fees are very low.

One of the things to considering is possibly only allowing the waitlist to go to RSA, Registration Services Agreement, people, who are then having to pay for these services every year to maintain them. That would be a very big disincentive, very similar to the other regions, like I said.

I would like to see it either under no transfer or under a long waitlist, three to five years, similar to what APNIC has just looked at.

Again, there has to be something other than just /22 for me to support opening the waitlist back up.

Alison Wood: Okay, thank you.

Paul Andersen: Back to the middle microphone.

Owen DeLong: Owen DeLong, ARIN AC. Could we go back to the slide to the questions for the community?

I would support reinstating the Waiting List if we address the issues that were raised by the Board when they suspended it.

I think /22 is fine. I’m actually fine with anything /21 or longer as being a perfectly valid size to do this.

I do think we need other restrictions. I would like to see at least a strong 24-month waiting period for transfer with a possible exception for M&A, but I’m not completely sure I want to make an exception for M&A. But we can discuss that under other policy proposals. So I’ll leave it at that. Thank you.

Paul Andersen: Thank you. Back to the side.

Joe Provo: Joe Provo, ARIN AC, Google, speaking for myself. Yes, I wish we could go smaller, but I don’t think we could. And most definitely yes. I will speak to the other policies when they are up.

Paul Andersen: Thank you. Middle microphone again.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support reinstating /22 – like Owen said, /21 to /24, anything in that range seems reasonable. /22 seems as good as anything. And, yes, we probably need additional restrictions.

One comment here. There was discussion of, well, /22 doesn’t completely eliminate the incentives. And we’re not about completely eliminating fraud. There’s no way to be perfect in that. We’re looking to have a reasonable balance between disincentivizing fraud and making sure that there’s no large incentives and penalizing the good guys, penalizing the people that are doing legitimate things.

So it’s about finding a balance, not about perfectly eliminating fraud.

I support the policy as written.

Paul Andersen: Thank you. Microphones are still open, but we’ll have to close soon if I run out of speakers. So please approach a microphone shortly. Back over to this side, please.

Barry Sherwood: Barry Sherwood, Great Basin Internet Services. I’m in support of this as written. I’d like to see a 24-month waiting period.

And I think I prefer the word “arbitrage” over “fraud.” Because I think it is a gaming of the system. I don’t know that it’s necessarily fraud. It’s just somebody sees an opportunity, and they’re taking advantage of it. And if we don’t like it, we can stop it. So there you go.

Paul Andersen: Thank you. The microphones will have to close after this speaker if we do not have – so please approach a microphone as soon as possible if you’d like to speak.

Chris Tacit: Chris Tacit, Tacit Law and ARIN AC. I would only support reinstating the waitlist if the considerations that the Board identified in suspending it could be significantly lowered or eliminated.

Although, I take David’s point that it may be impossible to completely eliminate the problem, but we might be able to make it a minimal issue.

/22 seems fine to me. And with respect to other restrictions, yes, I believe there need to be others, for the simple reason that, as we heard yesterday, there’s going to be economic value in IPv4 address space for the foreseeable future, and it’s likely to increase in the next while.

And so whatever we do will need to be probably a multipronged solution that calibrates itself to try and counter some of the economic incentives. And I’m not sure a block size is enough.

So I’ll reserve judgment as to what might be after we listen to a few of the other proposals and maybe discuss it after that. But I don’t think any one remedy is going to be enough. I think you’ll need a combination of techniques to do it.

Paul Andersen: That will close the microphones after Chris. I’ll give one extra second. All right. So that ends it not. So we will thank – not only will we thank you for your presentation, but we’ll also explain why we keep making the joke, because she is a – broke her world record in high jump just recently. So double –

(Applause.)

So that ends that one. John?

Draft Policy ARIN-2019-6: Longer Hold Time Requirements for 4.1.8 Recipients

John Curran: We’ll have Rob Seastrom up again to cover 2019-6: Longer Hold Time Requirements for 4.1.8 Recipients.

Robert Seastrom: Speaking of records, I’m going to try to set a record here for a short presentation.

So problem statement. We’ve all seen this problem statement before. The Board has suspended 4.1.8 Waiting List. Minimum hold time before you can transfer address space onward is a year right now. The author says that they believe the longer hold time of 24 months is reasonable.

Policy statement. To do same and put 24 months in the NRPM where there is currently 12.

And there’s been no discussion on PPML, even though it has been sent to PPML as a draft – there’s one – none sent to PPML as a draft, and the fact that the AC took it onto their docket was posted to PPML.

So questions, discussion.

Paul Andersen: Barely sat down. Microphones are open once again. Looks like you’ll get a little – well, he’s just running away from me.

Okay. Well, thank him for his very quick presentation, and we’ll open the microphones in the front middle again.

Chris Tacit: Chris Tacit again. This is another one of the factors that I think ought to be considered, duration, but I seriously doubt that two years is going to be sufficient given the extended time during which IPv4 address space is likely to be valuable.

I think you’re going to need to see a much longer period for people to start thinking twice about not sitting on these things, or leasing them in the meantime and then doing the transfer at the end of whatever that period is.

Paul Andersen: Thank you. So you’re in support of this – if I understood you correctly, you’re in support of this initiative, but maybe –

Chris Tacit: As one potential piece. But I don’t think it does it all, and the duration not quite long.

Kevin Blumberg: Kevin Blumberg, The Wire. I would support the Advisory Council merging this policy with the policy before it, taking this one salient point from this problem statement, which is to increase the time, and making that a factor of the first proposal, which is more important. This is a secondary control, not a primary control.

And I agree with the previous speaker, 24 months is not enough. I believe we need to look at the other regions and all the issues they’ve had over the past three years, because they’ve had significantly more issues than us based on their pools, and look at three- or five-year things based on feedback on the types of abuse that they saw in those regions.

Paul Andersen: So you’re in support of the problem statement, effectively?

Kevin Blumberg: I’m in support of the problem statement.

Paul Andersen: Thank you for that. Back to the middle.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I like the idea of merging this with the other proposal.

I would be concerned with approving any of them on their own. I think we need to have a consolidated solution.

I support the problem statement, it needs to be longer. I agree that 24 is probably not long enough. Maybe start with 36. Anything 36 to 60 months seems reasonable. I’ll leave it at that. Oh, I do support the problem statement.

Paul Andersen: We go back and forth. If you want to get in, look for the shorter line.

Barry Sherwood: Barry Sherwood, Great Basin Internet Services. I do support the proposal as written, although combining it would also be good. 24-month minimum. I said 24 months earlier. 24-month minimum.

Owen DeLong: Owen DeLong, ARIN AC. I do support the extension of the waiting period, as mentioned earlier. I’m perfectly fine with David’s suggestion of 36 to 60 months as valid targets. I am not sure that, when combined with the smaller prefix size, this wouldn’t do it.

People keep talking about comparing to the experiences in other regions. I would like to point out that no other region has experience with a Waiting List. The other regions’ experiences are with issuance from their final /8s, primarily, not with the Waiting List.

Paul Andersen: Good distinction. Thank you. Back over to this side.

Kevin Blumberg: Kevin Blumberg, The Wire. One additional comment. Our routing policy says that ARIN does not guarantee that the route that you get is globally routable.

Paul Andersen: Correct.

Kevin Blumberg: One other suggestion is to basically put into this, or whichever policy it is, that space issued under the Waiting List is not guaranteed to be transferrable and basically allow the community to revoke at any time transfers if they feel that abuse is there; but to actually spell it out that you can get space here, but don’t expect that at some point that might change. Let people know in advance.

Paul Andersen: Maybe I misunderstood. When you say the community to deny a transfer, I assume you mean may change the policy on you on transfers?

Kevin Blumberg: Yes, that things may change in the future.

Paul Andersen: Not that the community would suddenly approve every transfer.

Kevin Blumberg: No, no, no. The Board suspended this policy for a very good reason. And I think that somebody coming to the Waiting List a year from now is not necessarily going to know the history that we all know, and putting in there that at some point the Waiting List – again, M&As I’m going to separate out of here, because M&As are very different, but just this is not potentially going to be a windfall, you may not be able to transfer the space at a later date.

Paul Andersen: John, would you like to speak? I saw your –

John Curran: Why would you not say space issued via this policy is not transferrable, period?

Kevin Blumberg: I would be happy with that.

John Curran: You just said might not be at a later date. And the real challenge we have is that it’s pretty easy to tell someone we’re issuing you space that’s not transferrable. It’s a lot more challenging to issue them space, and then you guys do something in the future, and then we have to go back to people who have space and they say: They made your space issued not transferrable. That opens up a discussion about changing the rules out from under them.

Kevin Blumberg: And that’s why I was saying to document the fact that the space may or may not be transferrable.

John Curran: Why maybe? Why have that? Why not just say “It’s not”?

Kevin Blumberg: Okay.

John Curran: That’s my question. You keep saying “may be transferrable.”

Kevin Blumberg: The only reason is metrics on abuse, and if those metrics are not met, then transfers are fine.

John Curran: It’s far better just to prevent transfers.

Paul Andersen: Thank you. All right. Please approach a microphone if you’d like to comment. We’re running out of speakers.

Sir, you look very much like the person that was standing here a second ago.

Robert Seastrom: I was. But down here I’m not speaking on behalf of my employer, because I don’t have one this week, and I’m not speaking as the shepherd for this. I’m speaking only on my own behalf, and there are two points I’d like to raise.

One is “I think we should pass two proposals that do two different things” and “I think we should merge these proposals” are at odds with each other.

And many years ago we had someone who was in the community who was fond of omnibus proposals that have a lot of stuff in them. And merging the proposals, unless there’s a good problem that’s being addressed by that, makes something that’s actually harder to get consensus on.

Paul Andersen: That is true.

Robert Seastrom: And I believe that either making it a longer prefix or increasing the hold time is by itself an incomplete solution, but that does not mean I believe we should throw together what we believe is a complete solution, giving it to the community to take it or leave it.

So I am opposed to merging this proposal with any other proposals or any of the other proposals that are currently in with any others. So that’s number one.

Number two, when we talk about making it three years, five years, ten years minimum hold time, what we’ve essentially done is made it you can never transfer it, because five years in Internet time is an awfully long time.

And we’ve done a lot of work to make Whois is more accurate. One of the things we did that got a huge amount of community support was to eliminate the audit with 8.2 so that M&A could update and not have companies that you hadn’t heard of since the dot-com era in Whois.

So I want people to think about the externalities and the unintended consequences of advocating for a longer hold time. I would love to make the hold time be essentially forever, but I temper that with the fact that I value Whois accuracy very, very highly. Thank you.

Paul Andersen: Thank you for your comments. Microphones will close after this comment. Please approach a microphone if you’d like to comment or start typing. Go ahead, please, remote.

Kerrie Richards: Speaking for Jason Schiller, Google, ASO AC: I support a longer time, including 24 months, 36 months, 60 months, or maybe even 120 months.

Paul Andersen: That closes the microphones. I would like to thank the AC presenter, but he already disappeared on me. But we’ll thank him regardless.

(Applause.)

Draft Policy ARIN-2019-7: Elimination of the Waiting List

John Curran: Let’s talk about getting rid of the waitlist. If Alyssa Moore will come up, we’ll present 2019-7: Elimination of the Waiting List.

Alyssa Moore: So it won’t be quite as short as R.S.’s presentation, but this one’s pretty brief. And Amy Potter is the co-shepherd on this one.

I don’t think I need to go through this. We’ve been talking about it for the last hour and a bit. That’s the background.

So we already all know the problem. Unfulfilled requests create an opportunity for ARIN members to claim need for number resources, wait for those resources to become available via returns or reclamations, acquire them, wait a year and a day, and profit from them.

And ARIN can avoid this by abolishing the Waiting List and transferring returned and reclaimed resources to organizations that have qualified via the existing 8.3 process.

So the policy statement essentially says that we would get rid of Section 4.1.8 all the way through and add a new policy section on returned and reclaimed resources.

It also says that ARIN will auction returned and reclaimed IPv4 number resources to recipients qualified under Section 8.3. The revenues from those auctions would be realized – that would be realized from this activity will be allocated for purposes as directed by the Board of Trustees.

And the author also left us a comment that the specific auction methods and implementation details used to distribute the returned addresses are outside of the purview of the policy process. So that would be something dealt with at a later date and outside of this process.

So there’s no discussion so far on PPML about this particular policy. And I’ll open it up for discussion from there.

Paul Andersen: Approach the microphone. And Owen wins.

Owen DeLong: Owen DeLong, ARIN AC. I strongly oppose this Policy Proposal. There’s no good that comes from this, in my opinion. ARIN does not need the revenues from this. It doesn’t have a purpose in mind for those revenues.

I’m sure we would find one, but in general, in my experience, a large supply of revenue looking for a purpose in a not-for-profit organization tends to lead away from goodness; witness the “I can make money fast” gTLD scheme. So I think this is just a bad idea on multiple, multiple levels.

It also would disadvantage the very members of the community we’re intending to serve under 4.1.8 strongly. And so I really think that it’s a bad idea on both sides of that equation.

Paul Andersen: Okay, thank you. Over there.

Kevin Blumberg: Kevin Blumberg, The Wire. I don’t support this policy. If we want to be altruistic, we can return it to IANA, like we have done with some previous blocks, and let them distribute it out to regions that need it. But I believe we do have a need for this space, and this is not the way to go about it.

I have a fundamental issue with my doctor getting a kickback for services rendered. I have a fundamental problem with ARIN subconsciously or consciously being involved in the auction process of IP space.

I don’t need a quota system where staff are looking at things, going, well, you know, if it was done this way, we’d get revenue and – exactly.

Paul Andersen: No, no, don’t encourage –

Kevin Blumberg: And perceived or real is irrelevant, it just completely dilutes the stature that ARIN has with the global community in how it operates, and this would be a massive knock to that.

Paul Andersen: Thank you. Center microphone.

Robert Seastrom: Rob Seastrom, speaking for myself, because that’s all I’ve got. I agree with Kevin that the concerns as far as appearances with the other RIRs is a problem, but I also believe that this is far from being the worst possible outcome. If we’re looking at this from the standpoint of stopping the incentives for arbitrage or for making misrepresentations to Registration Services, this does it and stops it cold.

We’re handing out things that have value for free. We’re not running a charity here. We’re not for profit, but that doesn’t mean we’re picking winners and losers.

So I think that picking winners based on an externality that favors making misleading statements to Registration Services is a couple steps away from goodness.

So I’m on the edge. I’m teetering on the edge of supporting this as written. Thank you.

Paul Andersen: Thank you. Over to the far microphone again.

Joe Provo: Joe Provo, ARIN AC, Google, speaking for myself. I do not support the intent. As Kevin outlined – pretty much summed that up well.

If by some miracle it goes forward, I would think we need to address the language that talks about revenue stuff that’s kind of outside of general policy discussion and –

Paul Andersen: Sorry, which part?

Joe Provo: The second sentence, I think, talks about at the discretion of the board of directors, which all revenue really is – all the money management is at the discretion of the board of directors, so it’s kind of pointless.

Paul Andersen: It’s actually as directed, but I understand what you’re saying.

Joe Provo: Or if it does move forward, then perhaps that should actually specify an earmark or make it an earmark fund instead of an unspecified thing.

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

Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. So I oppose this policy for two reasons. First of all, I do think we need to be able to find conditions under which we reinstate the Waiting List, but I do also want to address the economic issue.

I’ve been thinking a lot about this, and having ARIN essentially sell address space I think would be an enormous departure of the way that the organization views IP addresses as a whole. In many ways it runs contrary to its history of trying to treat address space as a public nonproperty resource.

It would, for the specific commercial transactions involved, raise a whole bunch of questions. If somebody’s paying a lot of money for actually space, shouldn’t they then have an irrevocable property right to it? Could ARIN really ever expect to be able to take it away again under any conditions?

So it raises a whole bunch of very complex problems that I think would need to be thought through by the Board of Trustees far and above policy issues associated with this. Thank you.

Paul Andersen: Thank you. Once again, we are depleting our speakers. So if you would like to speak on this topic, please approach a mic expeditiously; otherwise, we will close the microphones at the end of our next comment.

Andrew Dul: Andrew Dul, speaking for myself. I will note that there has been a number of people on the PPML who have supported this idea, just not under this specific policy.

So there’s more I think positive posts regarding an auction idea on the list than zero. There have been zero under this specific policy.

And then to the issue itself, I believe we need to provide a financial disincentive for organizations to game the system. An auction is one method to provide a financial disincentive to do so.

I’ve also as discussed earlier in the day we talked about a fee for a waitlist allocation. I also believe that is a financial disincentive to perform activities that would lead to potential fraud activity.

So I could support both of those ideas. I don’t know the exact best method to do that. But I think just changing the size and some restrictions is probably not enough to make the types of issues go away that have caused the Board to suspend the policy.

Paul Andersen: Okay. Again, we need to close the microphones soon; so please approach a microphone. We’ll give you the last one before we close.

David Farmer: David Farmer, University of Minnesota, ARIN AC. My gut reaction to this proposal is “bleep” no. However, I’ve been – this is a radical change and maybe this problem needs some radical change.

So while I probably don’t support it, we need to talk about this – the only thing that I’d say is before I could even possibly support this, I would need to have a better idea of where the revenue goes. Just creating this pile of money without knowing what’s going to be done with it seems like a horrible idea.

Paul Andersen: Yeah, that would be obviously out of the scope of the policy. It’s tough. Normally the Board would not weigh in on it, nor am I suggesting we will now on a policy in draft, but obviously if this was to – a policy like this was to progress, there would be staff analysis, legal analysis, and we’d probably, I’m sure, have a lot of questions about that, too.

We’re going to close the microphones after this speaker. This is the last one. Please get in the line if you want to speak.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. When thinking about this problem more, I remembered that in the US the FCC auctions off bandwidth radio frequency.

This feels very similar to that process in a lot of ways, but that itself is not a great policy in many people’s opinion. It really does allow the space to be consolidated in ways that I don’t think ARIN wants to see the v4 address space consolidated.

So I think there’s been some arguments towards similarities to that, but we should – I would caution against making that type of analogy.

Speaking to the point Dave mentioned is that, yes, we would definitely want to understand more about where the revenues would go, but that conflicts with the guidance that financial discussions and financial directives are explicitly outside the scope of the NRPM.

So I don’t have a good answer on how one would resolve that, but if someone has suggestions, I’d like to hear it.

Paul Andersen: Microphones are now closed with the last speaker from John Sweeting.

John Sweeting: John Sweeting with ARIN. I’d like to make a couple points about the waitlist suspension that I’m going to cover in my department presentation tomorrow, but since there’s a lot of people here and we’re talking about the waitlist.

So I want everybody to know that – so the waitlist suspended a very specific portion of the waitlist. So it was the distribution from the waitlist. We are currently accepting, processing, approving, placing people onto the waitlist in accordance with how we put them on the waitlist.

The only thing we’re not doing is we’re not distributing from the waitlist. However, we are still doing all the internal procedures that we do to get ready to distribute from the waitlist.

So once there’s a policy in place that allows us to do that, we are ready to do that following that policy.

The only other thing I’d like to point out is part of that policy that was suspended was that if you get something off the transfer market, you get removed from the waitlist. That’s suspended.

If you go to the transfer market to get through this period, we are not removing you from the waitlist; however, you will have to answer to any space you get and show that you still qualify for whatever space we’re going to issue you.

Paul Andersen: Thank you for that clarification, John. That’s handy. And thank you, Alyssa, for the presentation.

(Applause.)

So I know that we kind of – we first had the general summary discussion, then we had each individual that was in there. We do have an Open Microphone later; so if you’ve had thoughts on earlier proposals, that would be the good time to bring that up. But, otherwise, I will turn it back to John.

John Curran: So we’re going to continue our trend of pulling things up in the meeting so we get out earlier.

To that end, we have finished the policy block, and the next on the agenda is global reports with Axel Pawlik coming up for the RIPE NCC.

Global Reports: RIPE NCC

Axel Pawlik: Good afternoon, people of ARIN. My name is Axel Pawlik. I’m the Managing Director of the RIPE NCC, which is ARIN’s cousin organization over there in Europe. It’s moderately warm and rainy. So I’m grateful for the chance to be here today because I like it cold. Reminds me of Siberia in here.

(Laughter.)

And we have the RIPE NCC Moscow Day today, so part of my colleagues are over there. I think it’s warmer than in here.

Update from the RIPE NCC, what are we keeping ourselves busy with.

Focus for this year, some new and some not-so-new things on there. We are continuing to prepare and dealing with strong membership growth and what we think will be a bit of a falloff or at least of a slowdown after the v4 pool is finished up.

We, of course, continue ensuring and working on the accuracy of the RIPE Registry. We look at due diligence, fraud prevention – I’ll talk about all this in a little while – value added through training service, and major developments in there.

Of course providing neutral information not only to our members but – and academics and the like, but to governments, regulators, the police force as well. And, yeah, looking at K-root, strengthening the infrastructure there.

Talking about law enforcement, one of the previous discussions about policy was, well, cranking up the quality of stuff that is in the database.

So you’ll see validation information occasionally is outdated, not functioning properly. So I think basically law enforcement came in and said, Hey, we would like you to focus on this.

There was a healthy Policy Development Process and discussions. We arrived at consensus there. We have been asked to check abuse contacts in the database and to follow up with resource holders to fix outdated information.

Yeah, we have hired a couple of people to do this. It’s work-intensive potentially.

Implementation started in February this year. What we’re doing is we do some automated checks, and where needed, and that will be needed, we will do manual intervention, contact people, and make it better.

Talking about training, we do training calls. We do training calls for a long, long time. They are exceedingly popular. Face-to-face training is great. Gives us feedback from our members. We do webinars, we do online stuff. All the documentation, all the material is freely available.

It’s great, but we don’t think our members get the most out of it. What we do is we give them certificates that they attended the training. But, yeah, they are maybe dubious in benefit, really, because you can come and collect your certificate and go home that says that you have been there.

That’s great, but – so we want to improve that, and what we’re looking at is what we will call most likely RIPE NCC Certified Professionals. And what we will do for that is looking, having a hard look at the identity of the candidate doing the exam and to have sort of basically online remote proctoring for this kind of thing.

We are in the process of setting this up. We’re dealing with a third party there for the proctoring. But of course we need material, questions and the like, that is useful for those things.

We did quite a bit of outreach to our community. Now we are doing extensive, as I said, job task analysis to get the questions right and relevant for the task. And, yeah, that’s what we’re looking forward to.

So the idea is, like I said, content will be remaining available for everybody, but the taking the proctored exam will cost some money, or our members will have vouchers for that. It will be available for non-members.

So we do this assessment platform. We’ll have people watched through their web cams in a secure environment. We might also – we probably will also have sort of online kiosks at our events to be used for this.

And what you get out of that, then, as the successful participant is have online digital badges that you can use that actually show that you personally did this exam and that you were successful there.

So we are looking at quite some ratcheting up in our training services.

RPKI remains an interesting topic. We’ve seen that here today. We have done a couple of hack-a-thons over the last couple of years that typically are quite popular and people come and like them.

So we thought we’ll do something similar with an RPKI Deployathon. So we brought professionals in giving talks and basically running through the whole process of setting up a validator and configuring routers and just playing with the thing, really, and we teamed up with Juniper in their offices in Amsterdam. So that was a fairly popular event as well.

Talking about policies, oh, yeah, that’s an interesting one, a newish one, the BGP hijacking is a RIPE policy violation. For years and years and years our community is saying, oh, the RIPE NCC is not the routing policy.

So some people are putting that into question. And that’s very lively discussion about this thing, at least like three different factions talking about things. Very interesting to see.

Then we have a proposal reducing IPv6 allocations to a /24 after we run out of /22s, and that would mean that we sort of picked things together and, yeah, give out smaller ones from the address pool that we have gained by returns and the like.

And some other stuff, basically housekeeping.

So, yes, we also are approaching IPv4 runout. Our membership, of course, is growing. Unprecedented growth again. So we think we’ll run out probably in February next year, depending on undergrowth and last-minute activities there, maybe, but earlier even. We’ll probably have about 24,000 LIRs by the end of this year. It’s all a bit crazy.

Yeah, the address pool is running out. That’s not unexpected, but it’s going to happen. Lots of transfers are happening. Like what we have there, like 500 per month? That is quite a bit of work.

And of course things are also tightening up. I’ll talk about that in a while.

So the last /8 is gone, and we are now allocating from the returned addresses that we have received from closures and the like.

Like I said, when we can’t do contiguous blocks of /22s anymore, then we’ll just find little bits and pieces, put them together to the equivalent of /22 and give them out. And if you can’t do that anymore, then that’s it. Like I said, February 2020 most likely. Or somewhat likely.

So there’s lots of things that we are thinking about here. So how can we do this? We have to do this transparently, of course, and efficiently, but also in a way that is fair. And what precisely is fair? Waiting List? Do we do a Waiting List? Don’t we do a Waiting List? How do we do this?

Of course then we’ll have to adjust our software. That’s work that needs to go into that as well, and talking about it and keeping input from our community and how to do this.

So community aspects. So should we extend the lifespan of v4 or rather not, ongoing debate for already 20 years probably. Complexity, routing table. Is that something we’re seeing? Maybe not. But certainly but we are seeing is new kind of actors in the Policy Development Process, basically in the community.

Back 20 years ago everybody was working together for the good of the Internet, and we were all very happy, all the same goals, and now we certainly see new people coming there that have their own goals.

Of course, also what we see that’s a good thing is involvement of governments, of law enforcers – so “competent authorities” I hear is the word – that look at this IPv4 thing and how we deal with this, how the community deals with it, what the policy process – Policy Development Process is, what form, what shape it is taking these days. So that’s all interesting.

For ourselves as the registry, thank God we said early on: Transfers are fine, go transfer away, but keep us informed. The registry is important. We need to know who is using which address space. And I think that we were quite successful with that.

Of course, yeah, dynamics between our members and ourselves. We are seen occasionally as being the tough bastards that ask awkward questions, and that’s something.

Like I said, new kinds of people are coming. The community is – members of the community are starting to shout at each other and are calling each other names, and that’s not so nice.

We have people, clearly speculators, we have maybe hoarders. We do have hijackers. We have crooks and people who show us falsified passports and other documents to get their grubby hands on the last /22s that abuse the system.

We think that’s system abuse. That’s against the spirit of the policies.

So, yeah, we have to find the right balance, be strict, be tough, but also don’t bother our good members – our members in good standing that just need to get the last couple of addresses for themselves for legitimate purposes. Difficult tightrope to walk.

All right. Different topic. Survey. We are doing community stakeholder membership service for a long time. The next one is coming up. It will be launched in May at the next RIPE meeting.

Last survey was quite successful. We got input from 4,400 people. But we have many, many more members. So we tried to get more feedback there because this is important for knowing what we should be doing and how we could improve.

So that’s also, of course, the last survey before we run out of IPv4. I don’t know how particularly important that particular point is, but might be. What should we do afterwards?

We tried to keep it short, keep it simple, keep it quick so we get more responses. If you happen to use our services, please do respond when that happens.

We use, by the way, the same people that APNIC has been using. There’s always a bit of, say, synergy in doing this, and, yeah, we’re quite happy so far with the support we were getting there.

Oh, yeah, we’re going to Reykjavik in May. That is soon. Of course, you’re welcome. You know there will be parties without end. Also drinks will be quite expensive, but it’s all worth it because it’s 30 years of RIPE community in May.

30 years. I wasn’t there in the beginning. I don’t remember anything of that. But the community has grown a little bit from the early days. So you’re welcome to come and celebrate and also, of course, work with us as regular.

So if you have any questions, I’ll be here for the rest of the day and during the coffee break. Thank you.

John Curran: Thank you.

(Applause.)

Most excellent. Everyone should have a waitlist policy. You’ll be tweaking it forever.

(Laughter.)

So I’ll now ask the next up for reports, is Kim Davies, to come up from the PTI and give the global report for IANA/PTI.

Global Reports: IANA/PTI

Kim Davies: Thanks, John. My name is Kim Davies. I head up the IANA team. IANA is provided by PTI, which is an affiliate of ICANN.

I heard it described earlier today that operations are boring. That’s a high compliment from where I’m from. If we can keep staying boring, that’s a pretty good sign.

This is the team that provides the IANA services. We currently have 17 people on our team. The way we operate is a lot of people work on a lot of different things; so many of these names are probably recognized by people who use the IANA functions.

I want to update you briefly on some of our customer satisfaction work. First is our Customer Satisfaction Survey. Annually we try to poll all of our customers to try and get a read on what we’re doing well, what we can improve on, and any ideas for future prioritization.

We segment our customers and we poll them in different ways when it comes to number resources. Our customers there are the RIRs. We send the annual survey to the CEOs of the five RIRs as well as the Registration Service managers.

This year the participation rate was 25 percent, which is 10 percent lower than the previous average. That being said, we’re talking about very small numbers here, so I wouldn’t read too much into that.

Importantly to us, those that did respond were satisfied. So we got 100 percent satisfaction rate, which is positive. And no one reported any specific service issues that they wanted to highlight to us in the previous 12 months.

Each customer group is asked to rank the different attributes of how we deliver service, and usually they’re quite consistent across all our different customer groups. Accuracy ranking highest usually, and timeliness of our services is another priority area for us to focus on.

With that all being said, one challenge that we’ve had doing these annual surveys is often that the customer groups that we’re polling had their interaction with us way in the past. Might have been up to 12 months earlier.

So asking them to recall how it went, what their experience was like often results in some scratching of heads, and we often get explicit response saying: Well, don’t really remember what it was like. Not so much with the RIR group, but certainly some other customer groups.

One thing we’re transitioning into is really polling or customers directly after interaction. That’s something new for 2019. I’ll get to that in a moment.

In terms of the actual results of the overall survey, 96 percent of the respondents reported being satisfied or very satisfied. In fact, this year we had the highest satisfaction rate since we started this survey I think six or seven years.

I won’t dive into the specific numbers. They’re there on the slides, and you can look at them themselves on your slide, and they’re also on our website.

So we’ve called the tool that we’re using to do these satisfaction surveys directly after an interaction – we call it “How did we do?” Quite simply, that’s the question we’re asking. It’s a very common design pattern. You’ve probably all seen in various different interactions with different companies.

The idea is we just send a simple one-question survey to our customers and ask them a simple question: How did we do? Did we do well, or is there room for improvement?

Optionally, once you provided a response, there’s a comment field. If you felt there was some actionable follow-up or perhaps a clarifying question, we provide room for that.

But this is something new that we now send to our customers after we’ve finished a request. We only poll people once in a period. I think it’s currently 60 days. We don’t want to bombard some of our more regular customers with constantly surveying them. And, of course, customers can easily opt out permanently if they don’t wish to receive these.

In terms of our SLA performance, we’ve hit our SLAs throughout the last 12 months and longer. All that SLA performance is on the website. As you heard earlier, there is an annual review committee constituted to look at that performance over the last 12 months and report how it’s doing, and the most recent report was favorable.

We don’t do a lot of change requests for RIRs compared to our other areas of work. So it’s a fairly small mission, but nonetheless it is important and we strive to meet all the SLAs that have been agreed with the numbering community.

I did want to take this opportunity to report an issue that we did have in the month of February. It’s not on the slides. But we operate a reverse DNS service that is used by the RIRs to publish PTI records in both the ip6.arpa tree and the in-addr.arpa tree. This is a system that only has access rights for the RIRs.

And we did have an outage of that system for a couple of days in early February. The root cause of this issue was that we were migrating that system to a new platform, essentially upgrading the operating system and moving virtual machines.

But one consequence of that is we restored an older snapshot of the data that was in that system, and this caused a number of knock-on effects that, once identified, were restored into operation.

Nonetheless, this, in my view, doesn’t meet our standards that we strive to achieve. So it’s something that we’re identifying the gaps that led to that issue and we’re seeking to correct.

We’re in dialogue with the NRO ECG to identify anything from the RIR perspective that they would like to see done differently in the future. But it is something that happened in February I wanted to share with you.

One thing that’s important in our operations is audits. We have third-party audits of our assignment practices as well as our DNSSEC operations.

This is one area where we feel that having a third party come in and analyze the way we do our operations, all of the security controls that are in place, as well as operational controls, is important to give confidence to the community about how we do our work.

It’s, in fact, something that was subsequently baked into a lot of our contracts we have with the community groups and we report on annually.

We just completed our 2018 audit cycle in the last few weeks, and I’m happy to report that our principal audit that is of interest to this community, which is what we call the Registry Assignment and Maintenance Systems, were successfully completed with no exceptions.

And also additionally we do an audit of how we manage the root zone KSK. That was also issued with no exceptions for 2018.

So no rest for us. We’ve already kicked off our 2019 audit program in the last few weeks. The framework that we used, in this case SOC2, has added additional new requirements for 2019, so-called COSO framework. So that’s something we’re working to integrate into our operations over the next few months.

One thing new that we’re working on specifically for this community is a new dashboard for RIR allocations. The way that we’ve done this in the past is a lot of the data that goes into our analysis of whether an RIR is eligible for new allocation has derived from a dashboard that was actually more of an R&D effort by another part of ICANN.

And as is often the way over time, over several years, it’s come to be dependent on not just by us but by RIRs as well to quickly see the state of resources for the purposes of working out eligibility for future IANA allocations.

That being said, that website was quite ancient. It was driven by Flash, for example. And it wasn’t being adequately maintained. So we’ve gone back to the drawing board and sat down with our RIR customers to work out what should replace it, and we’ve come up with a new approach where we have a dashboard that is specifically targeted to displaying RIR eligibility for number resources.

This is now actively under development. Here are some screen shots of our internal working system. It’s still got some bugs and things to be sorted out, but we expect to be launching it relatively soon.

But essentially it lets you look at IPv6 and AS number allocations, eligibility, projections towards when specific RIRs will be eligible and so forth.

One thing that’s missing there is IPv4, but as you can imagine, since we don’t really have anything there to give out, we’re not planning on having an IPv4 dashboard.

Briefly, I’ve already touched on this, IPv6, we show state of the RIR pools, growth of IPv6 addresses allocated in different regions.

What we did do is identify things that don’t pertain to IANA allocation policy, and we’ve stripped them out of the dashboard. So it’s now focused just on the task at hand.

And this is just a mockup. It’s not indicative of the final result, but we do intend to show projections so that we can sort of identify in what time window we expect RIRs to be eligible for another allocation.

Speaking of allocation, our actual allocation activity for IPv6, we made an allocation to the RIPE NCC recently. One thing that is notable there is that we only allocated a /22.

This was at their request in order to fill a gap in a larger allocation that was made prior to the implementation of the global policy in 2006.

We received the specific request. We validated with the NRO AC that this was an appropriate application of the policy, and we agreed that it was appropriate to proceed. So that was done last month.

IPv4 allocation. Well, this pretty much summarizes the situation from the IANA perspective. For those that aren’t aware, we have a recovered pool, essentially IPv4 addresses that were returned to IANA, and there was a global policy for post-exhaustion IPv4 allocation.

In essence, every six months we went into our recovered pool, we divided it into fifths, and we allocated what we had in our recovered pool to the RIRs. With each subsequent allocation every six months, what was in that pool shrunk and shrunk and shrunk. In March 2019, we gave each RIR just two /24s each.

As a consequence to this, we now only have three /24s left. And since we can’t really practically divide that into five equal pieces, it essentially means that this policy is exhausted. Unless we get more IPv4 returned to us, there’s really nothing more for us to give, according to that policy.

So that’s it. Happy to take any questions, and I’m also around throughout the rest of the day and happy to speak to anyone.

John Curran: Any questions for Kim?

(No response.)

Thank you, sir.

(Applause.)

So we’re sitting here with a pretty substantial amount of time before the break, and I could just keep pulling proposals forward, or we could break.

I think we’re going to break because we had the hotel set up a little early. So we are breaking, and use the time to catch up with one another.

We’re going to resume promptly, 3:30, here, and we’ll finish up the afternoon presentations. Thank you. I’ll see you all at 3:30.

(Break from 2:33 PM to 3:30 PM.)

Caribbean Update

John Curran: If folks will come in and get seated, we’ll get started. I’d like to welcome everyone back after the break. I see you all refreshed and energized. Nothing like seeing a little sunshine and a little sand and having a cup of coffee.

We have a few presentations and then Open Microphone, and we will be done for the day. First presentation is Bevil Wooding is going to come up and give our Caribbean update. Come on up, Bevil.

Bevil Wooding: Good afternoon, everyone. All right. Today I’m going to give an update on what we’re planning to do in the Caribbean, and of course all of this will be against the backdrop of our 2018 activities where we launched the ARIN in the Caribbean series of events and we also launched the ARIN Caribbean Forum.

Over the past 12 months or so, we have had intensified outreach to the Caribbean territories. We’ve also identified several groups that for the first time we’ve been creating specific outreach to.

That will include the technical community in collaboration with CaribNOG; the ARIN Caribbean Forum Justice Sector group, which we have been doing in coordination with several security-based agencies in the region; and of course, the ARIN Caribbean Public Policy Forum, which we’ve been working with the Caribbean Telecommunications Union to conduct.

As many of you have noticed, all of this is happening under the harsh conditions that you see around you and outside. So it has been a very intense period. The glare from the sun can affect your eyes. That high-level humidity can affect the productivity of work done in the Caribbean.

So I just want you to know that we’ve been toiling on behalf of the ARIN community to ensure that the ARIN flag continues to fly in the region.

So for 2019, what are we looking at? Essentially building on the foundation. Things have gone very well with the outreach structure and the outreach strategy.

So the idea is to continue deepening the collaborations that we’ve had with parties in the Caribbean and to focus even more intently on capacity-building initiatives.

The reason for this is because the service we’ve done and the events we’ve conducted have all indicated an interest in understanding more about how to deploy number resources, how to build out networks.

In discussions I’ve had with counterparts in the ARIN community in North America, some of these issues that have been identified in the region are not exactly priorities for the North American network operators.

But as we have gone out describing what ARIN does, and as we’ve gone out indicating what number resources can and should be used for, we’ve had repeated questions about how do we learn more about deploying autonomous networks and how do we learn more about building out v6 networks.

And so for 2019, we want to focus our activities on these emerging network operators and ensuring that they’re properly resourced in fundamental topics that address those issues – IPv6 deployment, ASN, both how to apply for it and how to appropriate it in the network.

On the policy side, continuing to work with the CTU and governments in the region to look at the policies to support expansion of networks in the region, and, of course, continuing to work with law enforcement and public safety agencies on Internet security.

Now, this is going to look like this. Essentially the ARIN Caribbean forum, which was launched last year, is going to be the vehicle through which several of these outreach programs in 2019 will be conducted.

This will involve new programs and new content being developed. We have started discussions with the Caribbean diplomatic community, and we have had initial conversations with judiciary and public bar representatives to discuss how to bring greater awareness to those stakeholder groups of what ARIN is doing and what RIRs do generally.

We also have had ongoing conversations with the CTU about working even more closely with governments in the region so that governments can be champions of appropriate and effective network utilization and number resource utilization.

They have the largest networks, they employ the greatest number of staff, and they touch the most groups of any group in the region. And so that outreach to governments is expected to continue, as our work with the law enforcement groups as well.

So what you can look for in 2019 will be more of these community development initiatives that we started in 2018, more Public Policy support work in conjunction with the CTU, and of course more justice sector collaborations.

The two channels through which this will be done will be the ARIN Caribbean Forum and the ARIN in the Caribbean events.

We’re trying to ensure that we touch as many of the ARIN territories within the Caribbean region. For us to do that, we can’t fly or visit physically every one of these territories. So we’ll be making even greater use of virtual meetings to ensure that we at least have some kind of touch point with the various countries in the Caribbean.

And a lot of that will be initiated this week as part of the extension of this Public Policy and Members Meeting.

Tomorrow afternoon we’ll have our second law enforcement group meeting, and that will be a half-day meeting with representatives from security forces here in Barbados and from around the region, with their counterparts from North America, and also with input from our fellow RIR representatives here in Barbados.

That meeting is going to be an important next step for deepening our ties with the law enforcement and public safety community.

For the Public Policy group meeting, which will be held on Thursday all day with the CTU, we’ll be taking a look at some of the work that Anne-Rachel has done, and she’ll be describing that in the next presentation.

And we will be comparing and contrasting what is happening on the global stage in terms of Internet policy with what the Caribbean needs to be focusing on, what the Caribbean sees as its priorities as part of the evolving Caribbean Internet policy discussion. That takes place on Thursday.

And of course, CaribNOG starts tomorrow and runs until Friday. And in that meeting, a lot of these same issues about emerging networks, we have – together with the CaribNOG team, we have identified these issues of IPv6 deployment, cloud security, et cetera, and those have fed their way into the CaribNOG agenda as part of our ongoing collaboration with that network operator’s group.

So what you’ll be seeing this week essentially is the first steps in 2019 toward creating those focal points around the topics that were identified by ARIN community members as important to them here in the Caribbean.

And then coming soon, following up this week of meetings, we’ll be doing a State of the Internet dinner, which John is actually supposed to keynote. That is part of the CTU’s 30th anniversary celebration.

And many of you know, we’ve had a long relationship with the Caribbean Telecommunications Union. That continues with our involvement in their 30th anniversary plans.

And the State of the Internet dinner is, again, a chance for us to speak to high-level officials about what’s happening on the Internet, the role that ARIN is playing, and what can be done to participate in the policy and development process.

Then Bahamas later in June, we’ll be having an Internet Week together with ICANN and ISOC, part of our deepening of our relationship with those organizations and their work in the Caribbean.

And then the Caribbean Peering Forum is also in June in St. George’s, Grenada, and we’ll be there to talk about number resources and Internet exchange points.

So you get a sense of what’s happening and how we are building out this emerging network priority, continuing what we started last week with network resilience and security, but also, and very importantly, finding mechanisms for not just having events in the Caribbean but strengthening the ARIN community in the Caribbean. That’s going to be a key for our focus this year.

So what we’re looking at is increasing our Caribbean participation, but we also, at the same time, are focusing on supporting Caribbean Internet development.

And that’s your Caribbean report. Thank you.

(Applause.)

John Curran: Microphones are open for any questions. Thank you.

Okay. Next up we have the Governance and – Governance Affairs and Public Policy update. Anne-Rachel will come up and give that.

Government Affairs and Public Policy Update

Anne-Rachel Inné: Thank you, John. Good afternoon, everybody. So this is an update on some of the things that we’ve been doing internationally.

So we’re the face of ARIN outside in government engagement and all of the international organizations that are talking about the Internet. As you can see from this slide, this is basically what government engagement is supposed to do, improve working relations in ARIN region and globally.

So when we go sit in ITU – it’s funny, this morning, when we were having the discussion around RPKI, it reminded me of how, when John was talking about how he can see himself talking in front of the jury having to advocate for RPKI, I felt like this is very much like how I feel every single time we get a question up at ITU or OECD: If you do, you’re doomed; if you don’t, you’re doomed.

That’s really what happens every single time when we go there. So we try to make sure that we keep John and the executive team apprised of what is going on internationally so we can react also effectively with the Board and all of you here.

So I’ll talk about most of the meetings that you see here. And before I talk about PP, I’m going to just give you an anecdote that just happened yesterday.

I am part of a group of folks that from time to time give online trainings to government. And the first week is always devoted to telling them about the infrastructure – what is the Internet, how it works, and all of that.

And yesterday we had to basically go and look into a question and respond to a clarification on what is a packet as opposed to a package.

You know, you get – yeah. So you get a package to get connected to the Internet from your provider, you know, your connectivity provider. And then you get packets, you know, when on the infrastructure.

But English being English, you also – when you have a package, you receive packets. So it was quite a little love that we had yesterday trying to explain infrastructure on which it can get package and packets both delivered. So it’s part of the, you know, having to explain how the infrastructure works.

So going back to ITU, International Telecommunication, Plenipotentiary 18, some of the most salient points for us, well, the geopolitical rift state. I think you all know that we are still at the point where we have a lot of people who believe that telecommunications today should include Internet and others who believe adamantly that it shouldn’t be the case.

So that rift is still there. And whenever we talk about telecommunications, it’s always hard to kind of see where do you stop in talking about telecom and where does the Internet come and what do you include or not in there.

So the discussion, then, basically continued, and we had very long hours and pretty contentious language in all of the Internet resolutions that are at ITU.

We ended up having minor edits in Resolutions 101 on Internet protocols; 102, Internet protocols and names, domain names; 133 around international domain names; and 180 that is specifically talking about IPv6 that got a title change that was – that is now called promote and deployment and adoption of IPv6 to facilitate the transition from IPv4 to IPv6.

Long title to accommodate everybody and make everybody equally unhappy. That’s what success is deemed to be in the government world.

So the reason why I’m telling you about the rest of the resolutions that are here, one is an OTT is that, again, out there when you talk about the Internet, and mostly to regular folks, including a lot of government people, Internet is a monolith. They don’t make a difference between Google and ARIN. They’re all the same.

For them it’s the Internet. Okay? So if you say OTT, it means somehow, somewhere we’re all included. And that’s the reason why we have to be there to say no, no, hold it, this is how it works. This is the layer above. This is what we do.

And, by the way, I was also a little – I was smiling to myself listening to the conversation about monetizing IPv4. If that was to ever take place, it would put us squarely into what is happening on the discussions globally around taxation, because we would be making money.

So these are all things that we have to always be reading very carefully. When people say the devil is in the details, I say the devil is in where the comma is placed. That’s how it works in government language.

So when we’re talking about OTT, it depends on where they put the comma or where the telecom stops, what could be deemed Internet starts. And then it can be either relevant or not for us.

There was a possible merger, two council working groups that was proposed, and finally didn’t happen. But at least we got instruction to streamline resolutions.

When you go to ITU – so ARIN is a member of ITU-T, the standards sector, and ITU-D, the development, where they do a lot of capacity building.

Well, if you take IPv6, when it’s the standards, in the standards world, they’re talking about how to do IoT, how to do everything that can go through the Internet v6 tomorrow.

And in the D sector, we get to talk about capacity building, how do you get to tell people about how to actually implement, deploy v6 and all of that.

And in between we end up having work streams that are lengthy, that take a lot of time, that take a lot of energy, that take a lot of money, because, believe me, Geneva is not the cheapest place to have meetings, and we have to be there constantly to explain no, no you can’t do this.

Actually, if you put this type of language, you are saying you are going to be doing policy for IP addressing. Sorry, this is not your job; it is ours. We’ve been doing this – this is actually the community. This is where people should go do it, not here, and so on and so forth.

Cybersecurity, you heard from APNIC and everybody, it’s all over. Security is up to whom you ask, to be honest, today. And artificial intelligence was something that was very contentious because of course it involves anything that – all the talk from data privacy to name it. And today we’re in there because, yeah, we’re part of the talk about who is and what goes in there and all of that.

So Council Working Groups, just to give you an idea, we have a Council Working Group that is called Council Working Group Internet. It’s basically international Internet public policies related to the Internet.

And traditionally this is a working group where the council members – council on ITU is the body that in between two plenipots, so in between four-year meetings, basically expedite the work at ITU as the highest body.

So in the group that is talking about the Internet, traditionally they have talked about anywhere from what has happened with these policies, generic policies on the Internet to – this time, for example, one theme they wanted to talk about was IPv6.

But even that, being like the least controversial item, couldn’t get them to agree to talk about it because they came out of plenipot with the position I was telling you about, and quite a few were for and quite a few were against.

So the full council that has been meeting in two months, in June, will have to decide what this council working group is going to be talking about for the next year.

We have the same council meeting in June. We’ll be deciding on the ITRs, so the International Telecommunications Regulations, Working Group. The last one couldn’t agree on do we do revisions of the International Telecommunications Regulations, of which we’ll have two sets, one dating from 1998, and I think a lot of you remember what happened when we got the 2012 ones, which is ITRs 2012, where we got the real contentious issues and the total split in opinions.

So council will decide the expert working group and also something called the expert working group for the World Telecommunication Policy Forum. The World Telecommunication Policy Forum is just a meeting that happens episodically. The SG calls for it, the plenipot agrees to it, and then council decides.

And they have decided it’s going to take place in 2020. Actually, plenipot decided it’s going to take place in 2020, and council will now decide on what we are going to talk about at that policy forum.

Thank God it’s not a policy forum that comes out with policies that are mandatory. It’s multistakeholder. We can put papers towards that, and we all get to participate as we actually participated in 2013 at the last one.

And then we have this year the anniversary of the WSIS Forum, and also we have the WSIS Forum working with the UN High Level Policy Forum at UNGA, the United Nations General Assembly, to have a theme this year that is about empowering people and ensuring inclusiveness and equality.

Make no mistake, inclusiveness and equality may sound like something just mundane, but it is talking about all of the issues that you’re seeing that are talked about, for example, algorithms and issues that people are having behind algorithms, fake news and all of this stuff. This is – all will be debated at the High Level Policy Forum.

ITU-T and the work that we do there. We participate mostly to Study Group 2, Study Group 20, and we monitor very closely – when I say “we monitor very closely,” we mostly participate online, so very early days for a lot of times for Einar and I, because Geneva is six hours ahead – and we try and participate as much as we can in Study Group 3 and Study Group 13.

13 because it’s all about future networks and what they call trusted network infrastructure as opposed to probably ours that is not that trusted at the moment.

So you have new ideas on actually platforms that could either work or not work with TCP/IP or DNS and all of that, and you have quite a few people participating in the focus groups and Study Group 13.

And we participate in the TSAG that is basically, again, in between two plenipotentiaries. TSAG is the one that basically collates all the work that the 11 study groups in ITU-T are doing.

In ITU-D, we just finished the work of the first meetings of Study Group 1 and Study Group 2. And TDAG, also. And we got a lot out of there on IPv6 and capacity building going forward.

So we’ll be going to CITEL, and I know that Kevon is here and he talked to you about some of the work that they’re doing. We will all be talking to CITEL and the Organization of American States where we participate because they have a lot of capacity building initiatives on IPv6 and networks and resiliency in general. That has become a really big thing in the whole region because of emergency telecommunications in general.

Some of the conferences that we will participate in or not, actually, in 2019. So GET. Bevil was in Mauritius lately to talk about some of the work that we’ve been doing in the Caribbean on helping in resiliency of networks.

And we were not the only ones. AFRINIC was there to also talk about some of their work they’re doing with their island states. And I know that APNIC has been working also with the regional office in the Asia-Pacific on the same issue.

We will be participating into a Global Symposium for Regulators, where the theme this year is inclusive connectivity and the future of regulation.

One of the issues that we keep having is a lot of the policies that ITU-D and DOS and, you know, takes out there for regulators to implement often have issues just because the regulators themselves don’t really talk to the community on the ground, do not really know sometimes where implementing a policy can break a system, so on and so forth.

So we do work with them as closely as possible, because they come as much as possible to Geneva for study groups, either in T or in D, and we really try to work with them on that.

Radiocommunication Assemblies and Radiocommunication Conferences will be in October and November of this year. These are mostly spectrum. So we don’t go to those. But we monitor because the end product of whatever it is that comes out for these devices that are connected afterwards, anyway, touches us.

So OAS CITEL, as I said, we work with them, and we have a working group on policies and regulations. We will be putting two contributions to them that will be around IPv6, but also some of the issues that we have seen in Study Group 2 and Study Group 20 at ITU, because it is the regional work of what is going on globally at ITU is taken down to the regions by OAS CITEL.

So some of the issues that we see with some of the governments like Canada or even the US and Brazil and others, for example, we talk also about in there to say: We’ve seen this. It will be important that you take some other factors into account if you’re doing that for the region.

Working group on deployment of technologies and services. Again, if they need here training, we’re there to provide that with LACNIC.

And we have a working group on preparation of conferences where basically the region sits and look into what is happening, what has happened, for example, at World Telecommunication Development Conference that was at 2017 at plenipot, what were the resolutions that were deemed important for the region, how do we translate them on the ground, and how do we collate them into the World Telecommunications Standardization Assembly or the future work on the International Telecommunications Regulations and so forth.

We go with all of the technical community. The technical community is – actually participates into the Organisation for Economic Co-operation and Development, OECD, as ITAC, the Internet Technical Committee, at OECD; includes ARIN, ICANN, all of the RIRs, I think, and IEEE and a few others.

So we participate in the discussions on going digital. We have participated in going digital. The Going Digital Project at OECD, that has been happening for the past two years.

And what that entails is we just finished with a final synthesis report. We have a publication on measuring the digital transformation, and there is a Going Digital kit.

In the meantime, what has happened, and it’s going to continue, is that we have all of the OECD member countries agreeing to look into all of their sectors at home to see what is it they have done in terms of connectivity, policies, e-commerce, name it, everything that is digitalized today and how well they are doing according to what is in the synthesis report that we came out with.

It was kind of surprising to see, for example, some of the European countries that were the first – one of them particularly that was happy to play the game and be the first one to be audited, quote/unquote, by themselves and their full community at home, who were the first adopters of v6 to completely plateau today.

And some of the things that we got out of that audit, national audit that was done by themselves was to see that even in places where you have not only government but industry willing to go for it, there’s always roadblocks in terms of if it is cost, if it is just simply, for example, this country is a federation.

So they have things going a little bit like in the US. So federal, state, local, governments and all of that, and people just putting different priorities onto what they want to do, which just today has put that country at an average level of adoption of v6.

So it will be interesting to see what the others come out with in the same vein.

And, yeah, so another theme that we’re following at OECD is the taxation one, where you have more than 100 countries that are agreeing to work towards consensus-based solution. And in there I promise you they’re looking at the chain of actors in the Internet, anywhere from, yes, the IP addresses to all the rest.

So if we were to be again looking to monetize IP addresses, I think we’ll be looked at a little bit more closely than now.

United Nations. Well, United Nations also is beginning to talk about the Internet today. At the Third Committee of United Nations General Assembly, you have major developments.

Two resolutions on cybersecurity were adopted last year – one proposed by Russia, the other by the US. And both were voted on, both were adopted.

One has a group of experts, the UN Government Group of Experts, to be piloted by the US. That is continuing. It was something that actually has been going on for the past at least four years. That never really got to have consensus.

And Russia has proposed the Open-Ended Working Group that is right now in the process of also being formed, and we’re not too sure what is going to give.

Again, as I told you, cybersecurity really means anything and everything to people. It depends on who you ask. So we’ll see what that gives.

And we have a range of Internet-related human rights issues. So in there it’s about looking at the accountability processes, are we responsible when we give an ISP a block of IP addresses and those are used to do bad stuff. Where does our accountability start and where does it stop?

Same if you look at, for example, the issue of IP addresses monetization. Regional Internet Registries say we manage that space. So why is it that people get to sell IP addresses when – we were having the same discussion this morning – when you guys have said from the beginning that these are not to be monetized; that any of the identifiers that are not used should come back to the global pool.

So these are some of the issues that we’re facing every single day in terms of accountability and all of that. And that’s why we also have to be part of the discussion and make sure that people understand that, yeah, well, things have evolved, and maybe we just should all sit around and talk about the future of this space together.

So the First Committee of the UNGA has development of international norms also in cyberspace. The 73rd session of the United Nations General Assembly that is happening now is significant in quite a few ways.

It has 10 resolutions that are addressing Internet issues – two on security, two on sustainable development, two on human rights, four on human rights, one on crime, and you have the cybersecurity and cybercrime that I talked about.

You have also the geopolitical dynamics whereby, well, we’re talking about things that should be all discussed together, all of us together.

What you hear more and more at UNGA is sovereignty. I’m sovereign; I can do what I want. This is my jurisdiction; I can do what I want.

So, to be honest, at the moment, we’re not too sure where this is going to lead us, but it’s out there.

So what happens to the multistakeholder model? Really not sure going forward.

Other UN organizations where talk of Internet is happening, we have the WTO. Again, taxation. What is e-commerce? What are services on Internet? How are they taxed? Which ones should be taxed? Which ones should not be?

This is all being reflected right now in the talks about e-commerce at WTO.

UNCTAD is talking about digital economy, taxation. Again, meetings on trade, services, development. Helping more on the best practices, but still we absolutely need to monitor that and see what is being said, what is being taken forward.

And then we have the United Nations Secretary General High-level Panel on Digital Cooperation that was put together last year. That will have its report soon in June.

So we’ll see what that report says and what is the view of going forward, talking about all of this cooperation about going digital, what does that mean, who should be there, at what level, how do we take it forward.

And other activities on Internet governance. Global Forum on Cyber Expertise, the GFCE. That is about awareness and understanding among the various cyberspace communities.

Internet & Jurisdiction that some of you know, that talks about jurisdiction and data, jurisdiction and content and domains and jurisdiction.

There is Microsoft’s Tech Accord, the Paris Call for Trust and Security in Cyberspace, Tim Berners-Lee’s Contract for the Web, Siemens’ Charter of Trust, the International Conference on Cyberlaw, Cybercrime & Cybersecurity.

And they really come by the day. So in between all of those, we also try to look into what ICANN is doing, mostly the GAC, and how issues of two-letter codes and new gTLDs and country names are aggravating governments and how they look into the technical community because we’re all together in this here.

And then also there’s the spat at IETF on DNS over HTTPS. I got two governments at ITU, they tell me that, well, if you’re supposed to be figuring this out and you can’t, what do you want us to do?

So there’s a lot out there. Thank you. And I’m here for questions now or around whenever you want.

John Curran: Any questions for Anne-Rachel? Lengthy governance report. But good.

Yes, Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. Anne-Rachel, thank you for dealing with all the things that, quite frankly, make my head hurt.

The one thing that I would – you mentioned during your talk was in regards to what happens if IP addresses are monetized and how governments view that monetization and the story that we’ve given over the years and how we’ve operated.

I think it might be important that during staff and legal, especially for a number of proposals moving forward, that that perspective be given to the Advisory Council, at a minimum, and possibly something to the community.

But I think that the Advisory Council should see the global aspect of the things that go on in helping them weigh their decisions.

And I don’t know if that goes on today. It didn’t when I was on the council. And I would suggest that that might be beneficial for everybody.

Anne-Rachel Inné: Sure.

John Curran: Any other questions? Thank you, Anne-Rachel.

(Applause.)

Our final report of the day will be Richard Jimmerson giving us the Software Development Update.

Software Development Update

Richard Jimmerson: This is a standing item that we do at each of the Public Policy meetings typically right at the end. It’s a Software Development Update to basically share with you how we receive our strategic guidance inside the organization that defines what it is that we do in terms of development inside engineering, how that work is prioritized. We share some highlights since the last meeting six months ago and talk about some upcoming initiatives that we’ll be working on between now and the next meeting.

Our strategic guidance that we receive is actually from the ARIN strategic plan that’s created by the ARIN Board of Trustees each year.

They come together around the middle of the year, and they create the strategic guidance for the organization and vision for the organization for the forward two years.

In our current 2019-2020 strategic plan, we have a line in there that states that ARIN is to maintain, develop and enhance functionality of ARIN services as sought by the users and supported by the membership.

And further, inside, as an organizational objective, as defined by the Board, that we continue to review and enhance online services, including making significant user interface improvements, as guided by the user feedback, customer surveys, and customer suggestions.

As a side note, inside the hallways, inside the ARIN offices, we actually have poster boards of the ARIN strategic plan and organizational objectives as defined by the Board. It’s on the wall in every hallway inside the organization.

John Curran requires that every January we change that poster board to the next version. And anytime that we’re doing something inside the organization and there’s any question for a member of the staff team, if it’s something that fits inside the Board’s guidance, we can go look at the wall.

And oftentimes John will invite us to do that. We have strict instructions inside the organization never to engage in any activity that does not fit in one of the strategic guidance items provided by the Board each year.

Factors that influence our priorities inside the organization. Of course, legal and regulatory. If there’s some sort of legal item that’s at issue that requires a change in our systems, that gets prioritized immediately. Same thing with regulatory items that might come down the pike.

Ratified policies by this community. Something that you ratify here this week through your communications and through the Advisory Council recommendation to the Board, ratification by the Board, that fast tracks it through our development process.

Also things that you submit through ACSPs, Board initiatives and other items that you see here help us influence priorities in how we actually line up the work for you.

Some project highlights. Since ARIN 42, of course, you already heard us say that we’ve launched a new website on March 2, but it was much more than simply a new website.

Specifically in ARIN Online, everything was redesigned basically from the bottom up and streamlined to improve the user experience. That was tied to some ACSPs, but that was work that needed to be done aside from the ACSPs, too, but we were able to close those ACSPs.

There used to be whenever we needed somebody to prove to us that they were a human in one of the forms that they were filling out on the website, you had to do like a simple little math question. We’ve replaced that with reCAPTCHA because we have received so many complaints about that.

Added accessibility features for on-screen readers for people with disabilities, and we’ve gotten some very good feedback about that since the deployment on March 2, actually.

We’ve improved page display and responsiveness for mobile devices. We made sure the development of this product, the new website, the new ARIN Online, that everything works well on a small phone, a tablet, all the way up to a browser on a computer, and we put a lot of effort into that.

We implemented a combined site search/Whois search on the main website that allows you to find things more easily and also RDAP items related to that as part of an ACSP.

More project highlights since ARIN 42. We’ve provided ARIN staff with the ability to open tickets on a customer’s behalf, and the customer can choose to either accept or reject the ticket.

We’ve had an ongoing customer service issue for years where customers have gone down the wrong path inside ARIN Online to get something done, and they find out some days later, and then it was upsetting to them that they had to start all over and go through the process again because they submitted the wrong ticket type.

Or they might have had a ticket that expired because it went past the 90-day window. Staff was unable to reopen that ticket for them. They had to go open a new ticket themselves.

There were a lot of other reasons why customers became frustrated with the fact that we couldn’t open tickets on their behalf. So as of March 2, staff is now able to do that.

In order for the ticket to be activated, however, the customer themselves has to either accept the ticket we created on their behalf or reject it. If they reject it, nothing happens within the system with the ticket and it’s simply closed.

We also did some Whois performance tuning. We have – people are running scripts and doing all kinds of things, basically pulling Whois data. And we’re constantly keeping up with the demand there. And we performance-tune Whois code so that we can keep up with that and keep a good level of service open to everyone.

And we also implemented the RDAP changes described here that we also put in the release notes for the deployment on March 2nd and that you can also find in a blog post that engineering has done recently.

So going forward, some of the forthcoming initiatives. As we described earlier today or yesterday, we really only work on one major project at a time inside of our engineering operation. And then we have some smaller and medium-sized things that we’re doing at any given time.

The big project now that we’re done with, ARIN Online and the web rebuild, is the routing registry. And we’re working on that for the next 18 months planned.

Some of the smaller-sized projects, we’re going to complete the final stage of a stateless implementation. We deployed most of that, actually just in this last March 2 deployment. In fact, we’ve done several deployments over the past month since that March 2 launch that were transparent to all of you. And at our May deployment that comes up here next month.

After that, you shouldn’t expect to see any outages of ARIN Online in our services for us to make deployments with some rare exceptions going forward.

We’re looking to add new Point of Contact types as part of the Routing Registry Project and some ACSPs. We’re looking at the DNS and the routing Point of Contact types. And we’re continuing UX improvements in ARIN Online on the website always. We’re continuing to improve those things based on feedback.

You guys call us up on the phone. One of your customers calls us up on the phone and we get a lot of data from them. We take and we process that in scrums every week. We talk about feedback every week that we’re getting from the customers, and it has an impact on the active stories that are going into our sprints and the work that we’re doing together to improve the services for you. So that will always continue.

And of course, as always, reduction of technical debt. We rely on packages and services and software to run our services to you, just like any other company does. And things go out of date. Things go out of service. They get bugs. They have security issues.

And we have to chase those down and knock those out on an ongoing basis to ensure that our services to you can remain current and very well delivered.

So with that, that is the Software Development Update, and I’m happy to answer any questions that you have.

John Curran: Microphones are open for questions. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. Even without my glasses all of yesterday afternoon – no, just kidding – the new website is wonderful on my phone. It was a constant nuisance for us. The only suggestion is if you could make, in the agenda, all the policy proposals linked so it cuts down driving around.

But it’s been wonderful being able to go through things with people using the mobile phone, which is becoming the more norm, and not having to use the big, thick piece of timber.

Richard Jimmerson: Excellent. Thank you.

Steve Wallace: Steve Wallace from Indiana University. Is there a mechanism – and if there’s not, I guess this is a feature request – for administrative POC to require all the other POCs to use multifactor authentication for the Orgs for which that person is the administrator?

Richard Jimmerson: Not systematically currently, no. You would have to actually talk to your POCs and require that of them, but nothing systematically requires it.

From what I hear, you’re saying if I’m the Admin Point of Contact, is there a way for me to force all other points of contact in the organization, but really what we’re talking about is the web users behind those points of contact to use two-factor authentication to log into ARIN Online.

Currently, that’s not something that we have as a feature, but we would be happy to take that as a suggestion.

Steve Wallace: Thank you.

Richard Jimmerson: Any other items?

(No response.)

John Curran: Thank you, Richard.

(Applause.)

Open Microphone

John Curran: Okay. It is 4:22. We’ve just got three more hours of stuff, and then we’re done. No. Sorry. We’re actually at Open Microphone. We should be done in a short amount of time.

So let me point out we have a session called Open Microphone at our meetings each time, and this allows people to ask questions that haven’t come up in the presentations. People who have new ideas ask about topics that may not have been considered.

So I’m here. We have Chairs of the Board and the AC up here. And so the microphones are open. Please ask away, if there’s a question you haven’t had a chance to ask.

Steve Wallace: This is Steve Wallace from Indiana University. So yesterday, I think it was, you talked about thinking about creating a program committee. And I participated in program committees for quite a few different events during my career.

And when you said that, I thought, oh, yeah, that’s how this is done. And then I thought more about it and how this meeting functions.

And this is my first in-person ARIN meeting so I’m a little bit naive, probably. I think that could be a bad idea. And the reason is you have a few hours that are really flexible.

This meeting operates more like a working group with specific tasks to accomplish. There are people brought in to inform the folks here who are doing those tasks in different ways to share information that’s germane to that activity.

And if you create a program committee and then offer solicitation, not only – you create a particular kind of dynamic that can be difficult at best, you have people competing to be here, regardless of whether that really furthers the purpose of this meeting.

And the program committee itself can be a little unwieldy. So, like I said, my first reaction is, oh, yeah, that’s how you do this. And then my second reaction was, oh, but not this. So I would be very cautious about doing a solicitation.

John Curran: Thank you. Excellent feedback and food for thought while we’re weighing this.

Paul Andersen: I think if anything we’d be moving very slowly. I don’t think the intention was the entire meeting would be handed over to a program committee, but more we would take some available slots and experiment with that kind of solicitation and then slowly move towards –

John Curran: Do you want to respond to the – I think his dynamic is the fact that you have so few slots will make a contentious and potentially not functional program committee.

Steve Wallace: Yeah, you have too few slots. And if you put a solicitation out, you’re going to create demand for those slots. And that creates a really challenging dynamic, even when you have large meetings with lots of slots.

And it’s hard for me to imagine – I’m a newbie – but it’s hard for me to imagine that being worth it.

Paul Andersen: I appreciate that, and I apologize. I understand what you’re saying now.

Kerrie Richards: I have two comments. One is from Jason Schiller, Google, ASO AC: When the Board suspended the fulfillment of the waitlist, was the intention to just not fulfill any waitlists, or was it to specifically put a hold on the entire Section 4.1.8.2, which kicks off an Org, kicks an Org off the waitlist if they get a transfer?

This doesn’t seem fair that someone who got a transfer prior to the freeze got kicked off the waitlist, but an Org getting a transfer now can remain on the waitlist and possibly get their waitlist request fulfilled if they still have a need.

Please, please, please reinstate the text. Any requests met through a transfer will be considered fulfilled and removed from the Waiting List. End quote.

John Curran: I believe it’s – the Board very much intended to only suspend the issuance of resources. So the rest of the process is operational.

Now, regarding whether someone receives a transfer can receive number resources or are they removed, they may be there now, but whenever we resume processing, they will be removed.

So it’s addressed when you folks tell us what we’re resuming. We will handle that as part of the transition. There’s no one who is going to be able to get resources because their transfer happened in this window, if that addresses Jason’s question. We’ll find out.

Kerrie Richards: And the second question comes from Brian Jones, Virginia Tech: Like the new improvements to the web pages. Great job. Thank you.

John Curran: Okay, thank you. Center, front.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Could we get an update on the orphan POC and the Org situation? And is there anything moving forward on that?

John Curran: We can get that arranged, yes. Try to see if we can get that arranged ASAP, but it might not be this meeting.

David Farmer: I guess the question is: Is it intended to be moving forward?

John Curran: No, it’s moving forward slowly. It’s just this whole website thing sort of is a big bang.

David Farmer: There’s a lot of things going on. I can be patient, but I just like to – so at the table topics for the Whois cleanup, we talked about that, so that’s why I brought it up.

And then also in that, during that discussion, we talked about, hey, maybe a way to maintain that going on is when a POC or Org is no longer attached to anything, the POC or the Org – the POC or the POCs or the Org, in the Org case, should get notified of that and told that their POC or Org is going to be removed unless they otherwise – request otherwise or something like that.

John Curran: I think that’s a good topic to have when we bring up the orphan POCs. Rear microphone.

r. LeVere Harper: Hi, r. LeVere Harper, Mondo Media.rlh and ISOC Barbados. I just want to know, how do you go about requesting an ARIN visit or a conference to be held in your country?

John Curran: That’s interesting. So we try to alternate our meetings throughout our service region – Canada, US, and the Caribbean. That generally means that we make it to the Caribbean every other year. We make it to Canada every other year and we make it to the US generally because we’re following NANOG in the fall.

Susan – Susan is the master of the meeting locations. If you find her and talk to her, you can figure out when that makes sense for you.

Paul Andersen: Talk to Susan. That’s the answer.

Krislin Goulbourne-Harry: Hello. Krislin Goulbourne-Harry, Fellow. I know you all mentioned that the numbers are not supposed to be sold. However, they are being sold, and you are having discussions on what is happening, right, in terms of them being monetized.

But what I don’t know is what possible solutions are, what are the outcomes you have been discussing?

John Curran: Repeat that very last part. I missed the last two words.

Krislin Goulbourne-Harry: I don’t know what are the solutions, the possible solutions or the outcomes that you have been discussing.

John Curran: If I understand you, you’re asking what’s the solutions we have for this other than monetization. Is that –

Krislin Goulbourne-Harry: I just want to know if you are planning to allow the monetizations or are you planning to find a way to stop it? Are we going to just go with the flow and everybody do what they want to do?

Paul Andersen: So, today we have policies that allow two parties to enter into a transaction and to transfer the addresses from one party to another. And that’s been functioning now for, geez, I’m losing track of time now.

John Curran: Eight years.

Paul Andersen: Did I say – oh, yes. And I guess there was a topic earlier, though, that we’re getting address space back that we are handing out. And that’s the topic. And how we are going to address that is the outcome of this meeting, we hope. So we’re hoping to hear from the Advisory Council soon and the community, of course.

John Curran: We have a transfer policy that allows people who have resources they don’t use to transfer them to another party and benefit.

The question is what does ARIN do with the resources that we’re taking back because someone doesn’t pay their bill or they return addresses. For the resources that are coming into ARIN, historically we’ve been reissuing them to people on a Waiting List.

The question is do we continue to do that, do we issue to a subset of people, do we issue to smaller sizes? Or do we potentially, ourselves, bring those to market and use the proceeds for something worthy for the community.

But what we do with our Waiting List resources is distinct. The community has the ability right now to go to market and transfer rights in accordance with policy. Does that help?

Krislin Goulbourne-Harry: To me it seems as if it’s opening more questions rather than answers. So it gets a little overwhelming.

So you have a lot of questions. So when you’re discussing, there are a lot of questions – what do we do here, what do we do there, you know?

All the questions, but what I don’t know is what do you actually plan to do?

John Curran: So the 15 members of the Advisory Council in this room are listening to this discussion. They’re going to get together in the next day or so. And based on what they heard, they’ll refine the proposals, all the alternatives.

Some of those alternatives will merge. Some will advance.

Yes, David.

David Farmer: I just wanted to say, it’s not what ARIN is going to do, the company or the organization; it’s what we, the community, want to tell ARIN to do.

John doesn’t decide this. John just does what we tell him to do. He does a good job at doing what we tell him to do. But even if we think – even he does what we tell him to do, even if that’s not what – we wanted it to be done because that’s what we told him to do.

So it really spins back to you. What do you want to have happen?

John Curran: Right. You find the AC and tell them, or you go to the Mailing List and you post what you think should happen. And that becomes part of the dialogue that converges on new policy.

The staff, we just implement that policy.

Kevin Blumberg: Kevin Blumberg, The Wire. And also policies take between six and 18 months, and many of these policies are three weeks into them, so this is the start of the discussion, just from my own experience.

But what I wanted to bring up was related to policy shopping in the different RIRs, and I want to make the community aware that I see a concern where an author puts a Policy Proposal forward in a region and then points to the other region and says, Look, there’s a Policy Proposal in that region.

And the community doesn’t realize that it’s, A, the same person, or, B, they decide to get a policy through in a region that’s easier for them to get it through, and then they say, Look, that region is doing it and now we need to do it.

We need to stand up on our own and be careful with the policy proposals that we see, that they’re the right thing for our region. That’s part of it.

That goes into the question about a policy, a new one. This morning, one of the slides said that ARIN does not require multi-homing for AS numbers, which is not entirely true from my understanding.

You need to have a unique routing policy to get an AS number, which multi-homing would be one way of doing that.

But there is very difficult requirements from my own experience to be unique. You have to have a real reason, which is not simply just you can ask for an AS number and get it.

And the question is, at this point, especially with the changes to the way cloud services require AS numbers, should we simplify and have a policy? And that’s sort of the question for the room, that the unique routing question or the unique routing requirement gets simplified down to allow it to be easier to get an AS in those scenarios.

So from an ARIN perspective, if you could explain what unique routing policy means, I think that might help inform the community as well.

John Curran: Certainly if the community wants us to simplify the AS number issuance policies, then that’s something you should tell us clearly. And it is possible that the world’s changed such that that makes sense.

This man’s name is Kevin. Converge on him and talk about a Draft Policy if that’s what you want. Yes, you want to comment on that in particular?

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I’ll point out that there’s quite a long history of policy proposals that do nothing more than but codify and clarify what is currently the standard operating practice among ARIN staff.

And someone just says, hey, we’re doing this already, but this could be ambiguous. Let’s actually write a policy that makes it in black and white so everybody understands what it is. And that’s perfectly acceptable.

And that’s – in this case, that’s probably something – that’s probably absolutely what I’d encourage.

John Curran: Center front mic.

Suzette Burley: Suzette Burley, an ARIN Fellow and also representing Digicel Jamaica. I know first early on – this is not my question, by the way – but we spoke about what we do with the funds from auctioning those IP addresses that was returned.

I have a suggestion. We can use it to continue with the fellowship program and inviting more persons to come as fellows. So that’s my suggestion what we can do with it. Since we haven’t quite decided on that yet.

But my question is, from my interaction with different IP engineers, especially within Jamaica, I found out that a lot of persons did not implement their IPv6 Internet infrastructure because they did not know how to.

And this was a general concern as I was going around having different conversations. So my question is, do we have an online webinar, because not everybody has the resources to visit the conferences? And if so, how is that advertised to the POCs?

John Curran: We’re in the process right now of spinning up training at ARIN. And we’ll talk a little bit about that tomorrow in our community, in our department reports. And v6 is one of our first focuses.

Rear microphone.

Richard Wahl: Richard Wahl, ArkiTechs. My question is connected to the training, so you answered it already. Could you give us insight into what are some of the programs that might be offered on these trainings?

John Curran: I believe we’ll have that discussion tomorrow. Susan will mention the training at ARIN initiative underway.

Owen.

Owen DeLong: Owen DeLong, ARIN AC. Going back to Kevin’s comment about AS numbers and requirements from cloud providers, as I understand it, the times when cloud providers are requiring you to have an ASN are when you’re announcing routes to them for subsequent distribution to other providers.

If you’re announcing routes to a cloud provider that they’re now announcing to other providers, that is indeed the very definition of unique routing policy and therefore would qualify you under current policy.

John Curran: Kevin is this guy over here. You should get together with him and talk to him about it. Next over here.

Rudi Daniel: Rudi Daniel, I’m a Fellow and also speaking for myself and (indiscernible). Just a comment, really. I would hate to see ARIN going into auctions, and the other reason is that once we have the money, then we have to decide what we’re going to do with the money, and that’s going to be a very contentious issue anyway. So I would hate to see that totally.

I also wanted to ask, do we at ARIN actually monitor the commercial market for v4 addresses currently?

Also because some of the proposals we have here, we need to know what the market is like on the outside in order to determine what we’re going to do. We also want to know the value in relation to block size, too.

John Curran: So, you asked the question, do we monitor that market. I’m going to say yes and no. Yes, we monitor the transfer market to make sure that there’s a healthy rate of transfers going on to have an early heads up in case something goes wrong somewhere and for some reason the transfers aren’t working at all.

But that’s literally just making sure John’s graphs of transfers are increasing and we see them going within the region and inter-RIR. The number you’re thinking about is do we look at price associated with them.

The two aspects of that is, one, we don’t ask for that. In fact, we work hard not to ask for that. So we don’t monitor that. But there are a number of people who publish full-on reports about the health of that market: Number of transactions; where they’re going; average prices involved.

So if the community gets to the point where it starts talking about monetization of these numbers and – we can provide them numbers. We don’t need to monitor the market.

We do have this public – easily obtained public sources about the size of that market.

I’m closing the microphones. Go ahead. Last one. Remote people, closing. Go ahead.

Chris Woodfield: Just one more point. There are members of the AC and I believe now of the ARIN Board – I’m sorry, the ARIN Board, that are part of the reseller market and do have insights that other members of the community may not. And that insight can be used to shape policy.

John Curran: Right. If you raise your hand and say, I’m looking to buy IP addresses, they’ll find you.

So any other questions? No? Last Call. Final call. Okay, I’m closing the mics for Open Mic and that ends the last session of the day.

Public Policy Meeting, Day 2 - Closing Announcements and Adjournment

John Curran: Let me do quick announcements.

I’d like to thank our sponsors, C&W Business and Google.

(Applause.)

And our event sponsors, Platinum Sponsor Addrex; Silver Sponsor, IPv4Mall.

(Applause.)

Okay. We have a meeting survey. The meetings, we improve them based on your feedback. Please fill out the survey. We’re actually going to enter one of you into a drawing – we’ll enter all in the drawing, but only one of you are going to win an Xbox.

Reminders, we start tomorrow at 8 AM. Our Public Policy and Members Meeting starts at 9:00. Thank you, everyone. Enjoy your time at the beach. See you tomorrow at 8:00 or 9 AM. Thank you.

(Meeting recessed at 4:45 PM.)

Network Sponsor

Webcast Sponsor