ARIN 44 Public Policy Meeting, Day 2 Transcript - Friday, 1 November 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: If folks will come in and be seated, we’ll get started.

Good morning and welcome back. Hope everyone had a lot of fun last night. I’d like to start out first – this meeting, everything we do is only possible because of our sponsors. I’d like to give a round of applause to AT&T, Google, and Addrex.

(Applause.)

Our elections, which we talked about a lot yesterday, remain open. Go forth. Vote. If you have a challenge, go to the Election Help Desk, which is outside, or drop an email to members@arin.net. So please vote. This is very important.

Okay. Rules and reminders. We have some policy discussions this morning. The Chair, in this case the Vice Chair, will moderate the discussions to make sure everyone has a chance to speak. Speak clearly, slowly at the microphone so that we can have a good transcript and so that we understand who is actually identified when we go back and read that.

Make sure that when you’ve spoken, don’t monopolize the mic. If there are other people, let other people speak before you go back to the mic. There are rules in the program. Pick up your Discussion Guide. Look at the standards of behavior. We just try to be courteous to one another.

Our agenda this morning. We have some reports going on. The NRO Activities Report. The NRO is the Number Resource Organization. It’s the name we use for the coordination between the five RIRs. So the Number Resource Organization, the five RIRs working together. We produce a summary of our activities.

We have the NRO Number Council report. When the IANA issues IP address resources to each RIR, it does it with global policy. The NRO Number Council – also referred to as the Address Supporting Organization Address Council, that’s in the ICANN context – the NRO Number Council develops those global policies. They actually don’t have their own policy body.

They help coordinate the five RIRs’ policy bodies, which is you, to actually generate the same text in all five regions. And when we have materially the same text, that policy becomes a global policy for the IANA to use.

So, we’ll have the report from the NRO Number Council. We’ll have the IANA Review Committee Report.

So, the five RIRs contract, collectively, with ICANN to administer the central registries. And we have a committee that reviews ICANN’s performance in that regard. So, that’s the IANA Review Committee.

We have a Recommended Draft Policy to be discussed. Why do I have this here, but I don’t have it on the agenda?

Kerry Carmichael: We believe the slide is incorrect.

John Curran: I believe the slide is incorrect. We have a number of policies to discuss this morning, but none of them are Recommended Draft Policy. We’ll talk about that later. We have the software update as well.

The head table, I have Bill Sandiford, I have Tina Morris, and I have Leif Sawyer. Respectively, ARIN Board of Trustees Vice Chair, ARIN Advisory Council Chair, and ARIN Advisory Council Vice Chair.

Draft Policy ARIN-2019-12: M&A Legal Jurisdiction Exclusion

John Curran: So I’m now going to start off. The first thing we have is our policy block. And the first policy up is the ARIN 2019‑12, which is M&A Legal Jurisdiction Exclusion.

Because this is not a Recommended Draft Policy, you’re just going to hear from the Advisory Council. I’d ask Joe Provo to come up and do the presentation, talking about this draft which is a policy in progress.

Joe Provo: Good morning, everyone. It’s always fun to be the first policy after the social last night. It was a good social. I have my “talking over music all night long” voice on. So, pardon me.

As Mr. Curran said, this is not recommended yet. This is draft. This will be seen in future meetings. This is very malleable at this stage.

This particular policy has had active discussion between the time that there was S&L review and this meeting. So you will see some text that has some slight variation. For completeness we have the S&L review within these slides, but we’ll be discussing the current state of play per the PPML threats.

This is one of a set of policies that had been proposed to deal with a few infrequent corner cases that result in complicated scenarios for member organizations.

I’m not going to totally regurgitate what’s on the slide here, but the key element is that the problem exists for ‑‑ similar to a policy that we heard about yesterday, that there can be a surviving entity after M&A procedures that is not necessarily legally formed, contained or otherwise within the standard interpretation of the ARIN jurisdiction.

There are several examples that ‑‑ two examples that were within the text of the problem statement. They’re within your Discussion Guide. The staff and legal, as I mentioned, was for the text as of 28 August. And there were actually no significant concerns presented.

The PPML discussion has resulted in little mutations to the text, as I mentioned. We have some text here that is bolded, which was not covered by the staff and legal. This is the critical element that people may be seeing for the first time if they’ve not been up to date on the PPML threat.

Basically trying to assert having no presence to cover natural persons, not just incorporated entities, was a late‑breaking discussion point from last week. And it’s merely saying to codify what is actually in effect, current practice by staff.

Due to input from other members, we’re interested in formalizing a clarifying comment that will be attached to the text as it is posted on the website, but not actually within the NRPM, such that we have context and some historical clarification.

It’s a little more verbose, but we don’t want to ‑‑ as we’ve discussed in other presentations yesterday, a lot of the goals that we have for the NRPM now include simplification. We didn’t want to encumber what is a relatively minor text change with a lot of references to other sections because that just sets us up for editing doom in the future.

As I said, this staff indicated that the process ‑‑ we’re essentially codifying what is an existing process but is just not merely documented within policy.

Again, this was all in reference to the previous text. We will have a formal staff and legal for the new text which is not materially different in the AC’s opinion. We’ll have a formal review for staff and legal after this meeting if there’s no additional activity on PPML, if we settle into a real good, solid piece of text.

So that’s what we have. Please throw questions, brickbats, whatever.

Bill Sandiford: Thank you, Joe. Good morning, everyone. Front center microphone.

Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I just have a question regarding the last sentence in counsel’s legal assessment. It says: “By making this a specific addition to policy, it could create an artificial way to move resources from one region to another, as opposed to one that is organically occurring.”

I’d just like to understand why that would be the case, if this practice already exists, how it could actually change things.

John Curran: I could call counsel up, but let me give a high‑level overview. Something that occurs because of circumstances is different than something that’s stated in policy. One, stated in policy will be found by others and exercised as a route.

So you could end up with an endorsement of something that’s already happening. That’s it.

Chris Tacit: Okay. So the consequence of that would be what, then?

John Curran: It’s just an observation.

Chris Tacit: Okay. I guess what I’m trying to understand is I know at the AC our job isn’t to look at the fiduciary aspect of things, but nevertheless we have to realistically think of what might happen ahead when it gets to the Board.

So one of the things I’m trying to figure out is if that sentence, from a Board perspective, might end up being a show‑stopper, which means should we continue working on this policy or not.

I know you can’t sort of give a definitive answer, but I’m trying to figure out how much of a problem that last sentence really is for this policy.

Bill Sandiford: Steve?

Steve Ryan: What’s being done here is creating a path that tells people who are not actually experiencing the transaction that is closing down activities on one continent and moving them to another to falsely create that pattern is the concern in that sentence.

In other words, it’s a warning that the more you mess in this area, theoretically, the more you create methodologies for people to think about doing things that are not actually occurring, to buy and sell things that are not really being bought and sold in order to be able to transfer from one place to another. I think that was what the sentence was intended to warn about.

With regard to that sentence, I don’t believe it’s the kind of recommendation that I would make that trespassing in this area is going to lead to the policy being rejected by the Board. The Board will have a panoply of things to think about, not just that sentence. Is that helpful?

Chris Tacit: Yeah, that’s a very helpful clarification.

Steve Ryan: John, you may have a different view than that. Management may view it differently than legal.

John Curran: Let me go first. So all I’ll say to the AC is that while you need to pay attention to legal reviews, a legal review that says the policy you’re working on is likely to have significant issues at the Board will use phrases like “significant issues and concerns.”

If you don’t see that in the legal review, then it’s just an observation that you need to pay attention to. That means it’s going to probably get discussed. It’s unlikely to pose. We’re very good if we see a “show stopper,” to put it in there very clearly.

Chris Tacit: That’s what I wanted to clarify. So thank you for that. That’s very helpful for me as a co‑shepherd of this thing. Thanks.

Bill Sandiford: Any others feel free to approach the microphones. At the moment the queues are empty. Any remote participants? Seeing that there’s none, going once, going twice.

Thank you, Joe, for your presentation.

(Applause.)

Draft Policy ARIN-2019-13: ARIN Membership Legal Jurisdiction Exclusion

John Curran: We’re going to move ahead to our next policy in the policy block, And this is ARIN 2019‑13: ARIN Membership, Legal Jurisdiction Exclusion. The shepherds, Amy Potter and Alicia Trotman. I’ll ask Amy to come up and give the presentation.

Amy Potter: Good morning. This is another proposal in the similar vein as the one we just saw from Joe dealing with some jurisdictional issues.

So the problem that this is trying to get at is that organizations that are not incorporated within the ARIN region but that still have a substantial nexus to the region are unable to receive resources from ARIN.

So, say you have a large US company that is looking to offer services outside of the ARIN region, and the country that they want to offer services in requires an in‑country legal entity to hold their assets and to hold the ASN that’s used for peering.

So this large US company has a startup ‑‑ another legal entity out of the region, and they want to still work with ARIN. They want to use ARIN to set up an ARIN Org ID, to receive an ARIN ASN, and they want to be able to reassign space from their parent company or related company within the ARIN region to this out‑of‑region organization.

Currently that is not something that they can do. So to accomplish this we added a little bit of text to Section 9 of NRPM, saying that “legal entities can demonstrate a substantial connection to the ARIN service region without necessarily being incorporated within the ARIN service region.”

So we sent this to staff, and it came back with some serious legal concerns. This Policy Proposal would open ARIN up to the necessity of serving legal papers and dealing with litigation in foreign legal forums.

This could be a problem because those foreign legal forums may not be committed to the rule of law. They might be hostile to foreign business interests, and the legal systems might be expensive or unresponsive.

Another issue is that it substantially reduces ARIN’s ability to know its customers.

ARIN’s General Counsel advised against adoption unless ARIN has a clear and pressing need to fulfill its mission by adopting the policy.

So I’m here to ask the community: Do we have that need? Do we see this as being a real problem that actually exists? And do we think that it’s something that we need to address for ARIN to fulfill its mission?

Bill Sandiford: Front and center microphone.

Chris Tacit: Chris Tacit, Tacit Law. This is one that does have the big, bold warning. So I get it. I guess what I’m trying to understand ‑‑ so, I’m not an expert in US law. I know in Canada, though, that merely not being incorporated doesn’t insulate you from being sued in Canada.

There are other connections to the jurisdiction tests which actually seem to be captured by a lot of the factors in Section 9 anyway. So, I’m wondering if this problem couldn’t be solved by the practical aspect that an out‑of‑region transfer wouldn’t be allowed anyway unless it met a significant number of these bullets, coupled with perhaps a requirement for the entity, even if it’s foreign, to bind itself to provide an agent for service within the ARIN jurisdiction.

I’m wondering ‑‑ because clearly somebody thinks there’s a need for this policy or it wouldn’t have come up. So is there a creative way to deal with this, to solve the legal concern? I guess that’s my question.

Bill Sandiford: John.

John Curran: So, in theory, one could create a tapestry of mechanisms ‑‑ the countries you’re willing to deal with, the need for registered agent, the requirement not to deal with certain countries even with an agent because of compliance with US law, the requirements to address where we could be litigated from.

And then considering the fact that Board members travel to countries, whether you can be litigated on doesn’t mean you can’t be served because you can have a Board member present ‑‑ nothing like have a Board member travel and receive notice while they’re on the road that they’re being served.

So could we put together a tapestry to address this? Yes. If there’s strong demand in the community for this policy, then that’s something that the AC would reflect and would go to the Board, and the Board would consider all aspects of that with legal guidance.

We know this is a policy whose implementation could create a significant amount of assessment of legal work about the value involved. And at the end of the day, it’s not to say that it’s not a possible policy to have, it’s just the AC may easily see this policy come back from the Board, saying: Please explain the near and present problem that this policy is solving, given the amount of work.

The Board has the right to send something back to the AC and ask: Do you really want this? Because this is what it’s driving in the implementation of policy. That’s all you’re seeing there.

Chris Tacit: Okay. So maybe in light of that, I could ask you folks to consider taking a poll about whether people want to see us continue working on this.

John Curran: Quite a possibility.

Chris Tacit: Because that would at least give an indication of whether there is any significant demand for this.

John Curran: I heard there was interest in taking that poll anyway.

Bill Sandiford: Perhaps.

Chris Tacit: Thank you.

Bill Sandiford: Front and center microphone again.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I oppose this policy. Just to clarify one thing that ‑‑ Chris mentioned transfers. This has nothing to do with transfers. There’s a whole series of policies sort of looking at this problem from different angles, and this angle concerns me greatly.

And I don’t think ‑‑ unless there’s some people that want to get up to the mics and say they really, really, really need this, I don’t see us doing this. Thank you.

