ARIN 36 Public Policy Meeting, Day 2 Transcript - Friday, 9 October 2015

This transcript of the meeting 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.

Table of Contents

Opening Announcements

John Curran: Good morning. Welcome, everyone. I'd like to welcome everyone to our second day of ARIN 36 in Montréal. I'm John Curran, President and CEO. I'd like to start off the morning with a couple of brief remarks, and then we'll move back into the policy block, where we have a number of policies to consider. 

So, first, thanks to our sponsors. Telus and Videotron. 

(Applause.)

John Curran: Our webcast sponsor, Google. 

(Applause.)

John Curran: And our break sponsors CIK Telecom, Belair, ColbaNet, and ServerHub. 

(Applause.)

John Curran: Okay. Voting is opened. If you have not voted, please vote. Everyone votes once. Well, unless you're from multiple organizations, then you vote multiple times. But please vote. Get in there and vote. 

There's the link. You can also go to the election help desk. Happy to help you out. Want to get everyone in there. Need to have your votes. 

Social media, again, create an original tweet. Use those tags and you'll be entered to win a gift certificate. 

Rules and reminders. The chair moderates the discussion of the draft policies so that everyone can speak and be heard. State your name and affiliation each time you're at the mic. Please be courteous, comply with the courtesies in your program. 

Today's agenda. We have the NRO Number Council report with Louie Lee. We have ARIN Services Working Group. Actually, I did that already so we'll skip that. We'll have the reports from the various departments - Registration Services and Engineering, an AC report, a Financial report, a Board of Trustees report and an Open Mic.

In terms of policies, we have three policies. We have Draft Policy 2015-5: Out of Region Use; 2015-6: Transfers and Multi-national Networks; and 2015-9: Eliminating Needs-based Evaluation for Section 8.2, 8.3, and 8.4 Transfers.

At the head table I have our Chair and Vice Chair. I have the Chair and Vice Chair of the Advisory Council. And I have our jabber monitor.

NRO Number Council Report

John Curran: So let's start right in. I'm going to ask Louie Lee to come up and give the NRO Number Council report. 

Louie Lee: Thanks, John. Good morning, everyone. Good morning, everyone. 

Audience: Good morning.

Louie Lee: Ah, there we are. Okay. So the ICANN ASO Address Council. Who are we – well, first, I'm Louie Lee. This is Louie's hat.

Owen DeLong: Vote for Louie's hat. 

Louie Lee: We are the NRO Number Council and we're the Number Resource policy advisory body. The Number Council does the work of the Address Council. The Address Council is a function and the Number Council is the people that does that function. We're 15 members, with three from each region, two of whom are elected by at‑large and one is appointed by the RIR Board. 

In ARIN, we have two years for staggered elected members. One year for – is that box clear? We just have three‑year terms and we rotate them, who starts their term each year, and just stagger that. 

I think that's a slightly clearer way to say that. What do we do? We advise the ICANN Board on policy issues, RIR formation. We select ICANN board members, and we also select an ICANN Nom Com member. And we have telephonic meetings monthly and we do meet together physically once a year.

These are the 15 members today. I've highlighted Mark Elkins. He was appointed by the AfriNIC Board in April to fill the position that Alan Baird vacated when Alan was appointed to the AfriNIC CEO position that Adiel vacated when he moved on to ICANN. 

And in August, the AfriNIC Board reappointed Mark to serve the one‑year term next year. Aftab Siddiqui was reappointed last month to serve the one‑year term next year. And last month also Tomohiro Fujisaki was re‑elected for the two‑year term that covers 2016 and 2017. 

And here in the ARIN region the ARIN Board appointed John Sweeting in July to serve through the end of the year when Ron da Silva resigned in order to serve the community in another position. More on that later. 

Last month the ARIN Board reappointed John for the remaining two years of Ron's original appointment – which the term runs through 2017. And the last change, I made Ricardo my other vice chair. 

So what do we do with global policy and global policy management? A global policy is a policy that determines the number of allocation policy for requests that involve an outside group like the IANA and so far only like the IANA. 

How does this happen? Well, we have already PDPs in each of the five regions. So each region, following its own PDP (Policy Development Process) in an open, transparent, bottom‑up manner, would have a policy working through it, and they're submitted in all five regions. And when each region follows its own process and gets passed, then it goes up to the NRO for review, which the function would be the ASO, and after our review, just to make sure that it's actually followed the process and that all significant viewpoints have been considered, then we pass it to the ICANN Board.

We don't judge it on its merits because it's already been done by each of the five communities around the world. 

So the ICANN Board will look at it, make sure that it doesn't cause major harm to the system, and ratifies it or sends it back for us to consider other things that we might not have considered. 

The Policy Proposal Facilitator Team is formed each year just to make sure that we can keep track of the policies that might be coming through, keep an eye on things, and it consists of one member from each team. 

And from ARIN it's Jason Schiller this year. Of course, as you know, there are no global policy proposals currently working through. 

When we meet, we meet monthly on the first Wednesday of each month. I get excited. My hands are waving, and my Italian comes out.

(Laughter.)

Louie Lee: We did have an emergency meeting on June 10th. It was out of schedule, just to make sure we addressed certain issues that would pop up that we can't really wait until the July 1st meeting. 

We also held a face‑to‑face meeting on June 23rd in Buenos Aires at the ICANN meeting. Oh, this happened. Right. Ron da Silva, he was appointed to Seat 9 of the ICANN Board. He will be starting in just a couple of weeks, but I understand that they've already got him getting oriented, drinking the Kool‑Aid and so on. 

(Applause.)

Louie Lee: It's tasty Kool‑Aid, right? He's busy drinking back there. All right. We've already started the selection process for the other seat, Seat 10. Seat 10 is currently occupied by Kuo‑Wei Wu. And we have just started the nomination phase at the end of last month, which is just about a week ago, and running through middle of December. 

So if you know somebody that would be good for the ICANN Board position, ask them first before you surprise them by nominating them, please. 

At the bottom is the link to the announcement and how to actually go through the process. 

Okay. So in June, at the ICANN 53 Buenos Aires meeting, the group did a number of things, talked to a number of people. We held our own face‑to‑face meeting, and, I don't know, maybe you can't really read through all the agenda items for our meeting, but most notably the 2015 leadership training program, Sandra came by and described what the program is and solicited help to staff that. 

So we appointed Fiona Asonga to help with that effort. A public working group was nearly formed. It's a working group within the Government Advisory Council, otherwise known as the GAC. And Bobby Flaim, whom you know from his activities here, he presented the group – showed us that the group is there from law enforcement around the world to help advise the government on things to do, research about what's happening, what things that the GAC might need to be paying attention to as far as crime and law enforcement. 

So actually this week I've been talking about a letter that he's helping the GAC write up for the RIRs. So be looking for that. 

All right. We had a meeting with the ICANN Board, gave them a piece of our mind. And they let us know that they're there to help us. And we held an ASO workshop where there was a CRISP update.

I did a little session about the number policies. But not a discussion. It's a snapshot, summaries, give them a list of topics that we're considering, with highlights, links to the full listings, and how they can participate, which is to come to each of the RIR meetings.

And this is a list that was for global – sorry, for all the RIRs, not just ARIN. So if you want to get at that presentation, just hop on to the ICANN website, ICANN.org, and check out the meetings listing. 

All right. And we also had a chat. I had a chat with the fellowship. The fellows had daily meetings, described what the ASO does, what the number community does, and I expect to have to repeat that each time for them. But it seems to be well received. 

Recent appointments, Ricardo for Vice Chair which I've already described. Hartmut Glaser is appointed the 2016 ICANN Nom Com. For the Stewardship Transition Coordination Group, Hartmut was appointed there. And I did mention that Fiona Asonga was appointed to the Leadership Training Program. What's missing on this slide is Ron da Silva for Seat 9 of the ICANN Board. 

Any questions? 

Vint Cerf: It's Vint Cerf, Google. You mentioned the public safety working group at the GAC. And although you mentioned only crime and law enforcement, does that group also have an interest in emergency services? Because there's some evidence now that using Internet‑based systems, we might be able to provide much better information to an emergency services provider – the fire department, police department or emergency medical services – than a classic phone call.

So I didn't know what the scope is of the GAC working group.

Louie Lee: I don't remember mentioning that, but that doesn't mean that they don't have a focus on that also. But we can – I can ask Bobby specifically about that.

Vint Cerf: I would appreciate that. 

Louie Lee: I'll see him next week. 

David Huberman: Good morning, Mr. Lee, Mr. Hat. 

Louie Lee: Good morning, David. Who are you, David? 

David Huberman: David Huberman, speaking on behalf of myself. ICANN Board, Seat 10. In your long experience with this, are you guys looking for nominees who well represent the numbers community directly – you know, a Ray Plzak, a Ron da Silva – or are you also open to considering – I'm just going to throw out a name not because I'm nominating that person – a Vijay Gil who isn't in this community but is an operator who we all know and work with? Are you interested in operator representatives who are interested and engaged in ICANN or just RIR people? 

Louie Lee: So we grapple with this also within our group. So that's a very excellent question. As much as we appoint people on to the ICANN Board that would be excellent board members, we find that the other members that are put on by the other part of the community have a strong representation to that community. I don't want to fault them, but it feels that way. 

So as much as that happens and we try to put on very good Board people, if everything else is equal, we're going to tend towards somebody that has more an interest and knowledge in the number community.

David Huberman: Thanks, Louie.

Louie Lee: Thanks. Anyone else? 

Thank you very much. 

John Curran: Thank you, Louie. 

(Applause.)

John Curran: Very good. Okay, we're going to move into our policy block and discuss the policies we have remaining on the agenda. The first would be Out of Region Use, ARIN 2015‑5, and I'll invite Tina Morris up to come up and give the AC presentation. 

Draft Policy ARIN-2015-5: Out of region use

Tina Morris: Good morning. As you know, we've been working in out‑of‑region use in the ARIN community for quite a while now. The last couple of policies have met with strong legal objections. 

So we took and abandoned the last policy and responded to the community support for the concept. We did a complete rewrite of the out‑of‑region policy, which resulted in what we have today. 

Basically this policy will allow v4, v6 and ASN use out of region. You can use it – you can justify further grants for use out of region and you can also use currently deployed space that's out of region as – to justify new space. So to increase utilization. 

Current policy's out‑of‑region use space would count as 0 percent utilized. This would count it as actually deployed space on your network. 

There's a lot of companies that operate internationally that would appreciate this policy, so we've been told. So we wanted to review it today and see what you think.

The policy statement is very long. I will leave you to go through it in your guides. 

Essentially it gives ARIN staff the ability to look at several factors and decide if an organization has an actual business presence in the ARIN region, and, if they do, they would qualify for out‑of‑region space, if they're anchored by – let me go back to that, the specifics – at least a 22 of v4, a 44 of v6 or at least one ASN in the region. And then there's several factors to demonstrate a physical presence – a staff in the ARIN region, all these factors that the ARIN staff can consider. 

We took this in for two staff and legal reviews so far. The first one came back. Staff had concerns that they had some conflicting instructions. So we went back and rewrote the policy to hopefully solve those problems.