Bill Sandiford: Thank you, David. Far microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I oppose the policy. ARIN’s been around 20‑plus years now. Organizations that needed space set up something, did something. To say you have a substantial presence in the ARIN region but no company in the ARIN region seems counterintuitive and kind of silly.

If we want to do that, call it what it is. Allow it, do it completely differently, whatever it may be. But this just does not seem a realistic, actual thing that needs to be done.

We’ve got a lot of other things that need to be looked at, and for something that hasn’t happened in 20‑plus years, and nobody here actually saying that it’s going to affect them, I see no point in continuing with this kind of policy.

Bill Sandiford: Thank you, Kevin. Rear microphone. Call for the queues at the same time; join the queues now if you intend to.

Owen DeLong: Owen DeLong, ARIN AC. I’ll echo what Kevin said, which is a rarity.

If there’s somebody in the room who has need for this policy or something like it, please, I implore you to speak up because, absent some clear expression of need and some example of an actual case where this actually applies, I think we should kick it to the curb.

I just ‑‑ it’s a Pandora’s box of legal issues. And unless there’s some real benefit and some real need that somebody can express, I think it addresses a possible but not necessarily actual corner case that doesn’t come up very often.

I don’t know of any countries that require the ASN to be registered to a company in country in order to do peering in that country that actually have a peering fabric in the country that is substantial.

If anybody’s got a case like that, I’d love to hear about it so that we can actually look at this in a more meaningful way. Thank you.

Bill Sandiford: Thank you, Owen. Rear microphone again.

Mike Burns: Mike Burns from IPTrading. I come at this a little bit differently, echoing what Owen said about certain countries requiring local ownership of ASNs and registrations. And that does exist, and we’ve seen that.

I’m just generally against these national laws that impact the Internet, the fabric of the Internet, how it’s routed. I’m just against those in general, and I don’t think ARIN should really take this pretty large step to compensate for those kinds of laws.

And by not taking the step, any pressure that could be brought to bear on these countries that are passing these laws would retain itself in place. So I’m against the policy. Thanks.

Bill Sandiford: Thank you. All right. Closing the comments, then.

Amy is asking to ask a question of the community and those in the room and remote. And that question is do we believe ‑‑ do you believe there’s a problem here that needs to be solved.

Ponder that for a couple seconds while the counters collect themselves for something they weren’t expecting to count.

John Curran: To be clear, we’ll ask all those who believe there’s a problem to be solved, aye, and all those who do not, nay.

Bill Sandiford: All right. Please raise your hand or indicate your support online if you believe there’s a real problem here that needs to be solved.

All right, and if you do not believe that there’s a problem here that needs to be solved, please raise your hand or indicate such online. Hands can come down.

John Curran: Why did the headless horseman go to college?

Bill Sandiford: Why, John?

John Curran: He wanted to get ahead.

(Laughter.)

John Curran: Even I think that’s horrible.

Bill Sandiford: It’s a question of do we prefer silence or pain. I guess I’m choosing pain over silence.

All right. Total in person and in the room, 81. Those who believe there’s a problem here that needs to be solved, zero. Those who believe there’s not a problem to be solved, 19. Thank you for your feedback.

John Curran: Thank you, Amy. Round of applause for Amy.

(Applause.)

Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

John Curran: Okay, we have our last policy of the whole meeting, actually, the very last one, ARIN 2019‑18: LIR/ISP Reassignment to Non‑connected Networks.

This, again, is just a Draft Policy. The AC is busy working on it but wants some input from you.

Robert Seastrom: Thank you, John. The problem statement for this Policy Proposal is that businesses have a need to lease IPv4 space. We know that’s the case because it’s going on right now legitimately or non‑legitimately on the radar or not on the radar.

So this Policy Proposal suggests three possible changes, of which two are expected to go through as a way of addressing that.

One of the things I will be looking for from the community is guidance on which of the two proffered changes to 8.5.2 might be considered preferable.

Let’s talk about the original policy language in Section 2.4. It describes a local Internet registry, and the operative term is at the end where we talk about “generally Internet service providers whose customers are primarily end users and possibly other ISPs.” So it creates this nexus where you’re getting a circuit, you’re getting a VPN, et cetera.

So the proposed language for Section 2.4 adds on to that, and the section that’s added on is italicized at the end here, that: “LIRs may also assign address space to other organizations or customers that request it for use in an operational network.”

Two potential changes to 8.5.2. One is that we get rid of 8.5.2 already. And I’m going to read through the strikeout there for anyone who is having difficulty for that.

8.5.2 describes operational use: “ARIN allocates or assigns Number Resources to organizations via transfers solely for the purpose of use on an operational network.”

So if we get rid of that, that’s easy. It means that you can do leasing without the need for a downstream circuit VPN connection.

Another possibility is modifying 8.5.2 by adding on to it: “but may allocate or assign number resources to organizations for other purposes, including reassignment to non‑connected networks.

So this was brought forward on PPML, and discussion ensued. A lot of discussion centered around what does this non‑connected network mean anyway and can’t they use Net10 for it.

Well, that’s not what was meant by non‑connected. Non‑connected was intended by the authors to mean that there is no circuit here, that we are engaging in the subdelegation of number resources just like an ISP does but without the circuit in place.

We’re going to make that abundantly clear in the policy text post meeting. We decided not to do that pre‑meeting and to present it as is.

Another problem is that the implementation details are unclear. And that’s going to show up again in a later slide as specific questions. Would the adoption of this policy mean that we can use leased‑out address spaces to demonstrate efficient use?

Meaning, as a recipient, can we use these address spaces ‑‑ then, you know, we’ve used this address space, and now we need to get some space from ARIN. Can we bring this forward, is it documented in such a way that we can bring this forward as a sign that we’ve used space properly?

That’s basically the same thing in the second question.

The third, though, and I’m going to elaborate on the third on the next slide, is can the lessor organization say, hey, we’ve leased out 90 percent of our address space. We well meet the requirements to get more space from ARIN, except for this problem earlier on with what ‑‑ like what the address space was being used for.

So does this proposal boil down to can an LIR that is leasing space out use that as justification with ARIN to get more space on the transfer market?

There’s been a discussion of ARIN’s role and the amount of control that we exert over how people use address space and when they’re able to get address space. For those in the room who may not be aware, the constraints that are exercised in the RIPE region are much looser than those in the ARIN region.

Some clarifying language has been proposed. We have not yet integrated that. So the questions that are before the community today, remembering that this is a draft proposal and we’re working on it, are: Do you support the intent of the policy, which is to decouple formally an IP address reassignment from network services so that it can be properly reflected in Whois? This is good for Whois health and accuracy.

Do you support option one, removing 8.5.2 entirely? Do you support option two, modifying 8.5.2, and how about the implementation details? We would like to hear the fine points of how this should actually go into play. And I’m going to flip back to that when we have people up at the microphones.

So, thank you.

Bill Sandiford: Great. Front and center microphone.

Andrew Dul: Andrew Dul, 8 Continents, ARIN AC. I oppose the removal of 8.5.2. We very specifically inserted that section into the transfer policy because we want transfers to go to people who operate networks, not people who lease addresses.

So that was very intentional. I would be okay, perhaps, with modifying that section. However, I think we also need to start thinking, if we’re going to go down the road of allowing leasing, what constitutes a majority of an organization operating an operational network versus a side business of leasing versus an entity which is primarily for leasing and doesn’t really operate an operational network.

Bill Sandiford: Rear microphone.

Kiran Malancharuvil: My name is Kiran Malancharuvil. I’m the original author of the Policy Proposal, so thank you for the community discussion thus far.

I sent out an email last night with some clarifying language, and I just wanted to note that for you in case you haven’t been on the PPML since last night, which is understandable.

The clarifying language, first of all, as Rob has already said, I wanted to clarify my intent about non‑connected networks to mean reassignment to organizations and entities which do not receive connectivity from the original registrant. I think Rob already made that clear, but just to clarify in my own words.

A suggested edit to remove the confusion about non‑connected networks of 8.5.2 is ‑‑ would read: “ARIN allocates or assigns number resources to organizations via transfer primarily” ‑‑ as opposed to “solely” ‑‑ “for the purpose of use on an operational network but may allocate or assign number resources to organizations for other purposes, including reassignment to organizations and entities which do not receive connectivity from the original registrant.”

So I hope that clears up some of the confusion that we saw on the PPML. And my apologies for not being clearer. I am a newcomer to ARIN, so I appreciate your patience.

A couple of other things that I wanted to mention. Of course we know IPv4 leasing is inevitable. It already happens, and there’s an increasing need for it as a result of the cost of obtaining IPv4 space. And the absolute barrier that a lot of small to medium enterprises encounter, they have a need for IPv4 space but they may not have the huge blocks of cash that they need to purchase or transfer IPv4 space to themselves on the transfer, the current transfer market.

So the purpose of this policy is really about equity and equitable distribution of IPv4 space and helping small to medium enterprises that can’t get financing and don’t have the cash to obtain what they need as far as IPv4 space is concerned. So that’s our primary consideration with this.

Also, we understand ‑‑ I had a number of questions directed at me this week about what our motivations are. That really is it, primarily. Although, also, of course, security, accurate Whois. Encouraging sort of more consistent use of SWIPing and accurate SWIP records are key as well.

And then finally I just wanted to note that this ‑‑ I very much appreciate the conversation about what this does with the needs‑based requirement in ARIN, which I think seems to be very precious to this community, and rightfully so.

I don’t think that this necessarily means that needs‑based justification for space is eliminated solely because the ability to lease to small businesses is now a legitimized environment as opposed to sort of technically or even sort of prohibited in the minds of the community as a practice that isn’t necessarily a black market, but certainly at least a gray market.

I think that we want to make sure that when we legitimize a practice, it opens up the opportunity for smart business solutions to address it, to address the security concerns that exist with the current leasing market, to address any of the issues that we see.

So we’re hoping certainly that ‑‑ and we have no expectation that criminality will go away, but we do think that we have an opportunity to address some of the problems that we see in the leasing space with smart trust and safety solutions. And that’s another one of our motivations.

So, I thank you for your consideration, and that’s it. Thanks.

Bill Sandiford: Thank you. Front and center microphone.

Scott Johnson: Scott Johnson, SolarNetOne. As I said yesterday, I was a participant in the 6bone. We’ve been working on v6 for quite some time now. I’ve been deploying it myself personally for over 15 years.

I have to oppose this policy change, both completely in spirit and context. This change would allow the creation of the concept of IP address space to be viewed as something like a paid parking lot, as well it would create a case of landlords for address space which could very easily lead to the similar practice of slumlording and other parasitic type of action as associated with a common public resource that was created by a group of dedicated engineers to serve the public good.

I don’t see how this serves a public good. I see how this only serves commercial interests who are looking to profit off the work of others. Thank you.

Bill Sandiford: Thank you. Far microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the concept. I don’t support any of the text here. And I want to point out that the concept of the LIR, in the ARIN region at least, has never really been used. It was a placeholder ‑‑ LIR equals ISP.

But that’s not the case in other regions. And I think we need to look to the other regions. APNIC has a very strong LIR/NIR community as an example. And I think we need to look to those regions, how they worked with their LIRs, and write proper policy to encompass actually doing it properly.

There are two reasons for this. One, we know this is in existence, we know this has been going on for many, many years, and we know all that it’s doing is affecting the accuracy of the Whois when it comes to these NetBlocks.

So we’re kidding ourselves thinking it’s not going on or by us not doing a policy it’s going to suddenly have all the space come back. All we’re doing is affecting the accuracy.

This is also, when done properly, a good environment. I worked for an organization. They managed a thousand companies that were within the ARIN region. They did everything for these companies. They washed their dishes if they had to. But each one of these companies had to go to ARIN. They would lose their space every once in a while because they would forget because they weren’t responsible for the stuff. The company that managed them did everything.

They would be a perfect example of an LIR. We handle everything for these small companies, including the ARIN registration.

So there are lots of use cases, and we can look around the world at how they’ve been done, whether they’ve been done at a national level or a company level.

But ultimately we need to be responsible for the Whois accuracy. This would help with that. And we need to protect it and write up good policy that encompasses all the requirements with that. Thank you.

Bill Sandiford: Thank you, Kevin. Front microphone.

Owen DeLong: Owen DeLong, ARIN AC. I’m not opposed to the concept of leasing. I’m not particularly in favor of it either. I do think that the wording in this policy needs to be pretty much completely scrapped and start over.

“For other purposes than use on an operational network” is a phrasing I just can’t stomach. There is no other reason to issue address space other than for use in an operational network.

It may not be that the use in an operational network is going to be by the exact person who is receiving the space. They may be leasing it to somebody else for use in an operational network. We can find a way to structure language about that.

But if we create language that says we will issue space for other purposes, I don’t know what those purposes would be, but I can’t imagine that it’s anything good other than use in an operational network, because I don’t know what else you would do with IP addresses than use them in an operational network. Thank you.

Bill Sandiford: Thank you, Owen. Rear microphone.

Mike Burns: Mike Burns, IPTrading. I’m a RIPE LIR. In RIPE, there’s such a thing as PI space, which is space that belongs to entities other than the LIR who sponsors that space. And it’s the same relationship we’re looking at here. We’re just trying to turn lessors into ISPs and allow them to reallocate this space.

Now, in terms of the language, I would get rid of 8.5.2. It just never belonged there in the first place. That kind of statement belongs at the top of NRPM. It just describes the overall goals of ARIN. In fact, it’s already there. So 8.5.2 should be gone.

But in terms of the implementation, I was the one who asked the last question about can I purchase addresses and justify them with leases.

And to answer that myself, I would say if I were able to do that, it would require the same sort of activity that an ISP would have to perform in order to use his suballocations and delegations to justify for more addresses.

That means a SWIP or some kind of a recording of leased‑out space. It might mean some requirements for the term of the lease. I wouldn’t expect to lease a bunch of space for one month and have that qualify to justify more space. So I think more work on the language of the implementation should be done.

But just a side note on the economics of the lease market. We have acknowledged that it does exist, there’s a space in policy that allows it to exist, and obviously it exists because it’s addressing a need.

But in the past, people who came to lease space were mostly spammers, and that’s because the pricing for leases was such that it was a difficult business case for any lessee to make. They could have purchased the space for between a year and two years of lease payments. So if you could buy the space and you could resell it in a year, why would you want to lease it?

However, now lease rates have come down significantly, and the economics of the engagement to a lessee are much more attractive. And there was some talk about small businesses and we do see small companies who can’t afford addresses who see the potential to lease addresses as their only mechanism financially to get into the space.

So as long as we implement this thoughtfully with the idea that lessors are analogous to ISPs, I definitely support this. Thank you.

Bill Sandiford: Front microphone.

Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I fully agree with what Owen said, and I just want to add an addendum. Just like with a brokerage market, when you have a transfer, the transfer doesn’t go first to the broker and then to the ultimate recipient. It just ‑‑ from an ARIN perspective, it’s justified by the policy and it goes from the transferrer to the transferee.

I think we’d like to see the same model here. If that’s true, then the resources are still being used for operational use.

What happens on the commercial side is a separate issue and shouldn’t concern us, but having that transparency in the leasing market would certainly help us improve database accuracy, and that would be the value of it.

So for that reason, conceptually, I like the idea for us to ‑‑ as a community, to try and get our handle on the leasing market and make it more transparent and have it reflected in the database. But this isn’t the way to do it right now. Thank you.

Robert Seastrom: I have a follow‑up question for you, and it’s actually a follow‑up question for everybody in the room since you are advocating for keeping the lessor organization in the proposal out of the middle and having the transaction happen directly with ARIN.

They would be providing the money to acquire some assets and then receiving a return on that. Yet, the number resources are not something that would be securitizable at this point because of demonstrated need. You couldn’t take them back. It’s not like a house where that’s pledged as the security for your mortgage and if you don’t pay, well, it goes back.

Can you think of ‑‑ and I don’t need an answer right now if you don’t have it in your hip pocket, but can you think of a way to accommodate that within our needs‑based system, where the security interests of the folks who are providing the capital is protected? Because I absolutely agree with folks who say the little guy is being held over a barrel right now.

Chris Tacit: That’s something I’d have to think about, but it’s an important practical consideration from a market‑operation perspective. And obviously we have to try ‑‑ our goal should be to try to align ARIN policy to the reality of commercial practices, but without compromising ARIN’s core mission, because if we ‑‑ we’re not trying to sacrifice the mission to improve database accuracy; we’re trying to improve database accuracy within ARIN’s mission. So we need to find a way to reconcile this, but I’ll give some thought to that. Thank you.

Bill Sandiford: Any remote participants? No? All right. Rear microphone.

Joe Provo: Joe Provo, Google, ARIN AC. I have a lot of feels here. I haven’t fully formed all the ideas, but ‑‑ and I don’t want to waste a lot of time extemporizing, but there’s a couple points I have to hit.

Kevin’s LIR comment was the most clear expression of an actual need that I’ve heard. When this first floated, I did not ‑‑ I opposed fully in principle and in text, and I still oppose the text. I do think that codifying practices that are currently viewed as, air quotes, “bad” for on the altar of database accuracy is not the direction we should go, similar to what Chris was saying about not trying to sacrifice our values.

So throwing around the word “need” when we’re saying people are doing a thing, therefore they need it, is not the same as our classical definition of needs‑based.

Secondly, I would posit that the ongoing existence of a gray, very dark gray market of leasing is a pointer to potential fault ‑‑ if not failure, then actually faults in the existing market‑based operation and transfers.

Why ‑‑ why ‑‑ we made the argument, but the ‑‑ when we ‑‑ when we went into a transfer reality, we made the argument that this would provide economic incentives to allow resources to migrate to where they’re needed to be used. And if that’s not fitting the needs, then do we need to reexamine the current transfer policies to enable this behavior to fold within it?

Is there actually ‑‑ people are very allergic to this: Is there a stronger so‑called regulatory hand that should be put into place to make sure that these participants are actually within that space rather than expanding the space of additional marketplaces?

And thirdly ‑‑ what is thirdly? I lost it. Whatever. I’ll come back to it on the list.

Bill Sandiford: Thank you, Joe. Placing a last call for the queues, asking people who have something new to add to join the queues before we close them. Front and center microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I do not support the text as written. I support the concept. Kevin’s had some very good ideas. I also want to bring up that the current ‑‑ there’s an RFC, 2008, that talks about the system that we currently use where ISPs loan addresses to their customers.

The word “loan” was actually used in that RFC, loans and leases, and these are all words that intertwine with each other.

And so I think the days where we can practically require the user of the address space to be connected to the ISP that’s loaning them the address space is an anachronism in the current state of IPv4.

And so we need to figure out how to describe this ‑‑ there’s definitely some things that can go awry in all of this, so we need to sort of describe this correctly and find the right language. But I support the idea.

Bill Sandiford: Thank you, David. Front and center microphone again.

Cathy Aronson: Cathy Aronson. I’m just trying to conceptually understand this, and I’m having really a hard time. So maybe I’ll say it out loud. Basically what you’re saying is people want to lease PI space and that somebody might go and get a big block simply to provide PI space as a business? Is that what this is?

Bill Sandiford: I think what I’m reading is that that’s one possible outcome of this ‑‑

Cathy Aronson: Okay, so you would ‑‑

Bill Sandiford: ‑‑ and there’s a question as to whether or not there should be language to specifically not allow that or allow that.

Cathy Aronson: Okay, I’m just trying ‑‑ like, I’m just having a really hard time understanding it. So if I am, I figure other people are.

So basically, right now, you really do ‑‑ as a customer of an ISP, you’re still leasing space, it’s just leased and attached to the connection that you bought from them. So what you’re saying is that people want blocks of space to use on whatever network and ISP that they choose.

Bill Sandiford: As I’m seeing it, I’m seeing that there’s a couple possible cases of this. One is there may be an IP address holder who is using their space but has extra and wants to monetize it or make it available to somebody else who is not connected to them.

Cathy Aronson: But still retain the rights to it?

Bill Sandiford: Right.

Cathy Aronson: Rob really wants to ‑‑

Bill Sandiford: You take it, Rob.

Robert Seastrom: Let me speak to this with an additional data point, which is PA space is absolutely being monetized today.

Cathy Aronson: Right, totally.

Robert Seastrom: There are perverse incentives here. If you want to keep the amount of space that we gave you 10 years ago, you better give us more revenue.

Cathy Aronson: Right, totally.

Robert Seastrom: That happens every day.

Cathy Aronson: Right. I just think that the wording needs to be ‑‑ like “leasing” is just ambiguous, because people are leasing address space with their connection to Fu (phonetic) that they connect to.

So I’m just personally trying to understand and put into words what the problem is and what people need. So basically you’re just a little guy; you want a block of address space to use on your network. It’s actually being used on an operational network and connecting to some ISP of your choice, right? And you just want to be able to pay something that isn’t an outrageous purchase price on the market to do that.

Robert Seastrom: Or even pay as you go.

Cathy Aronson: Yeah. Okay. Cool. I’m just trying to grock it. Thanks.

Bill Sandiford: Rear microphone.

Scott Johnson: Scott Johnson, SolarNetOne. I rise again to speak to the matter that this is to benefit a small‑ or medium‑sized business. Quite frankly, you can’t get much smaller than my mom‑and‑pop Main Street organization, and yet I’ve had no trouble acquiring through existing means in the policy all of the address space I could possibly ever use in my lifetime and the lifetimes of five generations to come after me.

That’s just not dotted quad. It’s IPv6, which is the real solution to this problem.

Bill Sandiford: All right. Seeing nobody else in queue, we’ll consider the microphones closed.

Kiran Malancharuvil: Just in response to Cathy’s point, I guess I don’t understand, and maybe I’ll look forward to further discussion on the list about this to clarify. This might be as a result of my newness here.

But I guess I don’t really see the problem of getting a block on the market solely for the purpose of leasing if that contributes to sort of a more equitable distribution and equitable access to IPv4.

The bottom line is small businesses do not have the money to buy on the current transfer market. And so if a business does have the money to buy on the transfer market for the purpose of allowing small and medium businesses to access and satisfy this absolute need that they have, I guess I would look forward to some conversation about why that’s necessarily a bad thing, or does it just fly in the face of a tradition that makes it uncomfortable?

Bill Sandiford: Cathy?

Cathy Aronson: I think that the problem right now is that there’s no policy to justify a block if you don’t ‑‑ if you’re not using it to run a network. So, like, if I went to buy from a broker a block of address space, I have no justification if I don’t have a network.

So that may be totally fine, but there has to be a policy that allows for that, because right now there isn’t. If that helps.

Kiran Malancharuvil: Great, thank you.

Bill Sandiford: John?

John Curran: Right now, if you attempt to obtain an address block via the transfer market and you say, I’m obtaining it so that I can hold onto it and lend it out to people, lease it to people, whatever, but I don’t have a network, you’re denied, period, because right now one of the requirements is you need to have operational need.

You need to say, I’m obtaining addresses from ARIN or I’m obtaining addresses from the transfer market through ARIN for purposes of an operational network. No network, no transfer.

Chris Tacit: So I thought a little bit about your question and also your last comments, and perhaps part of the solution here ‑‑

Bill Sandiford: State your name.

Chris Tacit: Chris Tacit.

Perhaps part of the solution here is to actually, if you’re going to allow this sort of thing to happen, to have a utilization requirement within a certain specified period of time. And then the onus is on the party that’s actually acquiring these numbers to make sure they’re put into use fairly promptly at a pretty high level of utilization. Maybe that’s part of the solution.

What I don’t want to see is having IP addresses inventoried because that just drives up the price for everyone, and it’s contrary to the core mandate of having the resources in operational use.

Bill Sandiford: Thank you. John?

John Curran: So the community should decide what it wants to accomplish and make policy to that end.

Consider that the moment that you move to the realm of address space being held by entities that don’t operate networks ‑‑ right now there’s a little bit of stickiness when you operate a network. We all know that when you assign addresses to equipment, you don’t generally pick them up and capriciously move them around because that’s configuration, and who needs extra configuration.

But on the other hand, if what you’re in the business of doing is providing address space to parties for purposes, then when ARIN asks you, What’s your utilization, you can create utilization very quickly. It’s just a record. It’s non‑confirmable.

Your neighbors can get you up to 20, 30, 70, 80, 90 percent on a temporary lease, and you have that arbitrariness of utilization because it’s not actually affected with infrastructure, it’s not an auditable thing.

It’s not to say you can’t figure out a way to do this, but the community needs to decide, if it’s going to go into this realm, what it wants us to verify and how that might be used, because, for example, someone who wishes to entirely engage in financial speculation of address blocks is immediately enabled the moment there’s no requirement for infrastructure.

Is that a bug or is that a feature? That’s for you guys to decide. But just recognize you have to make the policy pretty clear because what you think will happen isn’t what’s going to happen. What will happen is whatever you give us for enforcement, we’ll enforce; whatever you don’t, we won’t. And that may have different consequences.

So it’s not a nontrivial matter to drop the operational need. That’s not to say it can’t be done, but you need to think through and really decide how you want that whole new realm to operate.