The second one came back, both staff and legal see no major issues. It will increase staff workload a bit, and legal sees no material legal risks for this policy at this time. Which, if you remember, is a huge leap forward from the last out‑of‑region policy we had. 

Impact. There will be a little – a bit more demand on staff to get things done. There's also the possibility that we could require unicode character sets, which engineering efforts would be required to handle. 

On PPML, we had a lot of discussion in regards to this policy. But most of it really drifted off topic. We had only really two votes in support and two against. There were six people or so that went back and forth with negative comments, but they were somewhat off topic, whether this should be a global policy, things like that, just use v6 already, you know, the standards. 

So those weren't very helpful for the AC to determine if this should continue to go forward or if it should go away finally. 

So today I'd like to ask you: Is there anything in this policy that would prevent you from supporting it? Does it solve a real problem for you? And should it move forward? 

Vint Cerf: And that's the end? Microphones are now open for comments on this proposed policy. Please say whether you support it or you don't support it, maybe a little bit why, if you have the time to do that, and remember to say who you are. I'll take the center microphone, No. 2, first. 

Matthew Kaufman: Matthew Kaufman, Microsoft and myself. I strongly support this policy for the same reason that I objected to my own policy yesterday. 

I don't believe that ARIN should be penalizing people who are legitimately using their address space in ways that they see fit by imposing restrictions on issuing new address space, in effect restricting how they use their current space. 

There's nothing that would prevent me from supporting this, obviously, as I am supporting it. 

Yes, I believe it solves a real problem for users. There's any number of scenarios I have thought of, several of which I've encountered in my own operational work at Microsoft. 

There's nothing about the Internet that means that you shouldn't be able to take a virtual machine cluster, for instance, shut it down on one continent and bring it back up on another continent for a few hours and then perhaps shut it down and bring it back and light it back up on this continent. 

There's no reason why when it's operating off of this continent we should be penalized in utilization. 

Obviously we're still using those addresses to exactly the same extent we were before, just in a different place. 

I also believe that it's quite possible that there would be situations where you wouldn't be able to get any address space, if you were fully restrictive on this policy. There are places that you have to get address space from somewhere else in order to operate on the Internet at all. 

So, yes, this should move forward in its current state. I understand there's a bunch of – there are a bunch of staff and legal concerns, and I'm happy to see those have been addressed.

Vint Cerf: Thank you very much. Let me take Microphone No. 1 and then No. 2 in the back. 

Dani Roisman: Dani Roisman, SoftLayer. I'm also in support of this policy. I appreciate how well it's written, and it definitely removes a lot of the ambiguity that has been around over the years regarding out‑of‑region use, whether it can qualify as justified, whether it can qualify as needed, et cetera. 

So I think we definitely should move forward with this policy. Thank you. 

Vint Cerf: Thank you very much. Geoff Huston in the back. 

Geoff Huston: Geoff Huston, APNIC. I'm not sure if I should be for or against it because of my role in APNIC, so let me say I'm neither. But I'd like to remind you of a tiny bit of history and consideration. The RIRs were there as a convenience to the industry it served, so that we set up an RIR in Asia, we set one up in Africa, et cetera, as a convenience to the folk in the region, not to put boundaries around addresses, the first point.

The second point, though, is interesting, because this RIR, in particular, ARIN, was, if you go back, the original one. And all the other RIRs carved out space and said everything that's left is ARIN's, in effect. 

And that's still the case today. If I've got no RIR I can go to, in theory ARIN is the one, because ARIN is, if you will, underneath it all, the one that had everything that other folk took bits of territory away from.

So when you consider this, what is the scope of ARIN, I believe you've got to consider Antarctica. I believe you might well have to consider the Indian Ocean territories, I'm not exactly sure. But if you will, you can't find a territory in the other RIRs, I believe it is appropriate and proper to come to this particular registry and say: The precedent says I can come here. And I would like – I applaud the attitude of this community in considering this matter in the way it's doing it. 

It is a responsible thing to do. Thank you. 

Vint Cerf: Thank you very much, Geoff. 

(Applause.)

I have a question for Geoff. If I'm remembering correctly, ARIN officially gets created in 1997. So you may actually be saying it was IANA under Jon Postel that was the ultimate source of these things. 

Do I not remember correctly that RIPE NCC was the first of the non‑IANA RIRs? 

Geoff Huston: Geoff Huston again for APNIC. As I recall, and I'm trying to remember if it was '91 or '90, a number of addresses were handed to a delegation from Europe that included Daniel Karrenberg for use within that – that defined area of at the time Western Europe. 

Consequent to that, and I'm remembering '95, delegations were made by Jon to the nascent APNIC experiment. And then, as you say, in 1997, ARIN was formed with, if you will, the same global remit as had its predecessor. So ARIN was always the last resort thing. It was never carved out as territory as I recall it. 

Vint Cerf: Fair enough. Thank you very much, Geoff. 

Let me take – oh, I beg your pardon, John. 

John Curran: Geoff is correct. Just for a little detail: So when ARIN was formed, it was formed by assuming the duties that were done by the InterNIC with respect to Internet Number Resources. So ARIN's original service area was actually described as ROW, Rest of World. 

And, in fact, there is somewhere hiding – I don't know if anyone still has the original mug or business card, our logo was the word "ARIN" with this green pattern, which I had to stare at quite long before I realized it was all of the continents minus the APNIC and RIPE service region, because ARIN's original service region was that which was not APNIC and RIPE.

Vint Cerf: Thank you very much for that historical clarification. I'll take Microphone No. 2. 

Matt Petach: Matt Petach, Yahoo!. I support this policy. I think it is an incredibly good example of what can happen when we actually kind of go back and blank slate think about what we're trying to accomplish. 

It's a well‑written proposal. I will note in this little exchange with Geoff and John, I find myself scratching my head now thinking, oh, gosh, if we're putting brick‑and‑mortar requirements in for the ARIN region, what are we doing to those poor Antarcticans, and should we be thinking about fixing it for those. But we'll leave it as a matter of policy.

Vint Cerf: Thank you for that. Owen. 

Owen DeLong: Owen DeLong, Akamai, ARIN AC. I don't know how many requests ARIN gets every year from penguins, but I'll leave that for another time. I understand, it was a joke.

I support the policy as written. I think it is long overdue to move something like this forward. It has been mired in an unfortunate level of distraction and consternation over various legal issues that I wish we'd been able to solve faster. There are real organizations being affected by this quite negatively, and let's get it done. 

Vint Cerf: Thank you, Owen. Any other comments? I see one from No. 1. Oh, is there one on line? Oh, it's Kevin. 

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I support the proposal. Didn't for a long time. Really had to get my head around it. Then I realized we've had a lot of discussions over the years in regards to getting rid of the technical cruft that's in the NRPM, the things that are services oriented that really don't have a place in the NRPM. 

And this solves an incredible problem of non‑documented technical requirements, which is this whole concept of pinning your aggregate prefix in region to deal with a policy issue through a technical means. 

Pinning is not realistic for many situations. Doesn't help when you don't have your own backbone, creates a headache, and it is only done because that one pin was allowed to justify the out‑of‑region use. 

The interesting part about that is, of course, that the IPs are still being used 99.99 – depending on the provider that you're with, five 9s outside of the region – and that .001 percent inside. So I absolutely support cleaning this up. 

Vint Cerf: Microphone No. 1. 

Karl Brumund: Karl Brumund, Dyn. I do support this proposal. I also feel it does clean up something that has been outstanding, even though in our particular case we've managed to get around it. But, like Kevin says, I do second his comments about the technical cruft.

Vint Cerf: Thank you. We have one more comment microphone one.

Matthew Pounsett: Matt Pounsett, Rightside. I support this policy as written. I've had to object to the previous ones because they were either far too restrictive or far too lax, and I think this strikes a really good balance.

Vint Cerf: Thank you, and we have a comment at Microphone No. 2.

Chris Tacit: As the author, I still continue to support it. 

Vint Cerf: Thank you. Any other comments? Are there any online?

Chris Tacit: I just wanted to say Chris Tacit speaking for myself.

Vint Cerf: Any online comments? Jabber comments? 

Cathy Aronson: No, we're good.

Vint Cerf: So, it looks to me like you have very positive feedback from this community, which suggests to me that you should proceed.

Tina Morris: I agree. Thank you. I was going to ask for a poll, but I don't think I need one.

Vint Cerf: Unless someone feels strongly, I think that you have very positive feedback at this point and you should move forward.

Dan Alexander: Can we get a simple poll in the room if people are in favor of this.

Vint Cerf: Just a hands‑up poll or just a count? Do you want a formal count or do you just want hands up? Formal count? All right. Vote takers, please prepare yourselves. Wave if you're ready. We're ready. All those who are in favor of proceeding with this proposal, please keep your hands up until the note takers tell us they're done. 

Are you ready now? Hands down. Any objections? Any no votes on this one? I don't see any. So we'll wait for the note takers to do their counting. While they're doing that, I would make the observation that IP addresses are supposed to work everywhere, so this proposal I think helps to support that theory. Drum roll. There's something vaguely quaint about all this, pieces of paper and people raising their hands and here it is the 21st century. Ladies and gentlemen, there's 133 people in the room, four are remote, for a total of 137, 38 people in favor of this proposal and zero against. Thank you and congratulations. Well done. 

(Applause.)

Tina Morris: Thank you.

John Curran: We may have had one more additional poll in favor in the remote that did not get logged because of the delay. 

So we'd like to move on to the next policy. And the next one is ARIN 2015‑6: Transfers and Multi‑National Networks. And Kevin Blumberg will come up and do the presentation. 

Draft Policy ARIN-2015-6: Transfers and Multi-national Networks

Kevin Blumberg: It's good morning, right? Just remembering the time zone. So we have a very similar policy to the previous policy you just heard – completely different, but the same. 

The idea was – and I'm just going to talk about this for a minute and we'll go through it – but the idea was 2015‑5 had gone through a number of iterations and a number of staff and legal concerns over the time. 

And there were a number of people that felt that having a backup plan to the bigger sort of 2015‑5 would be a good idea. So a couple of people looked at the issue and said, well, if the community – keep in mind this is during free pool, free pool's there – during the free pool, before free pool runout, if there's concern about having this applied to free pool resources or the perception that this might be applied to free pool resources, let's apply this to transfers only. Let's count your out of region for transfers, because that's where it matters, and effectively make the out‑of‑region aspect a no‑op. 

Of course, some of the similar language in dash 5 in regards to pinning to an organization within the ARIN region, making sure that it was for an ARIN region entity, customer, was included, but the basic premise was similar. So let's just go through this quickly.

Problem statement, as I've just described. Nice amounts of text. By all means if you want to go through specifics, I would look in your Discussion Guide. 

The policy statement. So here we go. When evaluating transfer requests, ARIN will not consider the geographic location where an organization is utilizing or will utilize. So stuff in the past, stuff in the future. 

You need to get space for a transfer, for out of region, not a problem. It's both. Utilize or will utilize. 

That was actually clarified because of staff comments. Now, it requires an ARIN‑registered address if the organization, its parent or subsidiary has been an ARIN customer for 36 months, is in good standing with ARIN, is using space, and has a meaningful business. 

So these were the caveats that kept the staff and legal really clean on this. 

In its first iteration, legal did not have an issue with us making sure that this was a bona fide customer, I guess you could say – no, entity in the region. Customer is wrong because that would be – yeah. 

So staff comments. Again, came back pretty clean. I'm including them all here for you to see. It can be implemented as written. It would be a new part of section 8.5. It allows organizations to justify space larger than what they would have been able to do before because they now include their global use. 

Resource impact: Not very big, but they did bring up a new thing. After we fixed up the first staff and legal, we wanted to get a clean, you know, everything's good, staff and legal. 

And they came back, both in 2015‑5 and 2015‑6, and said if we're going to be doing out of region, there could be a major issue. And the major issue is unicode support. By the way, we don't have any unicode support. That's the issue.

So I thought about it. Neither policy requires unicode.  Unicode is a technical service that doesn't have any place in the NRPM. You can submit, I guess, an ACSP request and ask ARIN to spend lots of money putting in unicode support.

But it's not really part of the policy process. It would be a part of the policy process if we said the French language has accents in it that we want to include and do it – do a diversity kind of policy, inclusional policy for language. But that really isn't in the NRPM, and I would say it's probably more attuned to being in the RSA or something like that than within policy itself.

So while I applaud staff for pointing out that unicode support should be used, I really think it's for the community to decide if unicode should be used, period, not part of this policy or dash 5 and, more importantly, we have accent requirements in our region.

We should be – so it's sort of a moot point to me, if we're going to do unicode we do it for inside the ARIN region. Outside is also great at the same time. 

So last thing. We had gotten some feedback on the PPML. It was the only feedback really that we had gotten on the PPML in regards to, in quotes, those bloody multi‑nationals. 

The idea was that multi‑national to most people is a mega corporation. They're large. So I asked staff what their views of this policy would be and who it would help, because to me a multi‑national could be a small mom and pop web‑hosting company that decides to fire up a server in London to service for DR plans.

It doesn't have to be a mega corp. And in fact staff came back and said, again, because of what I was saying earlier in dash 5 with pinning, that the small providers would be far more helped by this policy than the bigger providers.

The bigger providers have their own backbones in many cases. They can pin in the ARIN region. It's less of an issue for them. It makes it obviously cleaner but it's less of an issue.

In the case of a small provider, if you have a 23 from ARIN and you announce a 24 in UK, you're probably not going to announce a 23 on top of a 24 in the ARIN region and a 23 in the ARIN region because you have no backbone of your own.

You have no way for that traffic to get there. You're just going to basically blackhole yourself into your own equipment in a foreign location – back in the ARIN region. 

So it's actually more dangerous to do the pinning when you're a small organization. So staff did come back with that, and I was a little surprised. It was a little different than I thought it would be. 

I was curious more than anything else and I wanted to mention this. So the question is do you support this policy? Does the criteria provide an appropriate balance? Is three years too long? Two years? Anything like that, what do you believe in that? 

Do you believe that unicode support is required in policy? And more importantly, is this policy complementary to dash 5? With the support of dash 5 is this policy needed? Is it duplicative of dash 5? That's really the question I think after hearing the feedback from dash 5 that I would like to focus on if possible as well.

Vint Cerf: Thank you very much, Kevin. Do we have any comments? I see one immediately from Microphone 2. 

Scott Leibrand: Scott Leibrand, ARIN AC. I'm a primary author of this proposal. I would say, yes, indeed, we need to focus on that last question. And I would even put a finer point on it. Does anybody in this room think this is a better policy than the one we just finished discussing? 

I wrote this as a backup to the last one, with the idea that because of the complexity of that and the comments we'd seen on PPML, it might not get support. If it didn't get support, I think this is another way to approach it. 

But since everyone in this room either supported it or did not speak up on the last policy proposal, I would say this one is unnecessary unless we have someone who thinks that it's better than the last one.

If anyone could get up who thinks this is better than 2015‑5, please speak up. Otherwise, as an AC member and the author I will probably be moving that we abandon this one in favor of 2015‑5. 

Vint Cerf: Thank you, Scott. Let me take comments from Microphone No. 1, please. 

Dani Roisman: Dani Roisman, SoftLayer. I agree that 2015‑5 gets the job done. I do have concerns if we attempted to move forward with this, there are statements that are vague, such as Bullet 3 is currently using IPv4 or IPv6 addresses in the ARIN region. 

Is that two addresses? Is that multiple addresses? And that Bullet 4 – can demonstrate it has a meaningful business that operates in the ARIN region – I believe that is too subjective and open to interpretation. 

So I stand with Scott's last comment. I believe that we should definitely abandon this and focus on dash 5. 

Vint Cerf: Thank you very much for that clarity. Let me take microphone null in the back. Center back. 

Kaveh Ranjbar: Kaveh Ranjbar, RIPE NCC. I'm neutral to the policy. I just wanted to mention in our technical community people see the unicode as a policy issue because it might end up that, for example, you end up with addresses in, let's say, Alaska with lots of triangles and circles. And no one else can read them. So the contact information and things like that, if you allow unicode, you need policy, do you allow it or not, and do you have a mandatory English, for example, things like that. 

So at least in our community it was discussed in details, and almost everybody sees that as a policy issue. 

Vint Cerf: Thank you. Take Microphone No. 3 now. 

Brian Bullard: Brian Bullard, Wells Fargo, speaking for myself. I agree that 2015‑5 is better than this. However, if that had not seen a positive response, this would be a great back‑up. 

Vint Cerf: Thank you for that. Let me take Microphone No. 1 next. 

Joe Provo: Joe Provo, Google. I concur that 2015‑5 is superior. There is nothing inherently amiss here, but given the positive response to 5, we shouldn't bother. Oh, and unicode is interesting since we're in Montréal after all.

Dan Alexander: Remote.

Vint Cerf: Yes, please.

Jason Schiller: Jason Schiller, Google, NRO NC. I support 2015‑5. I think 2015‑5 solves all the problems of 2015‑6. The only difference is the strength of the nexus and the amount of resources used, and we can address those concerns in 2015‑5 if needed.

I would not recommend abandoning 2015 – until 2015‑5 moves forward.

Vint Cerf: Good point. Finally microphone null in the center.

John Springer: John Springer, Inland Telephone, speaking for myself. Exactly what Jason said. I think we should table 2015‑6 pursuant to 2015‑5 making it to Recommended Draft Policy and moving all the way through the process.

Vint Cerf: Thank you very much. I don't see any other comments, but I'd like to make one observation about unicode. It has clear utility but it's odd to link it to a particular Number Resource consideration. 

I think it might be wise to come back to ARIN and say that you think the unicode should be available in the ARIN processes, and that's a completely independent implementation thing than a policy with regard to Number Resources.

So, John, perhaps you could take that into account. Are there any other comments? Do you feel a need at this point to take any polls? 

Kevin Blumberg: I think the feedback was perfect. Thank you very much for that. And, Vint, by the way, with the new services working group, I think that's a perfect – that's a good point.

Vint Cerf: Yes? One other observation. The use of the term "table," just to make sure it's understood, this is the American use of the term "table" and not the British use of the term "table." 

"Table" in England means to process the document. You create unbelievable explosions in British and American debate when the Brit says, and I would like to table this, and the American erupts from the seat, saying, goddamn it!  We're supposed to be discussing it. And the poor Brit says, but that's what I said. He said, no, you didn't. Table means to abandon it or stop talking about it.

So we're supposed to not abandon, I think, at this point. So, Scott, maybe you should give some consideration to whether you want to propose to abandon or whether you would be acceptable of – would you accept the idea of simply tabling it for now? 

Scott Leibrand: Scott Leibrand, ARIN AC. I would be perfectly happy sitting on this for another policy cycle and making sure 2015‑5 goes through.

Vint Cerf: Thank you very much, Scott. We have one other comment from the back.

John Springer: John Springer, Inland Telephone. For myself again. My intended meaning was we should sit on it and not dispose of it until we're quite sure that it's not needed.

Vint Cerf: Thanks for your clarification. I think we've finished. Kevin, thank you for your time and thank you all for helping with this. 

(Applause.)

John Curran: We are making great progress this morning. And we'll now go to the last policy to be discussed today. And so the last policy is 2015‑9: Eliminating Needs‑Based Evaluation for Section 8.2, 8.3, and 8.4 Transfers. And I will have – I know how I'm not going to pronounce that. It's not Leif. It'd be Leif? Leif Sawyer. Are you Leif?

Vint Cerf: No, but he's pretending –

John Curran: Okay, so I got the name right, but the wrong person. Okay. 

Vint Cerf: Here's Scott.

Scott Leibrand: Unfortunately Leif got here and got a room that gave him an asthma attack and has not had his voice for the entire duration of this conference. So he can speak briefly but not for an entire presentation so he asked me to do it.

John Curran: You have no problem for an entire presentation. 

Scott Leibrand: I can speak very fast or try really hard to slow down and let you all understand me. 

Paul Andersen: We have 40 minutes.

Scott Leibrand: Please, I can't speak that slowly. I'll need help from the rest of you to fill up that time.

Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

Scott Leibrand: Eliminating needs‑based evaluation for Section 8.2, 8.3, and 8.4 transfers. This is the big elephant in the room as it comes to what we want to do with transfer policy, and it attacks it head on. Nobody's ignoring the elephant here. 

This is a fairly new Draft Policy. It has not been reviewed by staff and legal. All the text in this document, in this presentation, was put together by Leif and myself primarily based on the text provided by the proposal originator, which is in your Discussion Guide.

So the simplified version of the problem statement, full version in your Discussion Guide, is that because of the needs basis requirement in Section 8 of the NRPM, there are a number of cases in which ARIN staff does not update the database to reflect who is actually using or has control of netblocks. So, for example, when ARIN doesn't think that the organization who has acquired the rights to use an address block has a current need for those addresses, or when that organization doesn't come to ARIN at all because they feel it would be easier for them to secure those rights outside of any registration and just don't approach ARIN. 

In both of those cases, the Whois registry, the ARIN registry reflected in Whois, does not reflect who actually has the blocks. So you end up with instances where an organization has acquired rights to use a block. But as far as you can tell from the public data, that block is still unused and available for other organizations to acquire, and everyone has a misleading view of how much IPv4 space is really out there and available.

In addition, we discussed this yesterday, NRPM Section 8.1 has a perceived threat of reclamation by using the word "return," and that serves as a hindrance to some resource holders approaching ARIN with their database updates for transfer resources.

So as a result of all of these things, the ARIN registry is becoming more inaccurate over time at least in the subset of cases. 

It's obvious to everyone in this room, I believe, that we are out of IPv4 addresses in the ARIN region, and four of the five RIRs in the world are also out of their general free pool of addresses. 

The author asserts that because of this, the RIR's primary responsibility for IPv4 is no longer allocation but documentation and ensuring the accuracy of the registry.

We've heard that very clearly from the RIPE region and others. That's an assertion that we should discuss here in the ARIN region as well. 