Bill Sandiford: All right. Final two comments. Far microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I know that we explicitly avoid thinking of IP address space as a commodity. But as we talk about similar things, like leasing, sometimes those parallels become uncomfortably unavoidable.

Now, I personally have a fundamental and possibly almost religious aversion to the idea of acquiring address space for the purpose of leasing. I also realize that religious beliefs almost never make for good Public Policy.

But I would love to find a way that organizations that have space that needs to be ‑‑ that could be used could have a mechanism for finding uses for the operational use of that space, such as leasing, while at the same time preventing an organization from acquiring space for the purpose of leasing.

I hate to bring in parallels to real estate, but I think of a lot of the regulations that came around Airbnb. To use an example, the initial idea was if you have a spare bedroom, let’s lease it out. But it turned into ‑‑ operators then turned it into a business.

And you may argue either way whether that’s a good thing or not. I personally do not believe that it has improved that market. And I cannot believe that the ability of organizations to acquire space for the purpose of leasing benefits the ARIN community.

The idea ‑‑ again, the idea of leasing I don’t think is fundamentally wrong as long as we can figure out how to remove the ability of organizations to do any sort of speculation through leasing.

Bill Sandiford: Thank you. Final comment, Joe.

Joe Provo: Joe Provo, Google, ARIN AC. I remembered my third point when Scott came up to the microphone.

In this policy and a few others that have been floated around, there’s been some, hey, we’re unlike other RIRs in X.

Yeah, that’s true. We are. Specifically in the v4 runout realm, we opted for hard landing, not soft landing. Other RIRs opted for soft landing. One of the arguments for hard landing when we went down that road was the economic incentive to improve utilization of v6. This policy is attempting to undercut that incentive.

And I’ll reiterate, striking operational need requirement is a bad thing, so I don’t endorse that. I do like the LIR example that Mr. Blumberg brought up. It’s clearly about operating networks and not about speculation. So that area should be explored.

Bill Sandiford: Thank you. All right. That concludes the discussion. Thank you, Rob, for your presentation.

(Applause.)

John Curran: So we have several things going on now. If you’re a remote participant, we’re going to try to get you synced up. Right now the video and audio are out of sync. Of course you won’t hear this because they’re out of sync, but by the time you hear it ‑‑ anyway. But that means we’re going to restart the remote feed, and we’re going to do that now. Go ahead, take it.

While we’re doing that, we’re going to have a presentation, but it’s not one that’s policy-related, so they can catch up online. I’m actually going to ask John Sweeting to come up talk about an initiative going on, coordinated among the five RIRs and ICANN, about indicators for the health of the Internet Number Registry System. So, John, all yours.

Identifier Technology Health Indicators (ITHI): ARIN’s Initial Results

John Sweeting: Good morning. So this Identifier Technology Health Indicators is the project that was started in ICANN, and they reached out to the NRO EC who said, yeah, we’ll be part of it, but we’ll manage it. We’ll do the numbers, look at the health of the numbers and come up with all the metrics and do the reporting, and the report will go up on the NRO website.

Just a quick summary of what this is. The goal of ITHI is to measure developed metrics designed to track the health of the Internet’s unique identifier systems, which in our case is the number resources, IPv4 and IPv6.

We’ve developed this system. We did community consultations. We did a global community consultation. We took the input from that and we came up with the metrics that were then approved by the NRO EC.

Initial measurements are in process by each of the RIRs. ARIN, all the RIRs have completed the comprehensive side of it, which is one of the measurements, and ARIN has completed all three of those measurements. So I’m going to go into that and give a little report here to you on those statistics.

I’ve already told you all that slide. So metrics. We did ‑‑ there’s three ‑‑ there’s comprehensive, correct, and current.

So the first one, on comprehensive, there was two criteria. That was complete and unique. Complete meant that all the Internet number resources administered by each RIR is accounted for in the NRO extended delegated stats and that there are no duplicates of those numbers.

If it ends up that something’s missing or there’s a duplicate, the Regional Internet Registry registration managers will get notified via an email ‑‑ hey, we’ve got this problem; you need to figure it out ‑‑ and we’ll go in and figure that out.

That global measurement is performed by the RIPE NCC, and they’re the ones that have set everything up and make it to where we get alerted. Yes, Lee?

Lee Howard: Lee Howard, IPv4.Global. It’s early after a really long week, and that’s a lot of TLAs that ‑‑ I know what they all mean. It’s just a little overwhelming.

John Sweeting: Okay, so you were just confused. Okay.

So did I go one too many? To be comprehensive, there’s two ‑‑ oh, no, I didn’t go one too many. Yeah, it’s been a long week, Lee.

So some of the other metrics to be comprehensive, do the Internet number resources registered by ARIN have a required Point of Contact with an email address? Do the Internet number resources registered by ARIN have the required organization’s legal name and street address? And the local measurement is performed by ARIN. So we use things that are contained in our database to check the comprehensiveness of our data.

And basically, remember, for comprehensive, all that infers is that there is actually an email address in the field. There’s supposed to be an email address for a POC, and there’s also a street address in the field that they’re supposed to be for an organization and also a legal name.

So when we did the ‑‑ we run the report, we come up with ‑‑ so the yellow is those under agreement, and so that could be legacy under agreement or anything that’s been directly issued by ARIN. And the gray is those that are not under agreement, which would be legacy that’s not under an agreement with ARIN.

So as you can see, Orgs with name and address, we’re at 100 percent for those that are under an agreement, 96.9 percent for those not under an agreement. POCs with emails, again, 100 percent on those under agreement, 82 percent not under. And both Orgs and POCs, 100 percent for those under agreement, 80 percent for those not under an agreement.

So for the correctness of everything, the metrics, required registration data listed for organizations to hold Internet number resources has to match official sources. So in the ARIN database, that means they must have been vetted. They must be marked as vetted. Which means we have gone through the process of looking at Secretary of State websites, all different kinds of things that we ‑‑ tools that we have that we look at to make sure that a company is ‑‑ actually vets, is actually real.

And the required ‑‑ of course we use the validation of the POC data to make sure that that is correct. And again that is a local measurement that is performed by ARIN because, of course, the other RIRs don’t necessarily have those same metrics to test. They don’t have a vetted field possibly or they don’t have a validated field for POCs. But we do, and that’s what we use.

So the stats on that. For the number of correct vetted organizations, for those under contract is 86 percent; for those not under agreement, it’s 10.5 percent. For validated POCs, under contract, 80 percent; not under contract, 20.9 percent.

And then they have both, both the Orgs have been vetted and the POC’s been validated, under agreement, 70 percent; not under agreement, 7 percent.

Moving on to current. So current is saying, hey, when did ‑‑ when is the last time you checked to make sure that these companies were vetted, are still vetted or that the POCs were validated.

For both we used the five‑year requirement, although for validated it’s really ‑‑ it’s one year because POCs have to validate every year per policy. And that local measurement is performed, again, by ARIN.

And when we go into the number, the currentness of our data in the ARIN database, Orgs have been vetted within the last five years, 58.7 percent under contract; 5 percent not under contract. POCs validated within the last five years, 98.1 percent under contract; 32 percent not under contract. And both Orgs and POCs, 58.5 percent under contract; 4.7 not under contract.

So these numbers pretty much show that for the resources that are under contract with ARIN, that the correctness of the data is much better than those that are not under contract. So we’re hoping to do things that will allow us to increase those percentages a lot.

Just remember on the current, where it’s been vetted in the last five years, 58.7 percent have been vetted. That doesn’t mean that those are correct. You have to go back to the correctness to see which ones were vetted in the first place and were good. So it’s a stepping stone.

You’ve got the comprehensiveness that there’s actually data there, then the correctness that it was actually at one time correct, and then the currentness that shows you how current that information is. So it gives you more of a feeling of whether you can trust that data or not.

So that kind of sums it up. We’ll be giving this report ‑‑ it probably will end up in the NRO statistics that ‑‑ the presentation I gave at the start of this meeting yesterday. These statistics will probably show up there for all the RIRs once we have the complete set of data, which will probably be at the next ARIN meeting. Yes, John.

John Curran: I’d like to answer the question at the mic. Ruediger, these metrics do not include any measurement of the overlap or intersection or gap between the five RIRs. So a gap in ‑‑ where a number resource is or a mismatch is not included in these measurements.

This is something intended to take to the other RIRs to discuss, and ICANN, to see if we can get measurements of such because we know those occur on occasion.

Did you have a question?

Ruediger Volk: Kind of. The question ‑‑ I’m looking forward to hear in the NRO activity reports what you’re actually doing there. For John’s presentation, I’m looking into that direction, but John’s presentation kind of has a hook where I want to hang on.

You were saying and starting that the investigation for the quality started or included an analysis of the consistency of extended delegated with the RIR data.

I wonder whether that is something that happened as a one‑shot thing.

And in early May things looked nice, and the fact that the way the maintenance of the common delegated extended of the NRO is patched together in a way so that later in May the ARIN ASes all disappeared, or other things that probably are happening. That incident was by far not the first where people could see inconsistencies and problems, and it certainly was not the last.

Is the quality thing and consistency check something that will be established as continuing activity, or was this just a one‑shot?

John Curran: As noted, you’re talking about extended stats as produced by the NRO. That’s not actually what these measure. These only measure the data in the ARIN database.

Ruediger Volk: John started talking about consistency between the RIR data, like ARIN, and all these specifics of the ARIN data obviously are private to the ARIN considerations. But he started quite correctly, I think, with saying, well, okay, the consistency between the NRO joined delegated extended with the RIR data has been analyzed.

John Curran: Right now, the scope of these statistics do not include metrics that would address your question because each RIR will produce consistency measurements on its own and currency measurements on its own, and the union of those would be reported.

I’m going to bring to the NRO this issue to discuss. But as I kind of noted both during and before your question, the scope of these don’t cover the issue you have.

John Sweeting: Ruediger, the first stats, the comprehensive is broken into two parts. And I only showed stats on the second part, which is germane only to the ARIN database. I didn’t report on the global numbers of the extended stats.

Ruediger Volk: Kind of understood. John, let me point back to yesterday you were somewhere making a statement about, yes, in fact we should consider there is one registry. I laud that approach and view very much, but we are just seeing and pointing to gaps in that vision.

John Curran: Well aware of that. Recognize that the current Internet registry ‑‑ I use that term ‑‑ two letters, Internet registry, which is the term that’s been used since, I don’t know, 1991 ‑‑ does not consist of a single database or a single union database that has one entry for every unique range.

It consists of many registries, which, if you hold up every address block, should be in one, and all the others should have pointers to that one. That is not the current state, but it is certainly what it should be.

Andrew?

Betty Fausta: Excuse me. Just a question. Betty Fausta from Guadeloupe, French Caribbean. I would like to note you’re talking about checking address at the base and many things for our POC, and I would like to know how you introduce the consent of people from French Caribbean of – what is the impact of GDPR of all the stuff you’re checking?

John Sweeting: Could you repeat the question, please?

Betty Fausta: I want to know exactly what is the impact of GDPR of the work you do about checking all the data you have.

Kevin Blumberg: The question was how does GDPR apply to the checking that is done with this data, was the question.

John Sweeting: This is data that’s contained within the ARIN database that there’s a report run through ‑‑ runs through those data fields just to check the data in those fields. And none of that data is reported; only the stats.

We don’t know ‑‑ we don’t have any idea ‑‑ we don’t get a report that shows what was in those fields. We just get a report of whether those fields, if it’s ‑‑ if they’re a POC and it’s got a check for validated, that’s what we’re checking. If it’s an Org and it says vetted, that’s what we’re checking that field that says vetted.

For the comprehensive, if there’s something there, we just check to make sure there’s something’s there. It could be ABCDEFG, and there is something there in that field. I’m not really sure how it ties to GDPR.

Kevin?

Kevin Blumberg: Kevin Blumberg, The Wire. I’m assuming this is baseline for the next and next and next. Do you have a frequency, is the first question, of when you plan to run the reports? I don’t know how much work went into it, how automated it is. But how often do you plan to run this?

John Sweeting: Thanks to our great engineering team, I can run it, like, anytime I want to run it. But we’re going to do ‑‑ we’re actually going to capture it and keep it for comparison data monthly when we do all our other stats.

Kevin Blumberg: Thank you.

And the level of information was very useful. Obviously as more data over time comes up and we can see the percentages going up in that accuracy, that would be wonderful.

But there’s one thing that’s missing from this, and that is the correlation of size of blocks from an impact perspective, i.e., 5 percent of something was invalid is not really relevant if you don’t know that that is a hundred /24s of IPv4 space; it’s not that important.