As he mentions here, RIPE's requirements are that you must be a valid RIR member with authority to transfer, and the parties engaging in the transfer, requesting it, must be who they say they are. That's pretty much it in the RIPE region. So in order to address all of the issues in the problem statement, this proposal seeks to eliminate needs‑based evaluation for IPv4 transfers and allows those transfers to be recorded in the database regardless of whether the addresses are being used yet.

So to do that, it makes a number of changes. One is to strike this third paragraph, which speaks about justified need. I'll let you read that. There's no reason for me to read the slide. The last one is removing the return threat that we talked about earlier. Here's the actual text that was removed. In Section 8.2 there's a bullet point under mergers and acquisitions that says the resources to be transferred will be subject to ARIN policies. This adds an exclusion relating to needs‑based justification or inspection of utilization rate. 

And there's another paragraph to be removed which is the work with the resource holders to return a transfer that we keep talking about. 

This does the exact same thing or shows the exact same thing where we added the excluding needs‑based justification or utilization rate text. 

In 8.3, we have a requirement that must demonstrate the need for a 24‑month supply of IPv4 address resources under current ARIN policies. That is removed to leave just the recipient‑must‑sign‑an‑RSA portion of that.

And in this location we also would add the same exclusion for policies related to needs‑based justification or inspection of utilization rate. 

There's the diff for that with the context. 8.4, again, refers to needs based policies. This is with regard to what the other RIR must have in their policy in order for ARIN to be able to engage in inter-RIR transfers. It removes the needs based portion of that.

Similarly, it adds the same exclusion that we've talked about twice previously to the second bullet. Removes entirely the third bullet, because that speaks just about needs. I think you're getting the picture here. 

Again, a diff. Take out the words needs‑based, add the exclusion. 

Lots of discussion, but as we've seen with most of these other proposals, there were 56 messages and only six of them actually spoke to the support or nonsupport for the policy as written. 

Of those, two were in support, four were against. There is obviously a lot of community concern with the idea of eliminating needs‑based criteria altogether, which is exactly what this proposal seeks to do. That's been expressed on PG&L and was expressed yesterday at the microphone with regard to the other policy proposal.

So the questions for this community: Do you support removing needs‑based requirements? If you're generally in support of this effort, do you think there are any refinements or changes that would improve this proposal? If you're generally opposed, are there any adjustments which, if adopted, would allow you to support it? Do you think there's another way that we could address the problem statement and the community concerns with registry accuracy and with the inability to record the transfers that are actually happening in the real world that you think would accomplish that better than the removing of the needs based assessment done in this policy proposal?

So those are the questions for the community. 

Vint Cerf: Let's join up at the microphones. I would like to get a clarification, John, from Scott. This is specifically with regard to IPv4 and not IPv6; is that correct? 

Scott Leibrand: That is correct. Everything in this is regarding IPv4 transfers in Section 8.

Vint Cerf: Thank you very much. John? 

John Curran: I'm not going to speak in favor or opposed to the policy as that's not my role in the Policy Development Process. I'm going to take a moment to take a general exception to some of the language. And I just want to make clear this isn't in favor or opposed to the proposal. But it's terminology people are using. 

For those people today using the meeting network, it's a meeting network which is – NANOG has worked with an ISP to route. But the meeting network IP address block is actually an ARIN address block. 

There's a Letter of Agency that says NANOG should use it for the week because they're the ones arranging for the network connectivity. The LOA doesn't say the IP address block is NANOG's. It says for this week, if NANOG asks an ISP to route it, it should be routed. 

It's actually the address block ARIN uses for conferences and we're happy to share it with NANOG and we share it whenever they need it. 

Now, the reason I make this little example clear is people talk about transfers that are occurring. And I want to be really clear. If someone has an address block in the registry and they come and say I'd like to update it, transfer it to another organization, we'll do that transfer. 

Even if they've signed other paper with other people that say they have the use of the block, ultimately the block transfers when the registry updates. So people are talking about transfers that have occurred and similar things. An options contract is not a transfer. A Letter of Agency is not a transfer. A document that says you have the rights to update the entry doesn't actually give you that unless the entry's updated. 

So, again, it's worth discussing this policy. But terminology that people say about transfers already occurring, I actually don't know what those are until someone looks at the legal documents, because in fact the rights of the address block in the registry remain to the organization listed in the registry until it's updated. 

And I want to make that just very clear so there's no confusion over that. Okay. End. 

Vint Cerf: Thank you very much, John. Let me take the first comment from Microphone No. 2, the front. 

Matthew Kaufman: I deliberately walked slowly so the microphone behind me could go first.

Vint Cerf: In that case I'm prepared to ask for a comment from the rear microphone in the center. 

Ralph Bischof: Ralph Bischof with SAIC. I do support this policy. To let you know, I've been involved with 8.3 and 8.2 transfers this year. And due to some of the previous engagements with IP addresses with the customer that I work for, there's a lot of – I want to say the word properly as perception.

I know the esteemed Mr. Curran had mentioned yesterday that in the NRPM there is space, there is wording that mentions they're not going to take away any space due to low utilization. 

But it's the perception of this wording and of the actual spreadsheet that comes from ARIN that says you must show us how you're going to use this space.

That is the actual perception of the customer. Even though the wording is in the NRPM, these are customers that I work with that wear many hats and do not know the wordsmith of the NRPM as much as just about everybody here does. So I'm definitely for this. I do not have any comments as to how to change it, but I'm for actually removing it. Thank you. 

Vint Cerf: Now I'll take the comment from Microphone No. 2 and then we'll go to No. 1.

Matthew Kaufman: Matthew Kaufman speaking entirely for myself but currently employed by Microsoft. I support this proposal. I suspect that there will be refinements that are necessary in order to bring it forward. I suspect there will be legal concerns and other details. 

I understand that the problem statement is compelling to some. I don't see that that's really the reason to remove needs basis. I think a much better question is the question that John has posed at least twice on the Public Policy List and not had answered, which is: If the numbering policy had been created after we were out of IPv4 addresses, would we have made needs basis a test? Would that be how we decided who was and was not able to do transfers? 

And I strongly suspect that the answer to that is no. The only reason that needs basis is in there is that needs basis is required to prevent people without need from draining down a pool of addresses which are available essentially for free. But now that they're not available, that is not the way that you would actually write that policy, should you need to do it from scratch.

So I think that it's a hold‑over. It's a vestige of a situation that no longer exists and so it doesn't need to be how we evaluate whether or not transfers should take place. 

Now, I know that there are some who have said that by keeping needs basis in there it sort of protects the small guy. It protects people who have a bunch of money, including my current employer, from doing things like buying up lots of address space and transferring it to themselves without need.

But the fact is that those cows have already left the barn. Many – it's not horses and tails this time. There are many things which, as John correctly notes, are not in fact transfers, which have taken place, including options contracts and other types of legal arrangements, which mean that the people with enough money to acquire a lot of address space, such that it cannot be sold to anyone else or transferred to anyone else but them, has already happened. 

That happened last year. It happened the year before. And so nothing that we do in policy, adding or deleting needs basis, nothing that we do here can control that. 

It can't control what will happen, and it certainly can't control what's already happened. And so for that reason I don't think that there's any reason – just the physical reality of the situation means that there is no reason to have needs basis, irrespective of my first comment, which I think is also valid, which is – would you have really put needs basis in if you had started from a position of no free pool? 

Vint Cerf: Thank you very much for that comment. Let me go to –

Paul Andersen: Jabber.

Vint Cerf: Go ahead.

Cathy Aronson: Jason Schiller. Google. NRO NC. Opposed. There certainly are purchases of IP address space without meeting ARIN policy. We can legitimize these purchases there by making the database more accurate. But by doing such we reduce the risk of organizations who complete these transactions. 

That means more organizations will buy more space without immediate need. This has the potential to cause IPv4 addresses to be concentrated in organizations with the deepest pockets and services that have the greatest return on investment per IPv4 address, enabling the widening of the gap between IPv4 have and IPv4 have‑nots is not good for the community.

Vint Cerf: Thank you very much. Microphone 1. 

Matthew Petach: Matthew Petach, I'm not sure if I'm speaking for myself in this case. This is a difficult policy indeed. I do notice that there's no staff assessment or legal assessment at all on this one, which I was actually kind of hoping to see what the legal team thought of this, hoping to see what staff thought of this. 

Certainly before it moves further, I think that would be very useful information for the community to have. I do find myself thinking a lot about words like QOS and weighted fair Q and sort of technical details based on my colleague from Microsoft talking about the cows have left the barn. 

Much like we do in a lot of our networks, we do think about how do we ensure that we don't have one particular top talker that squeezes everybody else out; how do we manage the limited resources of a piece of wire to make sure that we get at least some throughput from everybody on it? 

I think with a policy like this, I nervously support, but I would like to see some level of a cap or a limit on it. So rather than a strict needs‑based, we say not to exceed X in a year to prevent the completely egregious aggregation of resources that Jason Schiller just mentioned. 

I don't know if that's enough of a requirement for me to say I can't support it until I see that, but my sense of fairness does say I would prefer to see something in here that puts a cap and a time period on it to put some level of fairness back in the system.

And I really would like to see that staff and legal assessment does move forward with this. Thank you.

Vint Cerf: Thank you very much for that. Let me go to Microphone No. –

Dan Alexander: Sorry. Just to follow up on that, Dan Alexander, ARIN AC. This is just a Draft Policy, so it cannot move forward until staff and legal is done. This is really more for feedback of the room, whether your opinions are that this is something that we should be working on. So it would not move forward without it. 

Vint Cerf: Thank you for that, Dan. Microphone No. 3, please. 

Rhonda McFadden: Rhonda McFadden, Wells Fargo, speaking for myself and not my employer. I support this policy. I think that there's far too often the perception that ARIN can reclaim or force me to recuse my space. And I think that that just leads to misinformation. So I'm in full support of the policy. Thanks.

Vint Cerf: Thank you very much. Now we go to Microphone No. 2. 

Andrew Dul: Andrew Dul, ARIN AC. Speaking for myself. I think one of the things that is most important about this policy is that we're managing an asset of public good, if one wants to call it that. I'm sure that there are different ways to describe it. But we have to balance the needs of different members of the community. And the kind of paramount thing, if we look all the way back in history, was IP numbers are intended to be used on operational networks. And for me that's one of the core values that we have to adhere to. 

So how we do that I think is still open to debate, and this is a way to continue that debate. 

I have one objection to the current language, which talks about excluding certain aspects of policy. I think we can do a lot better in the way we write this rather than just saying we exclude a whole bunch of stuff. Thank you.

Vint Cerf: Thank you very much, Andrew. Let me take the microphone in the center rear, please. 

Brian Bullard: Brian Bullard, Wells Fargo, speaking for myself. I support this policy as written. I especially like some of the language clarification here. I know sometimes in the past it has been sort of scary for some of the folks I've worked with and in trying to figure out, make heads or tails of the whole situation. 

And thank you for clarifying that the legal and the other comments because I was kind of curious about that as well. So I'm glad to know that those will be coming forward.

Vint Cerf: Thank you. Microphone No. 2, then we'll go to No. 1. 

Milton Mueller: Milton Mueller, Georgia Tech and ARIN AC. I support the intent of this policy. I think it's pretty far away from being finished. I'll talk in more detail about that later. 

But I think it's really great to see that we are coming squarely to face with the obsolescence of traditional needs‑based allocation, and people seem to be no longer screaming in denial about this. We're significantly confronting the issue. The thing you have to know from an economic standpoint, needs has been a very subjective and arbitrary thing. Can you say I need this over a 30‑day period, a 30‑month period? That's a line we've drawn in policy. And now that the free pool is gone it makes no sense to be drawing that arbitrary line because essentially the market is what is going to be allocating addresses, the price system. That's how I would respond to Jason, is that if a resource has economic value, has scarcity value, there's no way you cannot do that. If you do, you create massive shortages or various kinds of distortions in people's behavior. And that's what this registry accuracy stuff is about. It's about ways of getting around the problem. 

The other thing I'd point out, the criteria for need has changed since, let's say, 1991 until now, and there's lots of people with very large blocks that under current standards they do not need. And if your concern is hoarding and speculation, those people which might account for 35 to 40 percent of the address space, those are the hoarders. And nothing is going to cause them to un‑hoard other than an attractive price that will pull those addresses and make them willing to release them.

So if you want to loosen up the market and make it more accessible, you're going to have to do something about relaxing needs basis. 

Now, I would say there are things in this policy that need to be much more systematically gone over. For example, the 8.1 principles would have to be completely rewritten. You can't just delete paragraph 3. You really would have to completely rewrite that. 

There's other minor verbal things in there. The other point I'd like to pick up on is the point Andrew Dul made, which is if the real goal here and the point of consensus is we want people to actually run networks to get address blocks and not just anybody, we could explore mechanisms, language for assuring that rather than just going out and knocking out needs basis we might have a simple operational criteria in there. Those are tricky economically also. I know from spectrum allocation that the "use it or lose it" requirement is going to be gamed. 

There's all kinds of ways of doing it. If we can get consensus around moving on from needs basis in order to get registry accuracy based on some kind of compromise of the sort that Andrew is suggesting, then we should explore that too. 

So I think this policy is not quite there yet in terms of comprehensiveness and its approach. 

Vint Cerf: I'll take Microphone No. 1 now. 

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC, speaking on my own behalf. I think I disagree with about three‑quarters of what Milton just said and agree with a quarter of it. 

For a third of the time that needs basis has been around, I'm going to count the beginning of needs basis since the NCP/TCP flipover in '82. We had no problem with needs basis. The problem was not so much one of demand so much as the criteria for it. 

I have personally been issued from my company class B by uttering the magic words "internal subnetting." 

You still have needs basis background. It's just that the requirements to demonstrate the need were much less than they are now. 

I think that with the no free pool, we need to look towards dialing things back and reducing what needs to be shown in terms of workload, in terms of evidence, in order to demonstrate need. 

Getting rid of needs basis is not the answer, it's like saying we have a problem in a certain part of the world and deciding obviously the appropriate solution to that problem is to turn it into a glass parking lot. That's simply not a solution. 

I'm in favor of dialing back the criteria for needs basis in a measured and iterative method over several months, years, whatever. But I'm opposed to getting rid of needs basis and therefore I'm opposed to this policy as written.

Vint Cerf: Thank you very much. Could we get the microphone in the rear center, please.

The problem is it's hard to see past this thing. Go ahead. You want me to continue and I'll come back to you. In the rear, please, center. 

John Springer: John Springer, Inland Telephone Company, ARIN AC speaking entirely for myself. I'm delighted to see the conversation continue. I believe that the matter is one not of eliminating or not eliminating needs basis but gray, not black and white. As far as the support of this specific policy as written, I want to see the conversation continue. 

Vint Cerf: Now Kevin. 

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I like cooking roasts. I cook them usually three and a half hours before dinner, and they're perfect. Sometimes I screw up and the three and a half hours isn't enough time and it's undercooked. When it's overcooked, you can't fix it; when it's undercooked, throw it in 15 minutes and you have an extra glass of wine and it's fixed. 

Our policy process on a policy that everybody in this room jumps up and says I love it, just make it happen, is six to eight months. The average policy is a year. A policy that requires work, a lot of back and forth in the community, is 18 months.

What I have heard a lot of here is: I like the idea of working on it; no specificity. This is a great idea, the time has come; no specificity. And what I'm seeing is two camps – one that says get rid of need completely, undercooked, to I oppose it completely, overcooked. 

Where do we get to in the middle of just right? What is that aspect in a runout environment that is just right? Because it seems to me that things have changed over time. 

There's a lot of different feelings. But what can you give us to continue this proposal that nobody feels like, oh, my God, if this happens, we're going to have to then do another policy? It's going to take 18 months for that policy to get through and look at the damage one way or the other that you're going to feel that you are being encumbered by. 

Vint Cerf: I'm going to close the microphones in a couple of minutes for people who might want to still have things to say. Let me take the center microphone, No. 2, please, Owen. 

Owen DeLong: Owen DeLong, Akamai, ARIN AC, very much speaking for myself. I'll start with addressing Kevin's comments. I think you've got it a little backwards. I think eliminating needs basis completely would be the overcooked state because it would be very hard to return from that error, much more so than a gradual relaxation, which is more of your undercooked issue. That we could go back and reiterate the policy and come out with something better. 

Just because – we constantly hear this argument that bad actors exist and are violating policy left, right and center, therefore we should adapt policy to fit the bad actors. 

I don't agree with that. I recognize and have long recognized that ARIN policies are not so much law or rule or even guideline, as they are a suggestion to the community of the behavior that we as a community have agreed is the desirable set of behavior among those, they're willing to cooperate in the Internet to make this giant Internet thing work. 

The Internet is a gigantic anarchy of many independent organizations operating many different independent things that all kind of manage to interoperate on some level.

It depends on cooperation. It depends on voluntary cooperation and good actors. The handshake deal has much more effect on peering than any contract. More traffic gets routed by handshake than by commercial agreement, even today. 

We need to recognize that. We need to stop trying to move policy into a realm where it legitimizes actions that the community has repeatedly affirmed are objectionable just because they happen to have become more commonplace. 

Were we starting today without any policy and any free pool, I would still want to develop needs basis. Taking a scarce community resource and allocating it strictly on the depth of pockets is not in the community's best interests. It is very much the market thing to do, and I realize that the invisible hand of the market ruling the world is a lot of people's ideals. 

I do not believe it results in an ideal situation or a utopia in any case in history. 

Vint Cerf: Thank you very much. Let me go to Microphone No. 3, then I'll go to No. 1, and then to the rear, No. 2. So No. 3.

Matthew Petach: Matthew Petach, one of those evil actors gaming the system by running to the empty line over here. 

I will note that to an earlier comment about let's just open it up and let the free market do what the free market does best, I would like to reiterate that even in our free markets, we do have controls in place. I think we've all seen occasions where stock trading has been halted because they've looked at it and said, holy crap, things are running amok. This is not what we intended. Let's put the brakes on and say hold your horses.

I worry about the policy as it stands because it really does completely cut the brake lines and say, oh, my God, I hope the vehicle just takes care of things. 

I would feel much better if we actually took a little bit more of a mid‑line between Owen's "we absolutely must keep needs basis intact" and the completely let the free market do everything and perhaps add something in here to the lines of not to exceed a /12 or a /10's worth of addresses in a 12‑month period. 

That prevents the deep pockets from completely doing one fell swoop and controlling the market, without unduly hampering the efforts of, I would estimate, most 90, 95 percent of the transfer needs that exist. 

I think this is a good start, but I think Kevin's "let's undercook slightly" is a very, very good set of advice for the community. So I would say can we come back or can we work on some language in here that will give us some of the controls, much like the stock markets have for saying, wait a minute. We have a way of putting the brakes on or we have a way of limiting damage in case things start to go too fast? Thank you. 

Vint Cerf: I'm going to close the queues because we are very close to and intending to have a break, but we have lots of people who have comments. Can I encourage you to be brief as possible so we can get through all this important discussion. 

Let's take Microphone No. 1, then we'll come to 2, and then 2 in the rear. Number 1, please.

Celeste Anderson: Celeste Anderson, USC, Los Nettos, speaking for myself. In looking at the entire transfer section, not just little pieces, I actually think we need to take a look at the entire section, now that there's been an exhaustion, and see whether the entire section needs to be rewritten.

It's confusing between IPv4, IPv6. If I'm merging with someone and they have both resources, there's a different policy than one or the other. And how is that done so I can clearly see where there's some confusion there. 

I also believe that we need to have some loosening of the needs assessment in the time period. But I don't believe we should get rid of it entirely. 

As someone pointed out, we are giving resources for people to actually use them, not just sit on them for a period of time. Thank you.

Vint Cerf: Thank you. We'll go to No. 2, please. 

David Farmer: David Farmer, University of Minnesota, ARIN AC. There's so much to talk about, but I'll limit myself. 

Vint Cerf: Stifle thyself. Thank you. 

David Farmer: I cannot support the policy as written. However, much of what the actual changes it makes I fully support. The balance is a little off. It starts with the title. There are a number of people that want to eliminate needs basis. The majority of the community does not support that. 

That doesn't mean the details of what is in this policy are unsupported. But if you insist on calling it eliminating needs basis, you're going to make me insist on not supporting it. 

So we need to tone that down a little bit and, as has been suggested, we need to find a new balance on what needs basis is. We need an operational need, and that's the primary thing, because of exhaustion and the need for conservation, what we know as need today is an abomination from the original Internet, but it was a necessary abomination. And we need to tone that back. But that doesn't mean we throw the baby out with the bath water. 

So we need to find an operational need. There's been a number of proposals that have talked about this. The attestation is an important thing, I think.

There could be some other things. I do think putting a cap on it is an important safety valve. Make sure we undercook it. I like that metaphor. And I'll leave it at that. 

Vint Cerf: Thank you. 

Scott Leibrand: Microphone No. 1, please. 

Marc Lindsey: Marc Lindsey, Avenue4. I've been involved in several large transactions over the last couple of years –

Vint Cerf: You need to understand something. I have these hearing aids, right? That's why I'm wearing these things. I have to cycle the damn things through several different programs before I can actually hear anything, so I apologize if you were speaking. 

John is suggesting that we hold the queues, take the break. Is that acceptable to everyone? 

Paul Andersen: Look at the person in front of and behind you.

John Curran: You know where you are in queue. This isn't very complicated.

Paul Andersen: This is a community‑building exercise. 

(Laughter.)

Vint Cerf: Yes, take a photograph. That's perfect. 

John Curran: I did that a minute ago. 

Vint Cerf: We'll take a legitimate half‑hour break. Okay, thank you, everyone.

John Curran: We'll resume at 11:00. Break is ready outside. 

(Break.)

John Curran: We have ample time for discussion. So we're going to reopen the queues. You can get to the end of the queue if you weren't already there. And I will now turn it over to Vint to moderate.

Vint Cerf: Thank you very much, John. I frankly don't remember where we stopped with regard to who was speaking. Was it over there? Yes, it was over at Microphone No. 1. 