But if that 5 percent happened to encompass a million /24s, then that is a far more important piece of information.

So if there’s any way to have that correlation of 5 percent equals, you know, this amount of the registered space, or whatever the case may be, that would at least allow for some better understanding of this data.

John Sweeting: Correct. Very interesting. And of course that happens with everything. Every time we use percentages, as in the transfers, when we do the number of transfers and then we do the total number of addresses, there’s no correlation there.

Lots of times there could be a lot ‑‑ somebody does a lot of transfers and very little addresses are moved if somebody does new transfers and a lot of addresses ‑‑

Kevin Blumberg: Exactly.

John Sweeting: That’s something that we discussed internally in my shop, and it’s something that we want to do. But these were requirements that we were asked to meet by the NRO, and the whole RIR registration services managers got together.

And this was the low‑hanging fruit to actually start and get a report that we could put out to the community. And that’s what we’re looking for now, input from the community. And ARIN, we can go off and do things on our own and report on our own outside of this report. These are the things we have to report for the NRO report, though.

Kevin Blumberg: Thank you.

Andrew Dul: Andrew Dul. On Slide 8, if you could go back, I believe the first column has a number that’s, like, 84 percent ‑‑ 86 percent.

What does vetted mean in this context? What is the 14 percent of Orgs not doing? Or what is missing for those 14 percent?

John Sweeting: Those 14 percent could be organizations from before the time that we actually had that ability to mark them as vetted. So early, maybe like in 2000, 2001. I’m not sure, Lisa, if you know when they ‑‑ when we first started actually vetting Orgs and started marking them as vetted.

But it could also be Orgs that have come in and asked for resources or something, and we’ve looked and we have tried to vet them and they don’t vet, so we take away, we remove their vetted status.

Andrew Dul: So there could be Orgs with no resources attached in that column?

John Sweeting: No, there’s Orgs that have resources that are no longer Orgs ‑‑ organizations that are registered, legally registered in a state that we can find.

And they haven’t come to us for any action. So we can’t force them to do an M&A transfer if they’ve changed. It could be M&As that have happened and we know they’ve happened and that organization has gone away, so they no longer vet. But this organization that acquired them has not done the transfer yet.

There’s ‑‑

Andrew Dul: What does vetted mean?

John Sweeting: Vetted means that we’ve gone out and checked, like I said, the Secretary of State websites, which is our most common way of vetting. We go in and look for that organization; we find it, it is registered. It will say it’s in good standing. It’s paid its taxes. It was registered in 2001 and it’s still valid.

Andrew Dul: So a non‑vetted Org is one where there’s a name, a field that doesn’t match a recorded ‑‑

John Sweeting: Right, we cannot find them anywhere. And it could be that they changed states and they never came and told us that they changed states. So we’re looking at one state and they’re actually incorporated in another state.

When we do that, if we go and look and find they don’t vet, we remove that vet checklist from that organization until they come back to us again, realizing we only have any kind of power or ‑‑ I hate to use the word “power,” but we can only ask them to do M&A transfers when they’re trying to do something else. And we can say, well, you can’t do that until you actually update your records and get the right organization in there.

John Curran: Folks, I’m closing the microphones. Unless you have an urgent need to speak to this, go to the mics now. Otherwise, the last two speakers are the last two speakers.

John Sweeting: Kerrie.

Kerrie Richards: I see that it would be easy to figure it out or to vet companies that are based in Canada and the U.S. How do you deal with some of the other people in the Caribbean or businesses in the Caribbean? How would you deal with that, vetting those?

John Sweeting: I’m going to take a stab at that, and then I’m going to ask Lisa to keep me honest here.

I believe for the most part we will request that the documentation be sent to us from the organization to show their paper’s in good standing. And we will usually accept that.

And I know you cringe and I know we cringe, but for some of the ‑‑ even in some of the states, it’s very, very difficult.

Lisa, do you want to get up and talk to that, or did I cover it pretty well?

Kerrie Richards: Okay, thanks.

John Sweeting: Sometimes you have to trust ‑‑ and it goes into depending, Kerrie, on the actual transaction that they’re attempting. If somebody’s attempting to claim a /16 and transfer it to somebody, we’re going to need more than just them sending us something saying that’s who they are. So we have other ways of doing things.

Owen.

Owen DeLong: So we’ve focused a lot on Secretary of State and all that. And that works great for entities that are incorporated, but I’m wondering how many of those unvetted Orgs, rather, are unvetted as a result of the fact that they’re simply not corporations.

John Sweeting: We have all the ‑‑ LLCs are also covered ‑‑

Owen DeLong: An LLC is a limited liability corporation. But, for example, Org ID DeLong is not a corporation in any way, shape or form.

John Sweeting: You don’t vet.

Owen DeLong: I don’t vet?

John Sweeting: You don’t vet.

Owen DeLong: I get tossed into the unvetted pile simply because I’m not a corporation.

John Sweeting: No, because simply you’re not legally registered to do business in the state.

John Curran: That’s correct.

Owen DeLong: But I am.

John Sweeting: Then you send us the papers and we go and check, we do a third‑party validation of that, and then you’re vetted. For the most part, we use Secretary of State, and I say we have other tools to do strange companies like you.

John Curran: We can’t remotely and automatically vet you, yes.

Owen DeLong: There’s lots of business structures, like sole proprietorships and whatnot, that are not incorporated and the Secretary of State doesn’t deal with them but have legitimate fictitious names and all the other stuff.

John Curran: Right.

John Sweeting: We deal with all that. Lisa could give you all the tools that they use. I don’t use them on a daily basis. But, yes, we do deal with all the fictitious names registered.

They all have to be registered, though. If they’re not registered with anybody to do business legally in the ARIN region, then they do not vet. I was just giving examples, Owen, thank you for keeping me honest.

John Curran: Thank you, John.

(Applause.)

NRO Activities Report

John Curran: We’re back on schedule and a little behind even. And we have our remote viewers back.

I’m going to give the next report. It’s the NRO Activities Report. I see the esteemed Paul Wilson here. Paul, do you want to give the NRO update, or do you want me to?

Paul Wilson: No.

(Laughter.)

John Curran: I shall give it.

The NRO, we all know what that is. It’s the Number Resource Organization. It’s the coordinating entity of the five RIRs. We have an MoU that defines the terms of it.

We promote the RIR system and the multi‑stakeholder model, including bottoms‑up policy development. So, the community works up and develops policy that we use to run this. It’s not a regulatory case where it comes down from government or down from some other authority. But we fulfill the role of the ICANN ASO.

So we’re called the NRO. In ICANN’s bylaws there’s an organization called the Address Supporting Organization. And there’s a line that says: The NRO shall fulfill the functions, roles, responsibilities of the ASO.

So, while we say NRO, whenever we go into ICANN, we wrap ourselves in a cloak that says ASO and change all the names. That is also why our NRO Number Council is affectionately referred to as the ASO AC within ICANN. That’s why the NRO is called the ASO. This has come up in reviews of the ASO. It’s one of the items we’ll talk about.

So each RIR executive director or CEO sits on the executive committee ‑‑ Axel Pawlik, Paul Wilson, Oscar, myself, and Patrisse for each of the RIRs. We have a Secretariat, which is hosted by APNIC, and an Executive Secretary, German. And Susannah helps out with running the secretariat with German.

We have coordination groups. So, every time we discuss something like statistics, transfers, registry, services, protocols ‑‑ those coordination groups are involved in all of that, that have the respective leaders of the respective departments of each of the RIRs.

So it’s how we take this group of five organizations and run a coordinated ‑‑ loosely coordinated Internet number registry system.

And we have informal groups that also coordinate just to make sure on things like public affairs policy, dealing with financial matters, we’re using the same terminology.

We publish things. So the most common thing that we publish is the NRO statistics, which we collect from each of the RIRs and publish in a common format, and that’s NRO statistics. We’ve added RPKI adoption reports to that.

We have the extended ‑‑ this year we rolled out a new extended stats file which creates statistics for each of the RIRs in a more common format. Not 100 percent there, but getting close.

And we do a comparative policy overview. If you want to know what the policy is in another RIR for transfers, for ASNs, you can bring up the comparative policy overview, and it divides the body of policy in each of the five RIRs into easy‑to‑read categories so it’s pretty easy to pick up.

And then, of course, we wrap ourselves in that ASO cloak and become the Address Supporting Organization. There’s an ICANN website which deals with the aspects of the NRO that we do under the ICANN umbrella.

We have a budget. So we all put money into the budget. It pays for the secretary, the website and some of the common travel, like the ASO chair. And so our fees that we pay collectively ‑‑ for example, we pay for the IANA.

We also have a joint contribution to ICANN. And it’s about $560,000 US Dollars is general operations. The contribution to ICANN, $823,000. It’s been that since the formation of ICANN. We’ve delineated that to be $650 for the IANA numbers services contract and a voluntary contribution of everything else of $173,000.

We have a Stability Fund. We’ve jointly pledged to help each other in times of need. And that could be financial or it could be staffing, because, again, we’re running one coordinated registry. If one of the RIRs has a really bad time, we’ll all help out, making sure we don’t lose a portion of the number registry system.

Cost distribution. So we have a budget, all those prior numbers. We actually charge each of the RIRs based on a formula, based on the size of the RIR, the revenues that each receives.

This is the cost distribution. So ARIN pays about 27 percent; RIPE, 31; APNIC, 22; AFRINIC and LACNIC, 7 and 10 percent respectively.

IANA Review Committee. I mentioned that earlier. We don’t do much. We don’t have many requests. It’s when we get a new ASN block or when RIPE went and got their v6 block or when ARIN will soon go get one. We put in a request; the IANA processes it.

So, there’s a handful of requests to the IANA each year. Having said that, we have a community‑based Review Committee, two members from the community in each region, one RIR staff. And they review the performance of the IANA and help the NRO EC, the executive committee, know that, indeed, IANA is performing its job and we should continue to use them.

And they publish a report. So their report for 2018 is published there, and you can see the IANA has done a wonderful job.

The Review Committee members from this region, Louie Lee and Jason Schiller, and it has two community members and one staff. Richard Jimmerson, our chief operating officer, is the staff member.

ICANN Empowered Community. You guys might already know about it. For those who don’t, when we went through this whole reformation effort, we reformed how ICANN was effectively charged with its mission of doing the IANA functions. It used to be those were done under a zero dollar, US government contract.

We went through a prolonged process a few years back where those functions now are being done by ICANN, or its technical affiliate, PTI, are being done as tasks charged by the affected community.

In the case of the IETF, there’s an MoU that says to ICANN: Operate all the protocol registries. Port numbers is a protocol registry. MIME types is a protocol registry. MPLS IDs ‑‑ there’s 2,000 protocol registries.

Every time you create a protocol, you often create a handful of registries. Those registered that are defined in the IETF, they have an MoU with ICANN that says: Operate all those registries for us. And they have a lot more requests than we do.

One of the other sets of registries is the six number registries. That’s IPv4 unallocated, IPv6 unallocated, ASN 32, ASN 64‑bit. Those are the registries that they allocate for us.

Now, the v4 one is kind of empty. V6 has a lot of space. The ASNs have space. We don’t do many requests, but that’s now done ‑‑ it’s something done as a US government contract. It’s being done again under our service agreement with them.

And the last thing they operate is root zone, and that used to be operated under US government contract, but now it’s technically ICANN ‑‑ the community tells ICANN, the operator, to run the ICANN DNS root zone.

The community wanted to have overarching control. So when we did this whole process, they created the ICANN Empowered Community, which actually has the ability to remove ICANN board members, replace the whole Board ‑‑ it has very strong powers ‑‑ and asked that some of the organizations like us participate.

So we actually are a member of the ICANN Empowered Community. Whenever you elect an ICANN director, we are one of the parties that has to acknowledge that the director should be put on the Board. Whenever they change their bylaws, we have to acknowledge that.

It has the various bodies of ICANN. So we’re part of it. And the DNS, the GNSO, the government NSO, the CCSO, the general purpose ‑‑ sorry. Wow, I got that wrong.

So, ASO, GNSO, ccNSO, the at‑large community are all members of the at‑large ‑‑ including the Governmental Advisory Committee. It’s a little bit of overhead, but it helps keep stability at ICANN.

You can see what we’ve done whenever we approve something that shows up on the NRO website.

ASO review. Periodically we’re required by ICANN to do a review of the ASO’s effectiveness within ICANN, which is reviewing how the functions that we ask ICANN to do for us, that we do within the ICANN structure under that, are performed.

So it’s a little interesting because we don’t do much with ICANN. We do a lot to help them. But in terms of what we do within the ICANN structure for the numbers community, it’s only development global policies, and we haven’t done one of those in five years.