Marc Lindsey: Marc Lindsey, Avenue4. I have two lives, but mostly relevant here, I'm an IPv4 broker. And the last year and a half or so I've done a series of transactions, many very large. I'm speaking from a specific, knowledgeable data point. There are others here who have their own data points.

So the idea that this needs policy is somehow preventing large supplies of shifting from large unused blocks held today to those who have deep pockets and want them, that's done.

There's no policies preventing that. People are finding ways to achieve their commercial outcomes independent of policy. And it's not violating policy. It is working around policy. People find ways to work around policy. 

So if your idea is we can keep needs base here and we'll stop this shifting of hoarded space with legacy holders to hoarded space by those with deep pockets, it's not working. 

So the idea ought to be if we have a transfer market, the goal is to take unused space today, put it in the hands of those who can use it – next year, two years, three years, whatever their financial engineering projections will allow. The focus ought to be on how do you make the market work fairly, efficiently, and transparently and how can the registry serve that function. 

Registry accuracy is one part of that. Controls on fairness is another part of that. This idea of hoarding and speculation are things you ought to avoid because there are real market distortions that are happening right now, in the transactions that I do, that you don't have the data in the registry to be able to analyze it. You have no idea what the transactions look like because there's barriers for the people to go look to the registry and say here's my transaction.

Now, eliminating needs won't automatically cause everybody to expose all their holdings, but it will reduce the barriers for those who now have a reason to work around it. 

Once you have the data of what's happening, you can move into controls that you want to address bad behavior. But first eliminate the barriers, get the data into the registry, and then build on policies to address bad behavior as you see it arise.

But don't hamstring network operators today who need address space, those who now have lots of it they want to put into circulation, don't hamstring that process to make it a darker market than it needs to be and eliminate your ability to effectively and fairly manage the market. 

So I'm in favor of the policy. I'd say take it down. Kevin's point is if we muck around with a lot of engineering on a different policy, 24 months will pass, the numbers will have swung all the way from one place to the other and you'll have no clear indication in the registry what's happened in the last 12 months, 18 months, 24 months. 

So my view is do something more quickly than not. This is a good start. It can be worked on. But from my own perspective I believe you guys ought to really be focusing on market controls and not holding onto needs basis in transferring when it doesn't really prevent the behavior you seem to be concerned about.

Vint Cerf: Thank you. Pretty comprehensive response. Let me take Microphone No. 2 and then Microphone No. 3. 

Michael Joseph: Mike Joseph, I'm a well‑done roast. I also work for Google, and one of the things I do, I speed often to work in the morning on the 101. I know this because most other people around me also speed. 

I don't think we should go raise the speed limit to 75 or 80 on 101 because it's what everyone is already doing. Some people might believe that would be handy, but I think the speed would increase anyway. 

The fact is registry accuracy is a red herring. We can talk about registry accuracy – registry accuracy is great, I think it's important – but it doesn't mean that we should allow the registry to be changed to accommodate unauthorized use of addresses just because the addresses are used in an unauthorized fashion. 

If not having the addresses properly registered is in any way making it more difficult for those entities using them in an authorized fashion, good. 

Secondly, I think the Section 8.2 stuff is a bit of a red herring as well in this debate. I know that was included in this policy. I suspect it was included in this policy to curry favor. 

I think that this policy is by and large about elimination of needs basis. And for anyone who wants to come up and talk about M&A, I think that's a separate discussion. And we actually had that discussion yesterday.

I think it's worth recognizing – and to answer the earlier question as to would we have needs basis today – in my mind, I think we would. Somebody actually at the break just mentioned to me, in fact, the transfer market is, in fact, a new free pool. 

And if we're going to have – if we thought needs basis was warranted in the old free pool, it ought to be warranted in this one as well. 

Networks didn't mine IP addresses using hard‑earned cash from the IP mines outside of Reston. They were allocated IP addresses based on need.

In fact, they were given temporary grants to use those IPs on the Internet based on their need. We can talk about what that need should be and how one should demonstrate it, and I think I'm perfectly open to a discussion on changes in Section 4 to talk about what need should look like. 

But the fact is they were allocated by the community based on need and they should remain needs‑based resources.

We can't make more of them. And the community continues to have an interest in ensuring the overall efficient use of IP addressing. 

I've heard a lot about futures and options contracts. In fact, I heard a lot more about it from the break. The fact is, yes, there are options in futures contracts out there. And I actually think it's not so bad. I think it's not surprising. I recognize that ARIN can't take a position on it nor should we. 

But the fact is people aren't going to option IP address space that they can never take possession of because of policy. 

Policy still has a role even in the face of an option and futures market. Sure, could you speculatively option something if you have a right to transfer that option? Absolutely. There's derivatives on lots of assets. And if people want to create derivatives on something like an IP address interest, that's their right. 

But the fact of the matter is it still remains a functioning market until we allow entities to take actual possession of IP address resources that they're not going to use efficiently. Or may not use at all. 

The fact is we as a community have an interest to make sure that operators continue to use IP addresses efficiently. We ought not allow an entity who has deep pockets – I'm not just referring to the large operators, such as the company I work for, many others, who have very deep pockets, I'm talking about the company who is selling a hosting or a VPS service having a much greater value on an IP address than an access ISP. 

And we shouldn't allow that hosting company to be incredibly inefficient with their utilization just because they can spend more per address than some other interested party. We have an interest as a community to make sure addresses are distributed equitably and remain distributed equitably. 

So in case it wasn't obvious, I oppose this policy. 

Vint Cerf: Thank you for your clarity.

Paul Andersen: Jabber.

Cathy Aronson: Jason Schiller, Google, NRO NC. This is in response to Marc Lindsey. ARIN policy is not preventing IPv4 addresses from going to organizations with deep pockets. Risk is risk of inability to complete the transfer due to source bankruptcy or source selling the interest to another party; that risk is mitigated if the transfer can be completed and recorded. I'm not sure that is a good thing. 

Vint Cerf: Thank you. Now let's go to Microphone No. 3, please. 

Rhonda McFadden: Rhonda McFadden, Wells Fargo, speaking for myself. Just a couple of points. I think it would be helpful if we removed any reference to mergers and acquisitions in this.

That would – with a merger acquisition, the needs, everything is transferring anyway. So I think that the needs‑based review is not required.

I think that it makes sense to have a needs‑based review for transfers, because I agree that we still want to make sure that there's equitable use of the IP address space, and it's not just being hoarded to be resold at a high dollar value.

And my other comment was about with the mergers and acquisitions, there's that commentary in there about doing the needs‑based requirement when the policy actually has step 12 or article 12 that talks about resource review, that gives ARIN that right to come back and review any of the resources that have been allocated in the past and gives you the right to request return of those resources.

So maybe it's worthwhile to consider taking this out. 

Vint Cerf: Thank you. Let me go to the rear of the center microphones. 

Kevin Blumberg: John, could you actually speak to the whole reclamation and the RSA? I think this would really help this.

John Curran: So recognize that we extended to the LRSA holders that we would not reclaim for low utilization. And then when we harmonized the RSA and LRSA we extended that to everyone, so everyone has the same service terms. So ARIN does not reclaim for low utilization. We will tell you – you're out of spec, please transfer. Figure out how to get these to someone who actually needs them, but we do not reclaim.

Regarding Section 12, resource review, if you truly are creative in your application to ARIN, and we discover that you're really creative in your application to ARIN after the fact, you will have the privilege of having a resource review. 

This is something where you explain your usage of your resources and we go back and look at your application. And since these are generally for resources we've just issued, it's pretty easy to undo that if someone gets creative. 

I would not recommend you – I would not recommend embellishment on your resource request form. And generally we don't have a problem. We have a few actors who are going to use the addresses for two weeks. They'll have completely finished their need with them because they'll end up on blacklists. 

And so by having a resource review policy we can minimize them requesting resources. And it's just useful from that perspective.

Vint Cerf: Thank you, John. We can now go to the rear microphone, center.

Michael Sinatra: Michael Sinatra, Energy Sciences Network, speaking for myself as always. First of all, I want to say that Dani Roisman is one of my favorite people on the entire Internet, so any disagreement I have with this policy is not a disagreement with him. And I think his intentions are great, and I think this is a good approach to start with. 

I do want to make a clarification that kind of comes out of Milton's and Marc's comment regarding hoarding. There are organizations out there, particular organizations that got their IP addresses very early on, that have a lot of them, who may be prevented from buying or selling IP addresses due to statutory regulatory issues because they're government agencies or because they have some kind of status that they can't tell that particular thing that might now be considered an asset. 

And that may make it very, very hard for nonprofits and other organizations to buy addresses simply because they may be prohibited from spending money on those sorts of things or they may be just unable to afford it. 

Does that argue against needs basis, or against getting rid of needs basis? Actually, I don't think it does. I think we can still get rid of needs basis or at least scale it back. 

What I'm saying is you're still going to have some market distortions but you're getting those anyway. If I can't buy IP addresses now, I'm not going to be able to buy them in the future. It doesn't really matter whether there's needs a basis check or not. 

So I think that the argument cuts both ways. The argument that you have these organizations that, oh, gosh, they won't be able to buy addresses if we get rid of needs basis. They can't do it now, so it doesn't really matter. I do think – I really like Marc's point about market‑conforming controls versus market‑distorting controls. I'm just saying that some of the distortions may remain after we move away from needs basis. 

In terms of the actual policy, I can't support this policy yet because it's still kind of in a draft state. It may make sense to start separating things like 8.2 and 8.3 to kind of keep – just to kind of segment things and make it a little easier for us to look at each section independently. 

But then again I don't know if that really makes sense because they may have implications for either one. But I do like Kevin's idea of the roast. I like the idea of maybe starting with small blocks. I know that doesn't help Marc right now, but maybe starting small blocks and removing needs basis or dramatically scaling back needs basis, putting some other lightweight controls on how we do transfers and things like that, that may actually help. 

So my feeling is, yeah, let's move forward with scaling back now that the free pool is exhausted. I think things have changed. I think it is time to start moving back. 

I would really like to know, though, as we take the roast out, we see that it's undercooked, we put it back in, I believe that Kevin said he has a glass of wine when he does that. When does that happen? When are we going to get the wine? 

(Laughter.)

Vint Cerf: I'll take that as a challenge. Let's go to Microphone No. 1.

Matthew Pounsett: Matt Pounsett, speaking for myself. I'd like to, I guess, address a couple of the things I'm hearing as justifications for doing this, such as fear of reclamation. If perception is the issue, let's do something that solves the perception problem rather than eliminating the entire thing. I'm sure there's some language we can insert into policy or remove from policy that makes it clear that the RSA – that what is declared in the RSA is what is true here, that nobody should be afraid of reclamation. 

Similarly, the idea that, well, some people are doing this anyway so therefore we should just let them – some other people have stated – it's not the way you do things. It doesn't help. And just because some people are doing it now doesn't mean that all the people are doing it who would do it if it was completely permissible. 

Taking away the restriction allows more people to – it justifies it. It allows more people to do it. It allows them to do it easier. I don't think that's necessarily the good approach.