Having said that, there was a review. We came up with 18 recommendations. We are working to improve all of those and act on all of those. Some of those are administrative, making sure the website’s updated. Some of those are procedural. Some of those are pretty significant items, like there’s some confusion over whether we should call you ASO or NRO. Can you fix that?

We actually launched our own consultation about the future of the ASO long term, not the past performance of effectiveness, but future, how you want this structured.

So you can see our implementation report of the independent review. You can see the launch of our public consultation for the future structure of the ASO, which was one of the 18 recommendations is to have this. And we’re still working through that.

Trying to figure out long-term how we work with ICANN is an open question. We have a stable arrangement, but it’s a pretty complicated, not well‑documented, significant overhead arrangement. It might be the price for stability. That just may be the way it is. But we are busy working with the community through this.

Technical projects. We have a number of technical projects we’re doing.

Emergency Backup Operations. If an RIR is technically unable to perform and someone actually wants to know what the Whois database looks like in that region or the DNS reverse services are, because they’re in a situation of nonperformance, it would be nice if we could restore temporary services.

The extended RIR Number Status Report, which is giving the status on transfers and status of the database free pools in all the regions.

RDAP. RDAP is a replacement for Whois, which includes the ability to link. So when you do a query, if you query the wrong RIR, it will chain to the right one. Or if you query an RIR and we’ve delegated it to someone and they run an RDAP server, it will chain to them. Sort of like RWhois but better.

And support for better character sets and a whole bunch of other things. We’re busy working on the technical aspects of RDAP.

There’s this Internet Technology Health Indicator project that ICANN asked us to launch, and you just saw a report about, about trying to measuring the accuracy and comprehensiveness of the Internet number registry system.

We just revamped the NRO website. That seems to be something what people who have websites do every few years, and we just did ours. And we redid the ASO website. Both of them are hopefully clearer, better organized, and easier for you to find things on.

So that’s the NRO Activities Report. Any questions? Ruediger.

Ruediger Volk: John, in the discussion after the last presentation, I was pointing to delegated extended. I didn’t hear you report anything about quality assurance for that.

I mentioned observations of incidents in particular with relevancy for ARIN. I wonder whether there is any activity, any plans, any achievements?

John Curran: We’ve received reports of concerns about accuracy in the extended stats file. And we’re going to be meeting shortly, in the next week, and those reports will be discussed.

I don’t know what level of resources will be put on them or what the joint decision will be, but we do understand there’s some concerns that some entries may not be accurate in the extended stats file. That has been received. In fact, I believe you sent a report in to the NRO to that effect.

Ruediger Volk: I reported a big failure of ARIN data at the RIPE Reykjavik meeting, and I reported something more recently, yes.

John Curran: Yes, we have the reports. And we’re meeting next week. Actually, yeah, next week, we’re meeting next week. And then we’ll have a discussion of those same reports.

Any other questions on the NRO Activities Report?

Okay. I’m now going to ask ‑‑ we have an NRO Number Council, also known as the ASO AC in ICANN. I’ll have Kevin Blumberg come up and give the NRO NC Report.

NRO Number Council Report

Kevin Blumberg: Good morning, everybody. John actually did a lot of the informational aspects between the ASO and the NRO, the differences in the last slide. Just because of time I’ll go through a little faster.

There’s lots of information online and absolutely willing to talk. And if you’ve got any questions, something that might have been missed, by all means please ask.

The NRO Number Council is basically made up of 15 members, three from each of the five regions. Two are elected; one is appointed. And I’m the appointed member from the ARIN region. The term of office is different for each region. In the ARIN region, it is three years.

We do a couple of things. Global Number Policy is the most important obviously from a perspective of this community. We also do seats 9 and 10 for the ICANN Board. We provide those, the work that goes into that. And on occasion we are asked for advice from the ICANN Board and for clarifications related to number policy.

So we do a telephone call monthly. We meet in person at the first ICANN meeting is what it is, currently in March. So we’ll go to the slide. A list of all the people. I’m currently the vice chair for that with Jorge. Aftab Siddiqui is the chair of the ASO AC. And all of the terms are listed.

One thing that we felt was very important to do, because these are elected positions, we wanted you to know and to be able to see the running stats through the year, because we do these presentations and update people consistently, the attendance statistics for each of the elected and appointed positions for each of the regions so you can have a sense of that. It’s available on the website: aso.icann.org.

There’s lots of documents on there. And they are ‑‑ as John said, the website is going to be going through an overhaul to make it more mobile friendly for when we’re at conferences and looking at it. Quick question?

Patrick Gilmore: How did many people attend ten meetings out of nine?

Kevin Blumberg: There was a typo there, but I appreciate you picking that up. That will get passed on to the staff who generate that slide for us.

John Curran: There is enormous enthusiasm on their part.

(Laughter.)

Kevin Blumberg: One of the important things to understand about what the ASO does is this graph. You’ve got all the five regions. You’ve got the ASO and you’ve got ICANN. And we deal with global policies.

So what is a global policy? A global policy is something that really is about the regions directing IANA on how to get space from IANA/PTI, the new company name, so from IANA to the registries or from the registries to IANA. That is it.

It is not about coordinated policies between all of the regions, things that are good between the regions. That’s handled in the regional policies or coordinated regional policies. But really the global policies and ‑‑ which are its own section in NRPM ‑‑ are about getting space there, getting space back or other identifiers.

We had something called the PPFT. The idea of the PPFT from each region is that we are watching for global policies or things that may be global in nature, and then those get reported back. And Jason Schiller was our PPFT member for 2019, and to the best of my knowledge as of today there are no global policies in the works.

We completed the ICANN Seat 10 Board election. We had three nominations. One withdrew their nomination. And Akinori was selected by the ASO for the next term. All of the dates are listed there. It’s a fairly comprehensive nomination interview and selection process ‑‑ very, very comprehensive, actually. And from this region, I was on the interview committee.

For 2019, we’d like to talk about all of the things that we have done in terms of appointments from the ASO AC into other things within ICANN. And for 2019 Brajesh Jain was part of the NomCom, the ICANN NomCom.

You’ll notice there really isn’t anything else there. And that’s an active aspect of making sure and having a direction of doing things within ICANN that have a numbers focus.

We could take on thousands of things and we are asked many, many things within ICANN to be a part of. It’s a very inclusive ‑‑ and they would love as many people to participate in all of the different working groups that exist.

But there’s a very important litmus test that we follow to make sure that this is important to the numbers community and not just generically to help ICANN and the constituents within that.

There’s 15 of us. We would never have enough time in the world and it would affect being able to do things when it was actually relevant to that numbers community.

For 2020, we followed a similar nomination and selection process. So the NomCom position for the ASO AC, because we’re given one position as part of ‑‑ I believe it’s directly part of the MoU ‑‑ it is an open selection.

We want somebody ‑‑ it does not have to be from the ASO AC directly. We want somebody from the numbers community who is able to understand the numbers community, provide input and give feedback. But it does not necessarily need to be an ASO AC member. And in this case it was not. It was Pankaj Chaturvedi, and I apologize if I pronounced that incorrectly.

So John mentioned earlier that we had the ASO review. Many recommendations. The ASO AC reported back to the NRO EC that we had completed substantially all of the recommendations that we were able to do. Notes were given.

And the biggest change is we’ve opened up a lot of what we do. All of our teleconferences now are open. You can dial in. The information is posted on the website, how you can connect in.

Our in‑person meetings, our in‑person workgroups are open for observers. There’s the discussion list. Our day‑to‑day discussions have gone from a closed list to an open list.

The only thing that we have kept closed is the Board selection process and the NomCom selection process, which obviously, for privacy reasons, does need to be kept closed.

We’re meeting next week. Our agenda has been posted to the list. Monday is a fully open day for all of the things that we’re doing. Wednesday is all related to the procedures of the NomCom and is being kept closed.

But it’s a substantive difference. It was one of the key recommendations and key requests from the community that we open up as much as possible. And we took that to heart and have done just that.

So I’m really looking forward to feedback from the community now that they can see the things we do work on.

And this is a hard slide for me and an important slide. I want to thank Jason. And Jason Schiller has been on the NRO NC for 11 years, just shy of 12.

For me, personally, he made it tolerable. And by “tolerable” is there is a huge amount of work. There’s a huge amount of acronyms. There’s a huge amount of differences between our community and the ICANN community. And he was able to show me and shepherd me along and help me and help Louie and help the community.

He spent inordinate amounts of time on pedantic policies that we would cycle backwards and forwards through. And he was always able to see a way through on that. And thank you, Jason, for your service.

(Applause.)

And lastly, please vote. It’s an important role, and we want your help. So, thank you.

John Curran: Any questions for Kevin on his presentation?

(No response.)

Thank you Kevin.

(Applause.)

Okay, racing to the end of our Public Policy Meeting. We have a few more updates. I’d like to have Jennifer Bly come up and give the ARIN Community Grant Program.

ARIN Community Grant Program

Jennifer Bly: Good morning, everyone. I’m excited to talk to you a little bit about the ARIN Community Grant Program. This was the very first year. It launched earlier in 2019. And it was designed to provide financial grants in support of initiatives that improve the overall Internet industry and Internet user environment.

To be eligible for a grant, projects must align with ARIN’s mission and fit into one of the three following broad categories: Internet technical improvements that promote and facilitate the expansion, development, and growth of infrastructure of the Internet, consistent with the public interest; registry processes and technology improvements that maintain a globally consistent and highly usable Internet numbers registry system; or informational outreach that advances the Internet by covering topics like IPv6 deployment, Internet research, or Internet governance.

And also projects must benefit the Internet community within the ARIN region.

The Grant Selection Committee consisted of five members including Susan Hamlin, Michael Abejuela, Peter Harrison, Tina Morris, and Matthew Wilder. Thank you very much for your service on the committee. And the program was facilitated by me.

In terms of evaluation, the Grant Selection Committee reviewed all the applications and made their recommendations based on the following selection criteria: completeness, alignment with eligibility guidelines, relevance and reach, and the likelihood of success.

And then after the Grant Selection Committee made their recommendations, the FinCom and Board of Trustees reviewed and approved these selections.

A little bit of stats from the program. There were 23 applications this year. And as each applicant self‑reported, there were three associations, 10 corporations, one LLC, and nine “other” organizations; two from Canada, 16 from the US, and five from outside the ARIN region.

Eleven classified themselves as Internet technical improvements, three as registry processes and technology improvements, and 16 as informational outreach. And projects sometimes identified themselves in more than one category.

The total funding requested was over $350,000, and average funding requested was about $15,000.

There were four projects selected to receive a grant, and ARIN provided $44,500 in funding this year.

I’d like to introduce you to the four projects that were selected for funding.

They included DNS Open‑Source Tools Enhancement & Maintenance by DNS‑OARC at $7,500; IPv6 Training for Enterprises by the Industry Network Technology Council at $20,000; the CrypTech Open Source Cryptography Project by CrypTech/Stichting NLnet at $10,000; and the Global NOG Alliance Admin Tool by the Global NOG Alliance at $5,000.

So congratulations to these first ARIN Community Grant Recipients.

(Applause.)

As far as reporting requirements go, each recipient will submit reports, one due in March of next year and one in September of 2020. And this will explain how the project met its objectives, how the funds were spent, the outcomes, the number of individuals reached, and how the Internet industry benefited in the ARIN region.

Each recipient will be encouraged to share their project results in a blog on TeamARIN and here at an ARIN Public Policy and Members Meeting.

Next year, you can expect to see updates to the program based on the lessons learned from our first run. And we’ll be accepting applications in March of 2020.

If you know of a project that needs funding, it’s not for commercial gain, and benefits the Internet community within the ARIN region, you are strongly encouraged to apply. Please let your friends and colleagues know as well. You can learn more about the program and apply on ARIN’s website.

Any questions?

John Curran: Any questions on the Community Grant Program? Yes. Far microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. You said $45,000 was the total amount granted in 2019. According to the ‑‑ querying the website, the budget for the grant program was $60,000, which suggests that there was $15,000 in unused funds.

Is that a function of the fact that there were ‑‑ it doesn’t seem like that’s for lack of applications. Is it just a matter of applications that just didn’t meet the bar in the grant committee’s view, or were there other reasons that that $15,000 was left not – unused?

Jennifer Bly: Basically, the committee evaluated all the applications and made the decision to award funds to the projects that they felt would benefit the Internet community the most in the ARIN region, according to the selection criteria. So it was a purposeful decision.

Chris Woodfield: Okay, thank you.

John Curran: Okay. Thank you, Jennifer.

(Applause.)

Okay, I have one more update, and then we’ll go into Open Mic and Closing Announcements, the Closing Announcements for the Public Policy Meeting. We have our Members Meeting to follow.

The last update is Internet Routing Registry update and RPKI. It says Richard. Oh, that’s right. Richard, come on up. Why don’t you give it? I like that. I suspect I’ll be involved in Q&A, but you can give the presentation.

Internet Routing Registry Update and RPKI Update

Richard Jimmerson: John, there are three parts to this presentation. I’ll do the first two, and then I’ll be happy to leave the last one to you if you’d like, sir.

So we have two large projects that are going on inside the ARIN organization right now. We’ve just completed a major project in the revamp and the update of the user interface for ARIN Online. For all of you, I hope you’re enjoying that.

Also updated the website earlier this year and some related improvements to our services. And we’ve delved straight into these projects.

We’re working on a new Internet Routing Registry at ARIN and also making some RPKI improvements inside our service offering.

A bit about the routing registry to start. This project started in late Q2 of this year. The project itself, inside the ARIN organization we have a product owner, and the product owner is John Sweeting. He’s working very closely with the staff organization inside ARIN, developing this new product and also community stakeholders to make sure the product we create meets the needs of the community.

The stakeholders that we are working with include Jared Mauch, Nathan Newman, Rob Seastrom, and Job Snijders. Now, the product we’re creating, based on their guidance, the feedback that we had gotten through a consultation with the community in the previous year, we are going to include both an easy “point, click, and ship” product and expert modes in the interfacing with the routing registry at ARIN.

So there will be an easy‑to‑use user interface for people who want to go in and just create objects and update the routing registry information inside ARIN Online, much like you do today with creating reassignments or updating your records inside ARIN Online, but you’ll also be able to interact with us through REST and other forms.

The objects to be supported initially on include route objects, route6 objects, as‑set, aut‑num objects, inetnum objects. We’re also looking at route‑set objects that I don’t have on the list here with our stakeholders.

There will be some integration with RPKI with the routing registry at ARIN. And we’re looking to have ROA information inside the routing registry that we’re creating.

In order to participate in this new enhanced routing registry at ARIN, we will require a services agreement to participate. And one of the primary reasons we’re doing this is we’re doing validation of the routing registry data against true ARIN registration rights information in the ARIN registry, and we have to know who the registrants are in order to do that validation.

Milestones for this project. The plan for ‑‑ we have already released new routing and DNS points of contact that are associated with this project. You can actually identify point of contacts inside ARIN Online now for routing and DNS. Those also satisfy two ACSPs that we had, 2018.15 and 2019.3.

And inside the first half of next year, with a major deployment that we’ll be doing, we had planned a skinny deployment at the very beginning of this. And our stakeholders came to us and said, you can’t do that skinny deployment; it’s not going to be useful enough to us. And they’ve asked for more robust first deployment, so we’re going to accommodate that.

In that first deployment, users are going to be able to create objects. They’re going to have FTP access to the new routing registry so that they can find the information that’s been uploaded there. And you will already have the RPKI integration that we’re talking about inside that first deployment.

And by the end of next year, still on target to complete the project, the core portions of this project at the end of next year, you should be able to see query information service and NRTM.

And the query information services, you’ll be able to query it just like you do a Whois today and those types of things, perhaps within a graphic interface for it.

So that’s the routing registry project that we’re working on at ARIN. We’re very excited about that.

RPKI overview. There’s another slide after this one where we’ll talk about the RPA and we’ll talk about access to ARIN’s TAL. This is not that. This is separate. In addition to that, we’ve been working internally on improvements to ARIN’s RPKI product.

So if you’ve been out and you’ve talked to Jan and you’ve talked to Jesse or if done that at previous meetings, you’ll find that they’re asking folks about the user interface for interacting with ARIN’s RPKI. And we’ve been making improvements inside that space.

We’ve also reached out to people who have created ROAs recently, and we’ve engaged them and asked them if they would like to work with us over the telephone or over video to help us improve the product. And many of them have responded, yes, and we’ve leveraged their support and their assistance there.

But even more so, we’re starting a project here in Q3 where we’re already actively working on this right now, and we’re adopting RRDP inside our services. And that’s going to be deployed here in our next deployment.

And we’re also removing ROA signing requests. We’re actually improving the user interface in ROA creation inside ARIN Online. There will be ARIN routing registry integration, like I had talked about before, with RPKI at ARIN, ROA population from the routing table, online ROA signing; no more queues for that.

Right now, when you go in to sign a ROA, a ticket will be created and you have to wait some 10 minutes or so in order for that to turn around, and you might need a manual response from someone. We’re lifting all of that out, and it’s going to be much more automated for you and much simpler for you.

And there’s going to be incremental repository generation. Right now you’re only seeing a couple times a day where we’re pushing out new information, where ROAs are being created. Maybe it’s every four hours or something like that.

But we’re going to be doing that much more often during the day, and you’re going to see much more real‑time pushing of that information once you create it inside our services.

And we’re also improving REST provisioning for ARIN’s RPKI, where you’ll be able to interface with the ARIN’s RPKI services more through our REST services and our REST API services.

So the milestones for this work is RRDP with this deployment, incremental repository generation also with this deployment. You’re seeing those improvements go in immediately, as well as some of the user interface enhancements that have already been pushed out and will continue to be pushed out inside the ARIN Online application for this.

In Q1, you’ll see the lifting of the caps on manifest and the CRL sizes. There’s an ACSP related to this. There’s been a lot more use of ARIN’s routing register over the last year than in the many previous years before that. It just dwarfs it, what’s happened in the last year.

And with that we’ve been talking to a lot of our customers who are in there creating those ROAs and using RPKI. And they’ve been giving us some feedback about how we can improve the services. And also they’re creating ACSPs, suggestions to the organization. So we’re completing some ACSPs here.

We’ll also be completing an ACSP on online ROA signing, improved REST provisioning, the routing registry integration. One of you in the audience, I think, actually submitted a suggestion for that. And that’s why we’re making sure that happens.

And then also in Q2, you’ll see the ROA population from routing table features done. So we should be done with all these improved features by the second quarter of next year for RPKI.

And behind the scenes, we’re actually doing an upgrade of our internal infrastructure for RPKI. So our hardware security modules have reached the age where they need to be replaced, and we’re actually doing the work to replace those right now. And that should also be finished here shortly inside this project timeline.

So there’s some things going on behind the scenes that you don’t see in the user interface on the front.

So those are updates on both the routing registry and some RPKI improvements we have.

The next slide is going to be about the RPA, but before we get there I’m going to back up and ask if there are any questions specific to the Internet Routing Registry products or the RPKI improvements that we’re making. And then we’re going to talk about the RPA after that.

Paul Wilson: Paul Wilson from APNIC. I just thought I’d mention that at our last meeting we had a Policy Proposal approved that APNIC would be implementing the AS0 ROA for unused, which is to cover unused address space in our ranges under an RFC whose number I forget.

But I’m not sure if that’s something that’s come up in the ARIN region, but it’s something that we’re doing, we’re implementing during the course of the next few months.

Richard Jimmerson: That’s not something that’s come up in our region, and it’s not something that our stakeholders have discussed with us either. But we’ll take a look at what discussion is going on inside the APNIC region in relation to that.

Front microphone.

Nathalie Trenaman: Quick addition to that. Nathalie Trenaman, RIPE NCC. We got a Policy Proposal in last week exactly about the same to basically put AS0 on unallocated space.

Richard Jimmerson: Excellent. Thank you. So that’s been introduced in the APNIC region and now the RIPE region through a Policy Proposal. I would expect the same thing may happen here.

Back microphone.

Ruediger Volk: Just a comment on the ASO or ROAs. That’s actually a good idea if we have a really secure view of the distribution of the stuff harking back to the common dataset. Finish on that.

My nasty question on the IRR thing is: Will there be any constraints or limitations on the excess and the use of the data that will be stored and provided there?

Richard Jimmerson: So our current plan is for anyone who is putting data into the ARIN Routing Registry, because we’re doing validation against that, those route objects, against the registry database, we do have to have an agreement with them in order for them to put it in, basically like the 20‑plus thousand ARIN customers that already have that.

But for actually viewing the data, there are no current plans to restrict access to that. So when there’s a user interface where people can query it, and via NRTM and via FTP, we currently have no plans to limit the access to that. There’s no RPA plan currently for that or anything along those lines. It would just be openly queryable, much like the Routing Registry that we have today.

Side microphone.

Kevin Blumberg: Kevin Blumberg. In regards to the AS0, it is imminent. I’ve been talking with the author. The complexity of our region is how much is actually NRPM policy, which goes through one thing, versus how much of it is an ACSP request.

So that’s just the complexity for our region. Otherwise it would have been, I think, already sent in to this region.

In regards to the IRR, all of the records will be tagged, authenticated in the IRRNG ‑‑ I guess the next generation, the one you’re working on now ‑‑ will there be anything in the new IRR that is not authenticated, ARIN‑stamped, basically, records?

Richard Jimmerson: The intent is everything in the new Routing Registry be validated against the registry data. So we won’t allow a route objects, AS‑set objects inside the new ARIN Routing Registry that do not correlate to the true registration data that we have. That’s the current plan.

Kevin Blumberg: My last question to that is ‑‑

Richard Jimmerson: Hold on.

John Sweeting: (Off microphone.)

Richard Jimmerson: Can you get to the microphone and just ‑‑ thanks. Just want to make sure that they hear directly from the product owner on this item.

John Sweeting: I was just saying that it’s not only ‑‑ John Sweeting, ARIN staff ‑‑ that it’s not just validated against the resources, but it’s also it’s only ‑‑ there’s only particular individuals that will be authorized to place those, create those objects in the IRR.

Richard Jimmerson: Gotcha, just like with any other interaction you would have with ARIN services, it can only be enacted by people who have the authority associated with the organization.

Kevin Blumberg: So for a second here I’m going to put on a second hat, which is Kevin Blumberg, Toronto Internet Exchange.

Authenticated IRR data is a critical component for us to be able to maintain route hygiene on our route servers. And this is becoming a more and more important issue, significantly more important issue within the Internet exchange point realm.

My question is how many of the other ‑‑ because I do know some of them are ‑‑ how many of the other RIRs are allowing just authenticated data? And is this something that all of the regions should endeavor to have consistently if possible?

Because RPKI is great, but it is going to have a very long upswing. And the more valid data, the more authenticated data that we can get our hands on, the more decisions we can make from a security point of view at the exchange points, as an example.

Richard Jimmerson: I’m not currently aware myself of the plans at the other regional registries in relation to that. If they have information, I’d invite them to come to the microphone. But I wouldn’t want to speak on their behalf in regard to that.

But we can check with them, absolutely, following the meeting.

Nathalie Trenaman: Nathalie Trenaman, RIPE NCC. We currently have a Policy Proposal to improve IRR data by checking against RPKI object. And that’s only for the subset currently of the out‑of‑region RIPE database IRR objects because we did have kind of a clean up on that with the NWI5 project last year.

So we have that pool of data. And the Policy Proposal is to correlate that against RPKI data. I think that’s a start in the direction.

Richard Jimmerson: Thank you. Back microphone.

Doug Montgomery: Doug Montgomery, NIST. Can you say more about the integration between the IRR and RPKI? If I create an ROA in RPKI, will you automatically create a corresponding route object?

Richard Jimmerson: Mark will help answer that question for us.

Mark Kosters: The answer to that is yes.

Doug Montgomery: Will that ROA object be flagged in any way that I can tell it was created from a ROA?

Mark Kosters: That’s some part of the implementation details that we need to work through. But that’s something that’s worthy of considering.

Richard Jimmerson: Front microphone.

John Curran: We’ll be closing the mics shortly for the technical RPKI. We do have a discussion about the Relying Party Agreement next.

Jonathan Stewart: Hi, Jonathan Stewart, Manitoba Internet Exchange. I could use AS0 on our peering prefixes and, in fact, might do that later today.

My question, though, the old IRR ‑‑ the current, existing IRR ‑‑ is going to continue to exist, and then the new one will exist beside it both at the same time?

Richard Jimmerson: So that’s something we’re actually considering for discussion with the community through consultation next year. So as we’re rolling through and completing the new Routing Registry, we would like to have a consultation with the community to discuss potential retirement of the old Routing Registry or if that’s necessary or not. John.

John Sweeting: John Sweeting, ARIN staff, product owner of the IRR. We’re actually ‑‑ right now plans are we’re going to follow the way that RIPE did theirs. We will ‑‑ actually, the current ARIN IRR will be renamed ARIN‑NONAUTH and new ARIN.

Ruediger Volk: Don’t rename.