If you want to speak about perception, phrases like "recipient organization bypasses ARIN entirely in order to secure needed IPv4 blocks in a timely manner," that just sounds like people who just don't want to play in the community with the rest of the community. 

I have no problem with scaling back needs basis, as R.S. said, in order to reduce paperwork requirements, make it easier, allow people to get through the process faster. On a long‑term scale, I think it would be justifying for needs basis to disappear entirely right around the time that ARIN's free pool has a steady net growth rate.

I have no fear of this being a long process of making iterative changes. I think that's the correct approach.

Vint Cerf: Microphone two in the front.

Chris Tacit: Thank you. Chris Tacit, ARIN AC, speaking on my own behalf strictly. For those of you who were here and heard me at the open mic yesterday, my message was that we really need to figure out what our objectives are going forward before we get hung up on drafting text. 

I think what this particular policy proposal highlights is us searching for our identity going forward. It's exactly that issue. I would encourage us if we can find a way, working with AC and staff, to solicit input from the community on where on the continuum we want to be in terms of emphasizing needs‑based assessments versus registry accuracy, because it's not a black or white and I don't think we throw one out or the other. But where do we want as a community to be on the continuum? 

I think we can move forward with this policy and others that are relevant, whether we do it in an omnibus way, as was discussed yesterday, or do we continue working with policies like these. But I really think we need to take that step back and try to get consensus around where we are on the continuum first, and I think the language will follow fairly quickly after that. Thanks. 

Vint Cerf: Thank you. I'm going to go to Microphone 1 and then go to the rear microphone and 2. 

Karl Brumund: Karl Brumund, employed by Dyn, speaking for myself. I'm actually in favor of this policy. My reasons are actually, you know what, let's actually have v4 completely all tied up. Let the people go nuts. Buy it all. Apparently there's this thing called v6. Yes, I know the equipment doesn't support it. Unfortunately, my VCR at home is collecting dust. Apparently I can't really use much with that anymore either. Same for my record player. My old Motorola StarTAC, it doesn't work too well, either. 

Technology moves on. You have to spend some money along the way. We seem to all be quite fine to not be using 8088s anymore. So the fact is that there will have to be an investment in a whole bunch of stuff, but let's really try and put the nail through the v4. Let it actually be completely all tied up. So what? Who cares? Once it's all gone, then we'll actually use this thing called v6. 

Vint Cerf: That's certainly a clear proposal. Let me get the microphone in the rear of Column 2. 

Gary Giesen: Gary Giesen, AKN. To address Chris Tacit's point, I think our goal should be to make sure that everyone gets enough v4 to make the transition to v6, and no more, no less. And so while I don't support the proposal as written, I would support a loosening of the needs basis to create a little bit of liquidity in the market so that everyone can get some address space if they need it. 

But I wouldn't support removing needs basis completely because then we'll end up with hoarding and deepest pockets will hoard all the address space. So I summarize my point, loosen it up, let's undercook the ham a little bit. 

We can always iterate, reiterate through the policy. But I don't think a wholesale removing of needs basis is prudent.

Vint Cerf: Thank you. I hope, Scott, that you're absorbing all of this diverse input. Let me get Microphone 2, then we'll go to Microphone 1.

Matthew Kaufman: Just a few additional points. Matthew Kaufman, speaking for myself, but working for Microsoft this week. I think when commenters on this proposal refer to organizations that are entering into options contracts, in order to secure enough space to meet actual customer growth requirements and calling them "bad actors" who are working around or outside of policy is simply inflammatory. There's no reason to say that.

The fact is they are doing exactly what you would expect them to do for their business, for their customers and their shareholders. 

I think that removing needs basis would help with the transparency of the market, because we would see fewer of those options and we'd see more of them converted into actual transfers that we would have visibility into. 

And I agree with the previous comment that you know in the worst case, if we really screw this up, we'll all have to move to v6, which would not necessarily be the worst thing. 

And to Kevin's comments, this is the kind of proposal that is likely to take so long that unless we all get together behind making it go faster, all of the things which make it irrelevant today, which make the policy considerations irrelevant today, will be triply or quadruply so. IPv6, of course, will be in a much different state, and it may in fact just be a no‑op. 

So it would be nice to see the community get together behind doing something in a timely manner to address the reality of having run out of addresses. 

It's not like it's a big surprise that we were going to run out of addresses. But we did not plan very well for that. And we continue to not plan very well for the realities that have followed. And quite obviously so to many of us watching.

Vint Cerf: Let me go to Microphone 1 and then I'll go to the rear, Microphone 2. 

Dani Roisman: Dani Roisman, SoftLayer, an IBM company, and the author of this proposal. My name is on the proposal as author, but there was a lot of input from a lot of community members, both ARIN and RIPE and NANOG, et cetera, over the past year actually. 

First of all, I appreciate all the discussion and input. It seems – I'm getting a general sense that most folks are in favor of doing something along those lines. Not quite this. 

Although I haven't quite gotten a sense of any specifics of what might people feel okay doing, I wanted to mention that there was a comment about the haves versus the have‑nots, and I actually wanted to propose that there are some smaller networks, up‑and‑coming networks, who actually – based on their current utilization today, and their modest growth plans over the next six, 12 months – might not actually be able to justify that much. 

However, two, three years from now might be in the position where they could be quite large, but find themselves not being able to get the IPv4 addresses that they still might need at that point in time.

Actually, the smaller start‑ups might be interested in taking some of their investment money and securing a modest supply of v4 addresses so they actually have them a year or two from now when it's very possible the transfer market could dry up. So this could still benefit some of those smaller start‑ups. 

The other thing I wanted to speak to regarding the land grab and depth of pockets, I've had the honor of working for two household multi‑national, extremely deep‑pocket companies over my career. And one thing I've learned in those companies is that, in fact, if you don't have a strong business justification, those pockets are actually more shallow than you would imagine. Those companies have deep pockets because over the course of their years – one of them over 50 years old, another one of them over 100 years old in the businesses – they've actually learned how to manage their funds. They've put funds towards profitable expenditures. They don't put funds towards land grab or hoarding because some nerdy tech guy says this is a good idea. And they definitely are not going to speculate on markets that have absolutely no precedence and have a tremendous amount of risk two, three years from now, four years from now of having absolutely zero value. 

So I actually disagree with the fud that's being spread around regarding deep pockets will jump on it. Deep pockets such as some of the large of the companies that a few of us represent here, deep pockets such as some Arabian prince who has billions of oil dollars and likes to throw it around. Even that Arabian prince isn't going to throw it around unless there's a significant glitz, glamour, or return on that investment. 

So I was going to say a large pocket, a large business, in fact, when I go to my employer and I ask for funds to purchase IP addresses on the transfer market for our growth, because none of the RIRs have the supply that we actually require over the next coming years, in fact, I have to do a tremendous amount of justification and I would posit that my justification to receive those funds is tremendously more stringent than ARIN's justification to actually transfer the IPs over to me. 

So I think we can take solace in that the companies with deep pockets have plenty of checks and balances and internal justifications to demonstrate actual need before they release those funds. 

The other thing I wanted to mention regarding the concern about the land grab and the large transfers, I spoke to a few of our associates in the RIPE region and asked them to show me statistics over the past 18, 24 months when they've actually had an open transfer policy, and the statistics they showed of the transfers that have occurred is that, in fact, it has not occurred. There has not been a large land grab. There's actually been an even keel rate of transfers over the past 18 months of multiple transfers across multiple companies of modest size. There's no one or two companies that came and pulled a /9 worth of addresses. 

There's a /18 here and /16 there and /20 here and a /14 over there. But it's actually fairly widespread out and actually it's across multiple recipients, well established ISPs, LIRs that seem to just be doing business as usual. In fact, the only precedent that we really have, which is the RIPE open‑transfer market, has actually dispelled that fear.

The other thing I wanted to mention was as you mentioned – as I mentioned at the open mic yesterday, I'm in favor of simplifying the policy language. So one of my goals here was to make it quite simple. Just cut to the chase, cut to the end game. 

That being said, if we need to make iterative steps, it will complicate the policy language, but I'm definitely eager to hear feedback and eager for assistance in help drafting a revision.

One of the recommendations that was meant around – that was mentioned regarding caps, there was actually – I've only so far received one very good, concrete alternative or compromise, which is perhaps taking a ratio of the organization's current holdings.

Let me walk through this. So let's say, for example, the proposal is that needs justification kicks in only if the requested resources for IPv4 are greater than, let's say, 50 percent of the current organization's holdings. 

And an organization is permitted to make a needs for a justification‑free transfer of up to 50 percent, maybe once a year, once every 18 months. Put a cap on it once every two years.

For example, if I'm a /8 holder, using it as an example here, I could make a transfer of up to a /9 over 12‑month period before I actually have to go through the rigmarole of a need assessment. 

So I would be interested in hearing some feedback on something along those lines. Again, tweak, titrate the numbers as necessary.

One thing about – there was discussion about working around the policy, whether or not you're speeding, you increase the speed limit, or whether or not you're violating the law, violating the spirit of the policy or not.

Truth be told, the larger players, the more involved folks, the folks who have organizations that have been attending ARIN meetings and RIPE meetings and APNIC meetings for years, those are the ones that understand how to go around the policy. 

So if we're more concerned with the small player, the new entrant to the market, oftentimes they actually don't realize that there are ways to work around the policy. So by having a policy that requires workaround actually further diminishes those small new start‑up's ability to operate in the space.

So if the big guy knows how to work around the policy, and if some of the policy isn't actually adhered to the way it's written, let's just simplify it and let's make it an even playing ground for the folks that are not necessarily as familiar with the space. 

One of the other recommendations that came through was if we eliminate needs base – and everyone's concerned about the speculators. I, too, am concerned about that. I think only folks that have a valid use for those IPs and have a valid business that utilizes those IPs should get the IPs. The Arabian prince who has four jets and 20 mansions and isn't running an ISP business and is just pulling them to speculate, he shouldn't get the IPs. And he shouldn't be flipping them around.

And I think one of the things I'd love to suggest and I would love to hear feedback is whether or not making a more firm anti‑flip, if that would help assuage some of those concerns. 

A speculator is not going to come in if they realize they actually can't do anything with these resources they paid for for maybe a 24‑month period only to find out there's a really good chance that 24 months from now these may not have any value. There's probably an equally good chance that they'll be at 4x the value, but it's a huge risk. That's the other thing I want to propose is maybe if you eliminate some of the needs base you actually put a more stringent anti‑flip.

The other thing I wanted to mention was there was talk about the mission statement of RIPE – of ARIN – I wrote RIPE separately – mission statement of ARIN redefining ourselves, better defining the problem. 

My understanding of the mission of ARIN is, of course, registration, accuracy, uniqueness and stewardship. And there's been talk about is this good stewardship. Part of stewardship in IPv4 days, when IPv4 was prevalent and young and starting up, was making sure there's equal access to the IPv4 resources – that's the stewardship – so that the entire Internet has an equal opportunity to grow. 