John Sweeting: We’re going to rename, Ruediger. Unless you want to become a stakeholder and argue with the rest of our stakeholders.

Ruediger Volk: Changing the semantics of names that are globally used is just a stupid idea. It is creating harm.

John Curran: So that perception, Ruediger, is a wonderful perception, but when you have data that is significantly obsolete and out of date ‑‑

Ruediger Volk: Everybody knows that ARIN data in the IRR is shit. So create a new brand of quality data and give it a name, a new one, so that it’s not tainted by the bad history.

Steve Ryan: The gentleman is out of order.

John Curran: Ruediger, your suggestion has been heard, and we’re not taking that approach. Thank you.

Richard Jimmerson: All right. Front microphone.

Alison Wood: I’m the remote, and this is from Andrew Gallo from GWU. He would like to know what will happen to objects in the existing IRR if there’s no agreement in place.

Richard Jimmerson: In the existing, old Routing Registry, after consultation with the community next year, if the community elects that we leave that up, it would be a separate Routing Registry that people could query where that data would stay. Or the community may elect to have us go ahead and delete or eliminate that old Routing Registry altogether. But we’re going to have to determine that through consultation.

John Curran: So there’s an IRR roadmap that’s published. And so far we haven’t deviated from that large framework, which says the old IRR will be locked and frozen, though.

So if the community opts to keep it running, it will be a static set of IRR data. I’m not sure of the functionality of a static set of IRR data, but it is possible the community will like us to keep that running and it will be unchanged.

More than likely, we’ll see what the community says. At some point the inability to change that data means it’s probably a good idea not to have people referencing it after some period of transition.

Richard Jimmerson: One last question at the back microphone.

Ruediger Volk: I wanted to comment, a few things on the authorization state of IRR data. As I understand RPSL, you have some classes of objects that actually cannot be authorized AS‑sets and if you go for root sets actually are things where authorization technically is not possible.

Just keep that in mind because it actually has consequences.

Then I would like to make a remark on and actually fix a little bit what Nathalie was reporting. The RIPE NCC IRR has been using RPSS as an authorization scheme all from the beginning. That’s essentially still in place.

My understanding is some of the other IRRs that have drawn on RIPE NCC database code to some extent, at least, have been doing this. ARIN did not ‑‑ did decide, when it started its RPSL database, not to do the same.

Unfortunately, in RIPE, some loopholes have been opened administratively, and the stuff that Nathalie was talking about is essentially getting control over that again. But kind of the state of the RPSL technology has allowed to do authorization since the last century.

Richard Jimmerson: One final comment, John. Remote participant, and that will be it for comments on this. We’re moving forward to RPA.

Alison Wood: This is from Anthony Delacruz: Could we, as a major ISP that also run our own IRR, provide to you a request to flush out whole ranges that have info we are 99 percent sure is bad data? Dealing with folks like RADb Merit, they make us jump through ‑‑ oh, I just said a name; sorry, Steve ‑‑ dealing with folks, they make us jump through hoops to get the person that put us in the entry to remove.

Richard Jimmerson: That’s something we’ll take a look at, and we’ll go back and read that comment from the transcript so that we can get more information on it.

John Curran: Yeah, we may have to reach out directly. There’s a problem with IRR data in general in that it’s easy to make; it’s hard to get rid of; it’s hard to update. And we have some product circumstances where we can’t necessarily do something on someone’s behalf because the parties that were involved are no longer around.

We need to have the exact ‑‑ they need to reach out to the help desk and make the request. We’ll see what we can do.

John, go ahead.

John Sweeting: Just a quick – any information that gets moved into the new IRR will absolutely be validated, though. There will be no mass import of the data that’s currently there.

John Curran: Right. It’s the old database that’s very hard to get old cruft out of.

John Sweeting: And to Anthony’s question, he should contact Jon Worley and talk to him about what we can do in regard to this specifically.

Richard Jimmerson: Thank you, everyone.

Now we’re going to talk about the RPA.

John Curran: So we made an announcement last week and pushed out a new version of ARIN’s Relying Party Agreement. ARIN’s Relying Party Agreement is the document that you agree to to use ARIN’s CA repository, RPKI Certificate Authority. And that new RPA has been updated to reflect a few of the comments we’ve received over the last year.

One of the things we received is people were saying: I want to take the data in your RPKI Certificate Authority and I want to use it for informational educational statistical purposes, and I see I can do that, but I can’t do it in machine‑readable form.

As someone noted, nearly everything today is in machine‑readable form if it’s online, it’s just a question of how readable.

We made clear we’re not trying to get in the way of someone producing statistics or electronic summaries, but it’s not to be used for machine‑readable form for redistribution for routing. Because clearly, if you’re doing that, then you’ve put yourself in the path between the data and the people routing. We’d like them to come to the repository directly and have an agreement with us. Everyone who is using it should be a relying party.

So if you have a system that’s doing statistics reporting, if you’re writing a research, if you need to redistribute in machine‑readable form for educational research purposes, feel free to do so. If you actually want to redistribute for purposes of enabling someone else to do routing off your redistribution engine, we’ll talk about that in a minute.

Okay. So first thing is we’ve added the ability to redistribute a machine‑readable form for education research and statistics purposes.

The second thing we did is we added the provision that we’re not asking in the RPA for you to indemnify us for a circumstance of our gross negligence or malfeasance on our part.

A lot of people who have legal background understand that if that’s really what was going on, the indemnification wasn’t much anyway, but we’ve made it specific. And so, no, we’re not asking you to indemnify us if we intend you harm.

And so that was another comment that came out from the community, a sort of moral hazard issue of indemnifying ARIN if we intend to do harm or don’t intend to pay the necessary level of diligence to providing the service. That’s also been addressed.

And then the other thing we did was we created a whole new RPA ‑‑ well, not a whole new RPA. We created a version of the Relying Party Agreement.

Turns out there’s some communities that already have agreements among their members. They’re a research association of networks, for example, or they’re some other affinity organization, or they’re a service provider who have customers who they already have an agreement with their customers and they want to redistribute ARIN’s RPA data.

We’re fine with that. Ask us. We have an agreement called a Redistributed RPA. If you’re a content company, CDN, if you’re an educational research network and you have members and you want to provide the RPA data, that’s great, we’re happy to sit down, as long as you’re capable of providing the means to redistribute and meaningfully agree to the agreement, you have the financial/technical means to do that, then you could execute a Redistributed Agreement and you can provide it to your community.

I’ve had a lot of people say, we don’t understand why there’s an RPA. We don’t understand the liability. Maybe there isn’t. You distribute it. That’s great. That works. We’re happy. We don’t need to be the party. So that’s one way to address this concern.

We do see liability, which is why we do have a Relying Party Agreement. So the new RPA is available. It’s in effect. The Redistributed RPA is also available.

I’ll take questions. Back mic, middle.

Ruediger Volk: Simple question: Is there a version that actually marks up the changes? Because this is a lot of legalese, and figuring out and doing three pages of legalese diff manually may be a nice job for a lawyer.

What I have figured out does not improve the things for me substantially, but I may be missing something. And the final judgment anyway will take considerable time until I hear back from my legal department.

John Curran: Two sentences and a paragraph. If you can’t find them and put the time into finding them, you probably shouldn’t be using RPKI to alter your routing; it would be kind of dangerous if you’re not willing to put in to find two sentences in a paragraph.

Thank you, Ruediger.

First microphone.

From the Floor: Is the Redistribution Agreement online, or how do we find it.

John Curran: We have it. It’s available by request.

Back center microphone.

Doug Montgomery: I’m pleased that the IRR will not have an RPA but a little mystified as to why it won’t, given that it’s directly linked to RPKI. And I think with a little hacking I could implement IRR to router protocol. Just interested in how are these things different?

John Curran: Do you want us to do a review of the legal risk of IRR to see if we need a specific agreement to distribute it? I just want you on the record if you’re asking for that, because we have not pulled in the lawyers on that or reverse DNS service or a few other things but can engage them.

Doug Montgomery: I guess it’s best left for an informal conversation.

John Curran: Thank you.

Far microphone.

Martin Levy: Martin Levy, Cloudflare. For the record, for those that don’t know, Cloudflare pushed for a modification of the RPA, and John and his legal staff have worked with our legal staff. We have this, and John knows that I’m still not happy. Other people are not happy.

But I’m going to take this new RPA as a data point and a release and now work forward from it because this is, whether you like it or not, an effort and does solve a couple of problems. Doesn’t quite solve all my problems. And I know other people, if I speak for other people, it doesn’t solve their problems.

So my point of coming to the microphone is to say this: ARIN, please continue both internally and via members or members’ lawyers or members, whomever, to take the path towards whatever comes after RPA version 2. It is easy for me to say here burn down the house, throw it away. But I know it’s not that simple.

And you and I have talked about this, and anybody else who has talked with their lawyers will realize that this is a pain in the…somewhere.

So my simple statement to you is: Please don’t consider this a stopping point. Continue this. I hope other members come and say that they need something better than this or the rest of the community does.

But I also think that you should explain some of the problems of running a registry like this inside the United States in a more broader fashion, maybe the other RIR meetings, because I unfortunately don’t have an answer to fixing this at the moment, and you know that.

John Curran: Understood. Thank you.

Any other comments on the RPA? Closing the queues. Thank you very much.

We do continue to look at this. The Board’s interested. It came up in the Board Candidate Forum. I’m sure it will come up again and again, and we do look at options for how to improve. We’re not silent in that regard.

At the same time, we’ve made some significant progress to date. And for people who want to actually do this in a different manner with an RPA or with their own terms and conditions, your organization can decide to redistribute this if you have a community you want to do.

As I said, maybe your lawyers will assess the liability different than our organization. So it’s available. Let us know. Thank you very much.

Public Policy Meeting, Day 2 - Open Microphone

John Curran: We’re now going to move on to Open Microphone. Look at that. Okay. We’re coming to the end of our Public Policy ‑‑

Paul Andersen: Microphones are open.

John Curran: Oh. Welcome. Our Chair returns. Would you like to moderate the Open Mic?

Paul Andersen: Sure. Well, I actually came back, John, because I have had so many complaints by email about your jokes over the last two days. So I thought I had to come back and rein him in.

(Applause.)

I didn’t think it was going to be that funny of a joke, but okay.

Paul Andersen: Microphones are open. This is the portion of Open Microphone that should relate to anything that has come up in the discussions that, if you’re me, you’ve been watching remotely or in the room over the last day and a half.

We will have our Members Meeting after where there will be a series of presentations and another Open Microphone which you can come. So whether you ‑‑ if you have an idea for a policy, a question about something that just didn’t get addressed. A better joke.

Far microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. You’re not going to get a better joke out of me. We have global policy, we talked about that yesterday. We’ve been talking about transfers quite a bit.

One thing that is very important for the community who is looking at drafting policy is to look at how the community is able to get additional IPv6 blocks from the IANA and how changes to our policy specifically related to transfers out of our region into other regions may affect our ability to either get additional space or may create issues where the other regions’ numbers suddenly get out of whack and they have issues with getting space.

There is clarity and clarification that is required in regards to how IPv6 space is requested. Transfers were not really taken into account in those calculations. And so before we jump on transfers globally around all the different places, as a community we need to take a very hard look at how we can get additional space or if it’s going to create a roadblock or an impediment to additional space, because that kind of adoption snafu would really, really impact the community far more. Thank you.

Paul Andersen: Thank you for the comment. The AC and community can take that.

Other questions or comments? That’s it? Just one? You guys are being easy. The microphones will be closing both virtually and remotely in the next 30 seconds if you do not start moving towards a mic or typing furiously.

Seeing none in the room and none on remote ‑‑ none on remote, thank you, Alison ‑‑ we will close the microphones in my brief stint at the PPM, but a decade of still involvement continues.

Public Policy Meeting, Day 2 - Closing Announcements and Adjournment

John Curran: Very good. I almost went to the Open Mic with a joke, but I didn’t.

So at this point we’re now in the close of our Public Policy Meeting. I’d like to thank everyone for coming. Please return at noon.

Now, that’s a brief time away. We’ve got about a half hour here, no, about 20 minutes, before our Member Meeting. We do all of our departmental reports and similar, get to hear from the Board of Trustees and the Advisory Council Report.

So out there are boxed lunches. So go forth, get your lunch if you want one. If we’re not seeing you because you’re not staying for the Member Meeting, I look forward to seeing you at a future ARIN meeting either online or in person.

If you’re staying for the Member Meeting, which is open to everyone, members, non‑members, feel free, come on back in at noon, and we’ll start the Member Meeting. Thank you very much.

(Break from 11:42 AM to 12:04 PM.)

Network Sponsor

Webcast Sponsor