I would suggest that the stewardship today is looking towards the future of the Internet. IPv4, we all agree, is not the future of the Internet. And anything that will extend the life, artificially extend the life, or attempt to extend the life of v4 and do anything to distract us away from the rapid and aggressive adoption of v6 I would suggest is poor stewardship. 

In closing, I would like to say that I would really appreciate additional folks to help me edit the policy so that it's more acceptable. 

One of the first questions here were those generally supported the effort, which seems to be quite a few people, are there refinements to the changes which you think will improve this? 

There definitely are people that said I support it in principle. I think the refinements – I'd love for people to give me specific refinements and work on it together.

What I'm going to do, if it's okay, I think I'm going to post something to PPML, maybe with my contact info, maybe get five, ten people who are interested in working with me. We can break off to the side over the next coming months in preparation for April, and maybe propose a really strong rewrite in April. Is that appropriate to do in PPML? 

Vint Cerf: Yes. Have you finished?

Dani Roisman: I have finished, and Michael Sinatra is my second favorite person on the Internet. I will not tell you my first.

(Laughter.)

Vint Cerf: So there. Okay, so let me take the microphone, 2, in the rear. Can I now close the queues? I'm not seeing people jump up and down, so let's close the queues and take the microphone in the rear, at two. 

David Farmer: David Farmer, University of Minnesota, ARIN AC. I'll give Dani a specific change to make. Eliminate the word "eliminate." This is a conversation. We need to make room for the other parties in the conversation. It's been made pretty clear by a number of people that the complete elimination of need is a non‑starter. 

Now, if we want to have a conversation about what a rational need in the 21st century is, I'm all for that. But starting the conversation by saying there's no need for need anymore doesn't make room for the other guy in the room. So we need to make room for the other guys in the room. 

And as part of the ones, I'm on a different side here, I'm going to try to make some room for you, too. I would posit maybe the issue isn't need. We've always had need even back to the 1980s. 

What happened in the 1990s is we went, oh, shit, oh, boy, we're going to run out. Now, it's taken a lot longer than a lot of people thought it was going to be to run out, but we're still not ready for it to run out, unfortunately.

So but what we did in the 1990s is we added more than just need, we added conservation and somewhat draconian conservation as we got closer and closer to the end. 

I would posit that what we want to eliminate is that conservation and go back to just need. 

In other words, conservation is trying to make everybody's need fit. Well, it's not fitting. So now we just need to figure out who needs it, who doesn't need it, try to make sure that the people that need it have an opportunity to get it. 

I fully agree that internal controls on the money that's going to be needed to buy the addresses is going to be a far more efficient regulator of that need than ARIN could have ever been. 

And so I'm not all that worried about that, other than eliminate that, the conservation part. So the money takes over on the conservation part because people are going to conserve their money. 

But need is still something that I still think that we should still have something to say about, and that's because if we completely say – you don't have to worry about your need for v4, what justifies us doing that for v6? 

And we still have a needs basis in v6 and for ASNs. Now, it's a very lightweight need. And I think that's where we need to go back to is a very lightweight needs test. But that there's actually some kind of test. I will leave it at that for now. Thank you. 

Vint Cerf: Thank you very much. Let me go to Microphone 1. 

Joe Provo: Joe Provo, Google, speaking for myself entirely as a legacy resource holder. And I'm going to skip a bunch of stuff since I chose the suboptimal line and other people have said things. 

Oppose as written simply because the language issues that other's – J.C., Andrew, many other people – brought up, including David Farmer's – Matt raised a point that calling people bad actors is inflammatory, but saying we're going to now eliminate this whole section that we've based everything on for a long time is, in my mind, extremely inflammatory. 

Good to hear that Dani is willing to work on making adjustments.

We've heard a bunch of economic and market commentary. As far as I know, Milton might be the only economist in the room. So I'm more interested in engineering and the emphasis on the Number Resources to be used, not treated as market derivatives, or that we accidentally back ourselves into a reality where it's more advantageous for people to be playing in a market. 

It's good to hear that the RIPE data does not yet support bad action actually happening. As we discussed in omnibus yesterday, overhaul is needed but this isn't it. 

It's good to hear there are more points for compromise. R.S. was totally on target and David reiterated it with we've always had some form of needs. Just redefining what it is, is a cool thing. 

I'll skip that. We've already talked about that. Kevin's undercooking and Matt's market controls that others including Marc brought up are useful tools to address the problem.

But I'd rather speak to Chris's point of trying to outline the world in which we want to operate rather than spend a lot of time on a life support system for v4, perhaps, as we were talking after, in the scope of the omnibus yesterday. 

Looking at it from where do we want to be in a v6 world and what v4 scaffolding do we need to get there. That's it.

Vint Cerf: Thank you very much. We'll go to microphone zero, I guess, in the back of Column 2.

Devon Trautwein: Belair Technologies, Devon Trautwein. Kind of similar to what he was saying. I guess a lot of people like these analogies. So what I've been seeing so far, v6 to me is kind of like a boat with some holes in it, and v4 would be like the raft we're all trying to stay on. 

So instead of come to v4, it's a much better place, but there's some holes in it. Here's a bucket. I would be instead – let's fix the boat, basically. Can we fix the boat? Is there a way of fixing the boat? Can we concentrate on fixing the boat instead of trying to find more space on the raft, more ways of trying to stay on the raft? 

Or maybe it's time to fix the boat or that everyone's technology catches up, instead of shooting the raft, like that guy was saying, and forcing people on to the boat. Maybe we can do something more like maybe it's a little communist thinking, but how about a mandatory 10 percent handover or trade of your free IPv4, of what you're not using, 10 percent, and a 2 for 1 trade for v6, or whatever you think is fair, so therefore you get more v6 and you're prepared for the future and you're not only – and you're only trading maybe 10 percent. 

Therefore, people that only have 400 v4, they only lose 40. People who have a shit‑ton more, they only lose 10 percent, but there's way more for the free market. 

Once you've done that 10 percent, maybe you can reapply to get back into the pool, gain more v4 if we need an extension of v4. This would extend the longevity of v4 without having to hurt too many people. Too much? Too drastic? Too much? 

Vint Cerf: Don't know. 

Devon Trautwein: Either fix the boat or let's think about – communism was not all bad. It's what it turned into was bad. I think the idea in some ways maybe was not all bad. Maybe I overstepped my bounds, but that's what I've witnessed for now.

Vint Cerf: Okay. Thank you very much. Last comments now from Microphone No. 1.

Marc Lindsey: Marc Lindsey, Avenue4. Couple of points I want to make. One is that the address spaces that are in the transfer market are not in the ARIN free pool, they are in fact held by companies that have no obligation to give them back. 

So a paradigm which is based on the free pool allocation from ARIN is flawed if you apply it to the transfer market generally.

Behavior in the market is behavior in the market that this room cannot control. You can set up parameters that people will work around. Smart people will work around those rules. 

So the reality is what do you want to try to do? Do you want to overengineer a solution that causes creative people to work around it?

Great example of market distortion: Is this what you want to have happen? I have people come to me weekly, I have a company, my only asset is an IPv4 address with /24, /16. Can somebody buy my company? I don't do those transactions. But every week somebody comes to me and they're doing those transactions. 

That's what's happening with needs basis. Buyers are doing that ridiculous transaction to avoid having to go to ARIN and updating the registry. People are doing lease transactions for five, seven years, paying numbers that are made up to avoid going to ARIN to get the database updated.

People are doing contracts where they're buying up X millions of addresses and taking them over whatever period of time they want, because they want to work through the ARIN transfer process. 

These are distortions that are happening today. You can choose to make it more difficult for the registry to reflect that, if you want. Those transactions and market distortions will continue. 

So trying to suggest that needs basis and whatever you'll do in policy will alter that behavior I think is flawed; it's a flawed approach. I do think if you try to reduce the barriers, allow people to come out of the dark, have their transactions recorded, you have a much better opportunity to get your hands around the market in a meaningful timeframe.

And to call them bad actors, I think, is wrong because there's nothing lawful, ARIN creating laws or creating policies that are voluntary policies. Voluntary policies based on contract. 

So by not following those policies, you're not breaking the law. You're merely pursuing commercial outcomes to your company's advantage. 

And that's perfectly fine. But the point still being you're not going to change that behavior by saying it's 24 months or 36 months. 

What you ought to be focusing on is talking about: Can you qualify those who are acquiring those address spaces in a certain fashion; are they truly a network operator in some fashion? If the answer is yes, then don't try to apply some second guesses to the quantity of numbers they need.

So my view of the way to alter adjust Dani's proposal a bit is to eliminate need as a quantification of the numbers you can get but qualify the sellers as being those who have valid addresses to sell and the buyers as being those who have some actual network or a meaningful plan for a network and get out of this business of second‑guessing how much they need. 

Vint Cerf: Thank you very much. Is there any comment, John? 

John Curran: One quick comment. I just want to point out, Marc, you're perfectly correct when you say this room, in the guise of the ARIN policy community, cannot control what happens out there in the market. 

The reality is that there are addresses that are not under contract. And so that is what it is. 

I will also point out, however, that this same room is the ISPs who choose to accept or not accept whether to route an address block. The fact they've chosen to route address blocks under a Letter of Agency or under whatever commercial terms they are that aren't in the registry indicates in fact this room has made a choice to accept that circumstance. 

There's actually enormous authority in the room to decide what is appropriate, but you have acted to commercially recognize that there are circumstances where address blocks will not be updated in the registry. That's a choice by your actions as service providers. 

And so you have to face that reality. If you're not willing to change that then, yes, you must very much cope with what Marc talks about.

Vint Cerf: So interestingly enough, John, I wrote down in my two notes that I wanted to share with the rest of you. The second one was routability. 

And the point was that, in fact, routability is the one possible control mechanism that would cause people to come back to ARIN to be registered. If it were the case that you couldn't route unless you were registered, that would be quite a powerful lever. 

I'm not proposing anything like that. I'm just making the observation that we don't have levers like that, and as a consequence we have all these other needs‑based, complex algorithms, as an alternative.

The second thing I would observe about the gaming of the queues, could we get a thing, take a number thing and then we should be at least as smart as the banks are. 

The banks have one big damn queue and multiple servers, and the way it works you take a number, so to speak, or like when you go to the DMV, you get to sit down, get your AWB 6129 number, and when you get called, you get to speak. So maybe we should think about that. 

Are there any other comments? Yes, go ahead.

Dan Alexander: On that point, I wanted to – I noticed, as I was watching the queue, there were a lot of people who stayed over from NANOG. There were Fellowship members up there. There were even first‑timers up at the mic, and I really just wanted to say thank you because that's what we as the AC really need as the input. And also the emails that everybody got last night regarding the digital polling is another form of feedback. So thank you very much for all the information that you guys provided. 

Vint Cerf: I'll turn it over since we completed the policy block and lunch is looming.

Closing Announcements

John Curran: Yes, actually that completes our policies for the day, and we now have lunch outside. We will then resume at 1:00 with the Members Meeting and have presentations from the departments, the AC and the Board of Trustees. 

So I look forward, everyone, you're free to go to lunch. Hopefully they're setting it up at this point, and we'll see you back here promptly at 1:00 p.m. 

(Lunch break taken at 12:00)