ARIN 33 Public Policy Meeting Transcript - Tuesday, 15 April 2014 [Archived]

Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting.

Opening and Announcements

John Curran: If everyone will come in, we’ll get started. We have a couple of updates this morning and then some policy sessions to go through.

So, first, thank you for our sponsors, ServerCentral and RCN. Let’s give applause. They’re working hard right now.

(applause)

Okay. Webcast provided by Google, and that is operational. I’m told the webcast is up and running.

(applause)

John Curran: Today we have the NRO Activities Report, the NRO Number Council Report, the Internet Number Status Report, and Internet Governance Update and an Open Microphone.

We will also cover just a few policies. We have seven policies on the agenda, which should make for a busy day.

We have a reminder. Everyone please speak clearly so everyone can hear you. State your name and affiliation each time you’re recognized at the mic. Comply with the courtesies in the program.

At the head table we have Heather Schiller. We have - shouldn’t be hard - Dan. Dan, John Sweeting, Paul Andersen. I got him. It’s something in the wiring that’s just - Andrew Dul and Vint Cerf. There’s something broken up there. I look at a face and it goes blank. So let’s start right in.

First report is the NRO Activities Report. I’m going to go through this pretty quickly. I’m giving the report. We don’t have our Chair of the NRO which has currently rotated to AfriNIC. So Adiel is the chair. Because he can’t be here, I’ll go through it.

NRO Activities Report

John Curran: The NRO Executive Council is the five executives of the five RIRs. We get together and we do joint coordination on a lot of activities. Whenever the RIRs do outreach, when we do communications, when we’re trying to coordinate activities, we use the NRO as the coordinating body.

It’s a lightweight, unincorporated association formed in October of 2003. We provide and promote a coordinated Internet registry system. We promote the multistakeholder model. We coordinate the joint activities and we fulfill the role of the ASO within the ICANN model.

Our vision: To be a flagship and global leader for collaborative Internet Number Resource management as a central element of an open, stable, and secure Internet.

Our key focus areas. Obviously RIR coordination support. When our communications or outreach or Registration Services teams or engineering teams work together, we use this. Global collaboration and governance coordination. When people ask what the Internet number registries are doing in a particular area or if there’s an inquiry, we tend to be the ones that we coordinate our response.

And rebranding and repositioning of the NRO, something we’re spending time on, just making sure we understand what this lightweight coordination organization is going to be, where it should go over time.

Again, the executive committee. Adiel is our chair, Raul is treasurer, and Axel is the secretary.

The secretariat is hosted by RIPE NCC. We have an executive secretary, German, who keeps things running day to day. We have coordination groups, communications. We have our Public Affairs, our Engineering, our Registration Services group. We have an IPv6 coordination team.

The ASO, what is it? The ASO is a portion of ICANN established by an MoU. It was updated in 2004, recognized in the bylaws to oversee the global number policy development to handle the appointment of directors to appoint various bodies. You’ll hear more about this in a moment. I’ll let Ron cover most of it, including the members.

Finances. The costs of the NRO are proportionate to the Registration Services organization’s size measured in revenue. So this way AfriNIC is not disproportionately burdened by our activities, it’s proportioned to the size of the organization.

The expenses that the NRO incurs is staff and travel. For example, if we send Adiel somewhere to speak on behalf of all the RIRs, that while you think might be an AfriNIC expense, it might be an NRO expense if he’s representing all of us. So there is some sharing that goes on to make sure that collectively as a system we’re appropriately represented.

We also send money to ICANN. At one point it was 100 percent of ICANN’s budget. Now it’s a small pittance, actually, in the total amount of money. But we do contribute and have been since their inception of $823,000 per year.

Internet Governance Forum is an activity we try to help coordinate among the RIRs. We have a representative from the RIRs and the IGF Multistakeholder Advisory Group, two of them, Paul Wilson and Paul Rendek. We participated in the IGF in Bali, including contribution financially and coordinating a couple of NRO sponsored workshops. We are continuing ongoing support for the IGF at 100,000 U.S. dollars per year.

We have engaged in quite a bit of correspondence over the year to WTPF encouraging them to be more open. The IGF open consultation we responded to, ICANN’s regionalization and ICP 2 process, the ITU Council Working Group on IPv4 addresses.

Generally our positions are things you recognize. You can find them all on the NRO website. They call for defending the community based policy process for management of these resources.

Other developments. We’ve met twice in NRO EC retreats, once in Montevideo and once in Dubai. We formalized the Registration Services and IPv6 groups. We do RPKI project coordination because that’s a fairly complicated publication protocol that requires cooperation among us and with ICANN. And we engage in discussions with ICANN obviously when they want to know how the RIR system is interacting with them in some manner.

Global coordination. So in addition to the activity of the ASO at ICANN meetings, we also participate as the five executives in the I* collaboration activities. This includes - in addition to the five RIRs, it includes the IETF in the form of the IESG and IETF chair and the IAB chair. It includes the Internet Society. It includes representatives from the gTLD communities, including the associations there. It includes ISOC and ICANN. And we do a lot of collaboration trying to keep the system running.

We’ve been an active participant in the NETmundial structure. Raul Echeberria and Maemura Akinori are a part of the Executive Multistakeholder Community. We’ve done a written contribution to NETmundial.

1Net coordination. 1Net is something that came out of the I* Collaboration Forum for discussing issues. Adiel serves as the coordinator of that and Pablo is on the steering committee.

So that’s what we’ve been doing coordinating with the other RIRs on your behalf. I’m going to ask Ron to come up talk about the NRO Number Council, also known as the ICANN ASO AC.

Thank you. Ron.

NRO NC Report

Ron da Silva: Thank you, John. There are increasingly two things that I’m learning to dislike: One, having three teenage drivers, paying my auto insurance, and two is my annual check to the US Treasury. So all the US citizens in the room, happy tax day. And a good morning.

So I am Ron da Silva, Vice President of Network Engineering Architecture for Time Warner Cable and also a member of the NRO NC, and I rise today to provide a report on our activities.

There are really three things I want to leave you with this morning, and they are what is the NRO NC and how is that different from the ASO AC? And, secondly, what is the global - what global policy exists, what is a global policy, and what is the process for developing global policies? And then, lastly, our recent activities, what is the ASO AC doing?

I’ll briefly go through this very wordy slide and really want to provide a high level of the NRO. I know John just talked about this, and I have several slides that follow. We’ll fly over them so as not to reiterate some of the same material.

But if you think about these different acronyms, and a lot of words here, ICANN is the Internet Corporation for Assigned Names and Numbers and performs the IANA function. What’s the IANA function? The IANA function is the Internet Assigned Numbers Authority. It is responsible for ensuring uniqueness for a number of resources across the Internet.

ICANN has several supporting organizations and the ASO, the Address Supporting Organization, is one of those. The ASO has - is comprised of an Address Council, and to fill that function, as John said a moment ago, the NRO was established to name an NRO Number Council to satisfy the ASO AC function in ICANN.

That’s always a little complicated. I was just asked the other day what is the difference between the NRO and the ASO, and really I think just from a mechanic standpoint, this slide tries to illustrate how those things are interrelated, but you can interchange the two terms and I think everybody would be okay with that. In fact, I will probably do that in the rest of the slides.

The NRO, as John said, formed back in ‘03, revised in ‘04. Comprised of representation from the RIRs. I’m hearing your mysterious buzz. That might be me.

So the executive council. Comprised of one member each of the RIR boards. John touched on this already. And the Numbers Council, which is three members from each of the RIRs, so the three of us here today representing ARIN on this, and there are 12 others from across the other RIRs.

So what is the ASO? As I said, the ASO is a supporting organization within ICANN and NRO NC is formed to support that role.

Some of these slides, by the way, is meant to be standalone. We use these materials as part of the NRO team at ICANN meetings and at other venues to be able to communicate to sometimes a very diverse audience that may only know things about names and don’t really care about numbers. So we belabor some of this detail for a broader audience, so I apologize if this is rather repetitive for you or something you’ve seen over and over and over from perhaps Louie or Jason.

But the membership here, I’ll ask them to stand. Jason, if you could stand. And, Louie, I see you on the other side. This is your representation from the ARIN region in the NRO NC. Louie also holds the honor of being the Chair of the NRO NC. He’s held that for several years now, and we thank them for that. They are both elected by you to represent you in this function. I’ve been selected by the Board to complement the team of the three of us.

And, similarly, each of the other RIRs have two elected members and one appointed member to comprise the 15 members of the NRO NC. Enough about that.

The second thing I want to talk about is global policies. And a global policy is a policy that has been shepherded through each of the RIRs, so a policy that may originate here in ARIN, similarly in the other four RIRs, go through each of the RIR’s Policy Development Process and be consistent across the Internet, across the globe, and have some requirement or some request or some interface, then, with ICANN or with IANA and needs to be coordinated across the RIRs to present a uniform or a global policy back to ICANN for ratification and implementation.

That’s what a global policy is. Conveniently, the NRO NC or the ASO AC, whatever you want to call us, doesn’t have any current new global policies to occupy ourselves with.

But if we did, like I said, this is the policy that it would follow. Looking at this graph from left to right, each in the regional communities have their own Policy Development Process. Global policy would go through that normal process, be reconciled by the NRO to ensure that it’s in fact uniform across each of the RIRs and then has actually followed the process prescribed by each of the RIRs. And then, if so, we then make recommendations back through ICANN to implement and enforce those policies.

So moving ahead. Now, since we don’t have any current policies that we’re tracking and shepherding through the global development policy process, we did have some activities around a previous policy. This one was ratified back in May of ‘12, and basically there was some desire for clarity on the implementation from IANA.

Specifically the policy says: Allocations from the IANA may begin once the pool is declared active. But then we’ve introduced the recovered IPv4 pools and different policies for how all that is managed.

So the ASO went back to the five RIRs and consulted with our respective regions to make sure the clarity that we were given back to IANA represented the desires and the goals of our respective communities.

And here’s some of the clarification we’ve offered back. Namely, the allocation from - the first allocation from IANA recovered pool can happen immediately and anything else can follow whatever normal policy exists for distribution of resources. Seems pretty straightforward. So that’s the global policy.

Now recent activities, aside from global policy, since we don’t have any new global policies to track, we have revised our process for appointing ASO members to different various bodies outside of the ASO. Some are enumerated here. We’ve also participated in the ICANN meetings back in November and also back in March, and I was fortunate enough to go to the March meeting which was two weeks after the NTIA made their announcement, so this was probably the first ICANN meeting I’ve been to where the entire meeting wasn’t about names.

And, in fact, a lot of the meeting was about numbers and what is this whole announcement about and what is the IANA function. So it was kind of refreshing, being a numbers guy, to be at the ICANN meeting that wasn’t all about names.

So no new gTLD spin. None of that stuff was happening. It was all about what governance are we going to put in place and how does that work and what are numbers anyway.

And then general ICANN outreach. We looked to provide webinar. We looked to communicate with the rest of the communities there in ICANN to make sure they understand what is an RIR, what is it that we do and what are numbers in the space and why does that really matter to the folks who are primarily focused on names.

I don’t mean to diminish the security side of things or the DNS side of things, they also get probably shortchanged, but predominantly you find that the ICANN meetings is all - a lot of it is about names.

And also we’re responsible for nominating two members to the Board. ICANN seat No. 9 is occupied by Ray Plzak and No. 10 by Kuo Wei Wu.

Some other appointments that we’ve made to different ICANN bodies by the NRO Nominating Committee, the Meeting Strategy Working Group and the Cross Constituency Working Group on Internet Governance and various folks we’ve put into there.

And that’s it. Any questions? Can’t help you with the Internet.

(applause)

John Curran: Okay. Resuming. We are going to now pick up working on our policies. We’re about two minutes early, but I think we’ll take advantage of the time.

ARIN 2014 3: Remove 8.2 And 8.3 And 8.4 Minimum IPv4 Block Size Requirements

John Curran: The first policy we’re going to consider is Draft Policy ARIN 2014-3, which is Remove 8.2, 8.3 and 8.4 Minimum IPv4 Block Size Requirements. I will do the introduction and then I’ll have Owen DeLong come up and do the AC presentation.

This originated in January 2014. The shepherds are Owen DeLong and Bill Darte. And it was accepted as Draft Policy in January 2014. It was presented at the Public Policy consultation at NANOG 60. It’s in your guide and online. It was posted for PPML and for feedback which means the AC needs your feedback on whether or not this is good number policy. Is it fair and impartial? Is it technically sound? Is it supported by the community? Should the AC continue to work on this or get rid of it.

Introducing Owen. Come on up.

Andrew Dul: The remote participants are reporting that the Web feed went down. So I don’t know if we want to hold.

John Curran: Yes. Can we confirm whether we have an external Web feed.

Andrew Dul: We have the transcript.

John Curran: We’ll have to work from the transcript so we don’t delay indefinitely. Hopefully we can get the network back online for the remote feed.

Owen, why don’t you proceed.

Owen DeLong: Good morning, everyone. I’m Owen DeLong from the ARIN AC, and we’re here to talk about 2014-3. All three transfer sections make the minimum block size allowed to be transferred to /24. The argument from the policy author is that in a post exhaustion world, policy should allow and enable networks to move blocks around as they see fit without arbitrary regulation of minimum size.

And it proposes to remove all instances in 8.2, 3 and 4, which set a minimum transfer size of /24. There’s been pretty minimal discussion on the list. Several posts have been expressed in favor for abandoning this. There’s been one person on the list supporting it and one person on the list suggesting that relaxing from /24 possibly as far as /28 but not removing altogether might be a good idea.

So for discussion points, should an organization be allowed to transfer existing blocks without size limitations, and is there any improved language or comment that you wish to offer.

Microphones are open.

Discussion

Paul Andersen: Microphones are open. Could I have a question just for my own? Is it clear to the AC which sections are being changed.

Owen DeLong: Yes, 8.3, 8.2, and 8.4.

Paul Andersen: Removing a bullet point from each.

Owen DeLong: Yes. The part that says the minimum transfer size is a /24.

Paul Andersen: Would it affect the minimum transfer size as the smaller of the original allocation size of the applicable minimum allocation size in current policy in 8.2?

Owen DeLong: It would not. If it refers to 8.2 and we remove the minimum transfer size from 8.2, it would affect that part of it.

Paul Andersen: Thank you. Center microphone.

David Huberman: David Huberman from Microsoft and the policy author. The reason I proposed this policy is - there’s quite a few reasons. First off, this is an artifact of policy that’s developed over many years. I do not believe, having been there, that there was a whole lot of thought put into the virtues of a minimum when these policies were created.

Secondly, this isn’t ARIN’s role. ARIN’s job is not to put artificial basements into the routing space. ARIN doesn’t have a role in the routing space. Not much of a role anyway.

It is up to the operators to decide when and when we won’t carry traffic from our peers and our customers. As an operator, as AS8075, nothing stops me from accepting route announcements that are longer than a /24, that are smaller than a /24. ARIN policy, however, provides somewhat of a barrier to people who wish to obtain less than a /24 in a post exhaustion world. They can’t go to the transfer market and get one, even though I’m perfectly willing to carry it.

This doesn’t make technical sense. It doesn’t improve the operations of the Internet. It doesn’t fix any problem that technical operations are having in 2014.

And, therefore, I don’t think it serves the operator community in any way, other than to be a barrier to some cases where they want smaller than a /24.

Secondly, I’ll note that both at APNIC and RIPE over many years there’s been policy that allows PI space as small as a /32.

The Internet didn’t break then. Looked at the stats a few years ago, and there were well over a thousand PI assignments of less than a /24.

Thirdly, organizations are already exchanging smaller than a /24 for peering. We have interconnections with transit providers and peers where we are announcing less than a /24 and they’re accepting it. So it doesn’t make a whole lot of sense where that exists for ARIN to have this minimum, which I believe is arbitrary.

So, again, for the purposes of operating the Internet on a day-to-day and end-to-end basis, I don’t think ARIN policy makes a whole lot of sense here.

Paul Andersen: You’d be supportive of the first bullet point of the discussion then, obviously.

David Huberman: Should an organization be allowed to transfer

Paul Andersen: Your answer - yes.

David Huberman: Should an organization be allowed to transfer existing blocks without limitations on size. Existing blocks? I support my policy proposal, yes. I’m not sure what that bullet -

Paul Andersen: That I assumed.

Owen DeLong: If you support the policy proposal, the answer to the first question is obviously yes.

Paul Andersen: Although you do seem concerned. I’ll let you think about that.

Paul Andersen: The microphone would be helpful there. So let’s go to the far microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. David Huberman only talked about routing. There is another technical piece that this block size relates to, and that is reverse DNS.

By having a minimum allocation size of /24 allows a clean reverse DNS delegation. Is that sufficient reason? I don’t know. But it’s not completely arbitrary. There is some logic behind it. I will also note that I’m personally less concerned about it within the ARIN region. It seems kind of perverse to be moving around smaller than /24 allocations between the RIRs for that DNS delegation reason that makes that unnecessarily complicated in my view and shreds any regionalization completely. Not that that’s not already happening. Just a matter of extent.

I’m getting a sign to move forward. So -

Paul Andersen: Are you supportive of the policy or - you’ve raised a concern.

David Farmer: Mostly neutral to not supporting.

Paul Andersen: Far microphone.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council and Time Warner Cable and also the guy who runs a very small friends and family network who has been doing classless IN-ADDR delegation for over a decade. It works fine.

I’m not concerned about that. ARIN can put records or C name records in reverse DNS instead of NS delegations. That works okay.

We have never ever warranted routability. In fact, we have expressly disclaimed any warranty of routability. The routability is between you and the people who you pay to route the network.

We have, however, guaranteed uniqueness and we can absolutely guarantee uniqueness and there’s value to uniqueness in network numbers that are not globally routed. I am in favor of this proposal.

Paul Andersen: Thank you very much. Next speaker.

Matt Pounsett: Matt Pounsett, Afilias. David Huberman came close to this but I don’t think quite spelled it out. There’s another good reason for this, and there’s good stewardship in doing this. Right now, if you’ve got five small organizations that only need a /28, they all get /24s.

We can now serve them all out of the same /24 if we remove the minimum allocation size. I think that works well. As R.S. mentioned, there are no problems with DNS. The RIRs generate their configurations out of DNS already. That’s just going to work. I don’t see any reason not to do this. So I support this policy.

Paul Andersen: Support. Okay. Thank you, sir.

Jason Schiller: Jason Schiller, Google and the NRO NC. I just wanted to echo the comments that David Farmer made with respect to routing and aggregation as well as delegating the DNS. He made some points that suggested that maybe these things are difficult. Maybe they are; maybe they aren’t. I’ll let the community decide that. But I wanted to make sure it was clear that if these concerns are valid in international space that is between RIRs, I think they’re also valid within the ARIN region without transferring between RIRs, simply transferring within the ARIN region, and I think they’re also valid within individual organizations’ networks as well, because the implications are the same, whether you have to delegate DNS internationally or within the ARIN region or within organizations that a single company runs. It’s equally painful.

The other point I want to point out is I personally do have concerns about the size of the routing table and the implications that has on the default free zone. Certainly if we allow small blocks to be transferred, people will get small blocks and then they will go to their upstream ISPs and convince them to route it or go other places.

I think this is not a good situation for the Internet to be in, for the default free zone to be in.

However, I think that there are some cases where smaller blocks do make sense when they’re not being routed on the Internet. We have in the past created policy that required resources that were globally unique that were expressly required not to be routed.

I don’t see why we couldn’t do that here. And I think one good example of this came up this week earlier when we were talking about exchange points.

You may have an exchange point that only has two or three participants. They may not need - may not ever need a /24. A /28 may do them fine. And this block has no need to be routed on the Internet.

So I think if we want to enumerate some use cases where smaller blocks might be useful in cases where they’re not routed, I would certainly support that. But I don’t think it’s good to encourage small blocks to be exchanged with the expectation that people will get them routed somewhere.

Paul Andersen: Not supported as currently proposed.

Andrew Dul: Could you clarify whether that was your personal opinion or Google’s opinion.

Jason Schiller: That is my personal opinion.

Paul Andersen: And not support it.

Jason Schiller: No, not as written. I think that we could put some constraints in there and I could support it.

Paul Andersen: Any remote? Or are we still having technical -

Andrew Dul: We don’t have any current remote participants. They’re having a hard time keeping up given the constraints.

John Curran: Just administrative. The ARIN meeting network is apparently back up but somewhat unstable. That’s also causing issues for remote access. Should stabilize shortly. But we don’t have all the remote participants at the present time.

Bill Woodcock: Bill Woodcock, PCH. So, first of all, there’s no technical issue with the delegation. It works fine as you’ve heard from other people who have been in the DNS industry professionally for quite some time.

Secondly, on the issue of whether this will cause the routing table to explode, what you’re seeing here is the tip of the iceberg of eyeball networks versus content networks. The content networks need to be able to advertise services. The eyeball networks would like to force content networks to be their customer. One way of doing that is deny them access to IP addresses so they have to get the IP addresses through the transit provider.

All of that, sure, ten years ago, okay, but we’ve come a long way since then, and it’s not clear to me that repeating this same fight over again now that we are in the present, in the 21st century, is really useful.

There are content networks that are just as large or larger than eyeball networks. Jason, you work for one of them. You work for one of them whose stated position on this policy is opposite yours -

Paul Andersen: As I see counsel rise, I assume he would be saying right now, if I could channel him, to keep specific company names out. That would be my guess is what he was rising for.

Bill Woodcock: So, in short, denying content networks access to small prefixes does not keep the routing table smaller. And, in any event, ARIN’s job is not to manage the size of the routing table anymore, and in any event, even the cheapest routers I buy for tiny, tiny sites now have 16 gigs of RAM and can hold many, many millions of routes. So this is also a non issue.

What does seem to me to be an issue in the era of transfers and paying for IP address space, paying for access to IP address space, paying for transfers, whatever you want to say, is that we have a choice for somebody running a server between forcing them to get an advertised /24 and allowing them to get an advertised whatever size they actually need, which might be, say, a /32. Or, viewed a different way, if they had 256 servers, as they almost certainly do if they’re a big content provider, they could use a /24. Or they could go out and get the /16 that the eyeball networks are forcing them to buy right now and waste almost all of it.

Alternatively, the eyeball networks could get that /16 and serve 65,000 actual customers with it instead of forcing it to sit empty and complaining about the number of routes in the routing table when their routers are mostly setting update.

Paul Andersen: I would take that as support.

Bill Woodcock: I strongly support this proposal and any other that helps get rid of legacy minimum allocations.

Paul Andersen: If you could stand there one more second. Don’t run away because, Owen, I don’t know if you had a question or comment.

Owen DeLong: I was going to comment.

Paul Andersen: Sorry. Thank you.

Owen DeLong: So lots of ISPs that just got tarred with an interesting brush there are not actually eyeball networks but backbone networks and have a lot of customers who are content providers and some customers who are eyeball as well or eyeball providers as well.

And the reality is that this would be an impact on their routing table. And I’m happy for Bill that all of the routers he’s buying for small sites have 16 gigs of RAM and can support several million routes.

But a lot of the backbone routers that do hardware forwarding don’t have so much space for their forwarding tables and don’t actually have the ability to support more than about 700,000 routes or so, and until those routers get replaced, rapid growth of the routing table is still a valid concern.

Paul Andersen: You would have concerns with this policy.

Owen DeLong: I absolutely have concerns with this policy.

Paul Andersen: Everyone has to. We’ll go to remote participation, and then we’ll go to the blurry-eyed traveler.

Andrew Dul: Marla Azinger: I don’t support as written. I think some parameters could be constructed to make up for the pro reason Bill mentioned. And, honestly, it doesn’t completely matter what ARIN hands out. Operators will decide what they route.

Paul Andersen: So supportive. Thank you. Center microphone.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Many years we’ve had new /8s get turned up, and then the inevitable it’s not routable, it doesn’t work, we have to clear out all the filters have come up. And we haven’t had that for a little while now, thankfully.

A /32 of IPv4 is not going to get routed. It’s not going to be usable for a while. Maybe a /25 will. I don’t know.

But part of the ARIN NRPM for me as an Internet provider has been being able to show and point our customers and our customers’ customer to a document to show this is the way IP space works, here are the rules around IP space.

There was talk yesterday in regards to this to say no, this should be in a policy document separate from the NRPM. But right now we have - this is all we’ve got.

My concern is that I’m going to have customers who are going to say I want a /32 pulled out of your network. I want to transfer - ARIN says it’s okay. Here’s my legal document to say that I’m allowed to do this.

And it’s actually going to allow companies to justify court orders allowing for transfers that potentially would never have happened before. And that is an impact to my company.

So, no, I do not support this. What I do support is a look at reducing the amount over time as the industry operationally is able to support it. And I need to know when that is.

Paul Andersen: Your concern is timing more -

Kevin Blumberg: My concern is not only timing but having a minimum prefix. I don’t think a /32 is a reasonable - so as in no minimum - a reasonable expectation. I would support slowly dropping the minimum over time and seeing how that impacts both routing table and other issues.

Paul Andersen: Thank you. Administrative concern or comment.

John Curran: The meeting network should be back up and operational. You may safely switch to it. Thus sparing the hotel guests from what we’re otherwise doing to their poor network. Remote participants should be online, webcast should be online, and we should be good to go from here. Thank you.

Paul Andersen: Thank you for cooperation and patience.

Gaurab Upadhaya: This is Gaurab from Limelight Networks and also on the APNIC Board. And when our transfer policy was being discussed, the policy chair, I just might want to point out that though David said we have allocated /29s as PI, I was trying to get access to our transfer policy. I think we will not accept a /29. So that is an issue that you might want to look at when it comes to it.

I think this is a valid proposal, /24 being used in sites where just using one or two IP addresses is a waste of IP address space. But I would like to see some language which limits how it is done so that I don’t have people trying to transfer /32s in and out on day one.

So some - as a slow start, let’s call it a slow start, in terms of how this is done. Otherwise I support the policy. But transfers - inter region transfer, you might need to do a bit more work and have policies in other regions that will also accept these transfers.

Paul Andersen: Thank you. Dan.

Dan Alexander: I think just the one point that I would make is I disagree with the term that this limit was an arbitrary decision or that it’s an arbitrary designation, because I don’t think that ARIN policy is at all interested in setting that limit, but the policy is there to support the consensus of what network operators are doing. It wasn’t always a /24. It used to be back in the day a /20 because that was the consensus of most people that was the smallest block that anyone wanted to route. So the policies were in support of that.

And of course there’s always exceptions and you’re always going to have agreements between operators that will route something else, but eventually we reached a point where the general consensus out there was people were routing blocks down to a /24. So the policy responded.

I think the policy should be - in this particular case should be reactionary and not an instigator in a change in the global routing.

Paul Andersen: Thank you. Center microphone.

Robert Seastrom: Rob Seastrom. Again, I’m going to jump around a little bit here. I would like to first reply to Dan and Owen’s concerns. Several years ago, I want to say probably four, there was a research project undertaken at NANOG late at night. And it involved alcohol, and routing longer prefixes.

Paul Andersen: Never.

Robert Seastrom: And it worked surprisingly well. However, sobriety and better judgment prevailed in the morning and the results of this were never widely disseminated. I encourage somebody who has the guts to actually try this and then publish the results to do disability testing with longer prefixes to inform the discussion. But it works better than you would expect.

If we’re concerned about echoing people’s filtering policies, in general the filtering policies don’t exist these days.

To Owen’s point, I’ve personally replaced several generations of routers. I have in the course of my employment replaced several generations of routers. I stood at this microphone many years ago and iterated through stuff from IMPS and ENSSs on up to the present, and I’m not going to bore you by repeating that, but your routers have a finite lifetime and they’ll be replaced eventually. And a routing table slot that holds a /29 does not need any more space than a routing table slot that holds a or /24 or /20.

So I think rumors of routing table exploding are only interesting in comparison to there being a case where you well and truly can’t get any more prefixes, which in a transfer market just isn’t the case.

So this is a stewardship issue, not really a routing table issue. To the point of transferability between RIRs, the classless IN-ADDR delegation RFC is 2317. Portability between RIRs can be handled by chaining CNAMEs. A CNAME to a CNAME is expressly permitted in RFC 1034 Section 3.6.2. So I don’t see any difficulty with that either.

I don’t see any technical difficulties with my routers, or otherwise and I remain strongly in support.

Paul Andersen: Still in support. Thank you.

I’d ask if you wish to comment on this proposal you start typing if you’re a remote participant or approach a mic because we’ll be closing mics shortly.

Current microphone.

He was first? He yields to the back microphone.

Masato Yamanishi: My name is Masato. I’m current APNIC policy SIG co chair. And I’m neutral to this proposal because I don’t have a position, but I have a question about the inter RIR part. And as you know, minimum size in APNIC is /24. Then if this policy will be adapted but APNIC will not do so, is it still the policy?

Owen DeLong: ARIN policy requires a compatible needs-based policy in the receiving region for such a transfer and also requires that the receiving RIR accept the transfer. Therefore, since APNIC’s policy is not compatible with longer prefixes currently and presumably APNIC would not accept the transfer on either of those basis, the transfer would not go through in that case.

Paul Andersen: But a /24 -

Owen DeLong: But a /24 still would.

Paul Andersen: No implication for -

Owen DeLong: Doesn’t have any impact on APNIC.

Paul Andersen: Very good clarification of potential unintended consequences.

Milton Mueller: Milton Mueller, Syracuse University and Advisory Council. I’m speaking in favor of this. I just wanted to respond and maybe ask a question about a comment that Kevin made about getting court orders to carry a particular route. Is there any evidence of that ever happening.

Paul Andersen: Kevin, did you want to respond to that quickly?

Kevin Blumberg: Kevin Blumberg. There have been issues where companies have gone to court over IP address space in the past, specifically to yank out space. John, you can probably speak more to that than me.

John Curran: So it’s not with regards to routing address space. We have had cases where a single - a party in a proceeding believes that as a result of the proceeding that they’re in and they’ve gained the material assets of the corporation that they’ve won against as part of their judgment, they’re seeking everything: names, assets, and the IP address of the website.

Well, the IP address of a website has one address and a block that’s part of a provider’s block. And we explained that. But it’s also very clear to say that we literally can’t administer the change if we wanted to. It’s not compatible with the policies adopted by our community.

If we didn’t have a restriction, we would still argue that that wasn’t permanently allocated, that was as part of a service, we’d leave it to the service provider to argue the point. But the fact of the matter is that the fact that there’s been a minimum has been useful in past proceedings where we’ve been involved because someone has tried to pry a single IP address free, if that’s helpful.

Milton Mueller: That sort of answers my question, because it doesn’t strike me as an argument against the proposal, because the point here is that ISPs can decide what they want to route and don’t want to route. And if it’s too small and they don’t want to route it, they don’t have to route it, if I’m correct.

So nothing about this proposal, being able to yank a smaller segment out through some court proceeding, has nothing to do really with routing but with conflicts over assets. I don’t see how that argument bears on this proposal at all.

And also wanted to address what Dan said. I think it’s very interesting from a social scientist’s regulatory economist viewpoint, there are these situations in which the industry decides that they want something to be a rule when in fact they have the discretion to do things or not do things collectively or not. And you’re saying that there was kind of a consensus that nobody wanted to route below /24 and so we made it into a rule, but now we know that some people don’t mind doing that. Some other people can do that.

And you’re saying, I think, that you don’t want ARIN to be in the lead. You want them to be codifying what practice already is. And I would think that that’s kind of a difficult line to draw; that we - you know, if - they can’t change their practice unless we change the rule in this case it seems to me. So I would still favor allowing the practice to be more flexible under the current situation.

John Curran: Just to respond on one little aspect. I didn’t want to imply if this policy went through that organizations would be able to go to court and get address space, one address transferred. What I wanted to point out is in a single past case it has been fortuitous that we’ve had this policy because rather than having to argue about whether or not the service provider durably transferred one IP address to the website or not, we were able to simply say our policy set by the community do not allow the single transfer of an address.

Without that, it’s not that necessarily there wouldn’t have been other arguments equally valuable, but the court gave heavy weight to the fact that the community set this policy and has allowed us to take the most expeditious path. That’s all I wanted to say.

Paul Andersen: Okay. If you wish to speak in the room, please move to a microphone in the next two seconds.

We will close the microphones, but first we have to clear a small remote participation backlog.

Andrew Dul: Kevin Otte from Flying Penguin Technologies notes: Question: What would be the resource burden on ARIN to be able to track all these smaller allocations that could be potentially created? And, two, he notes: While I recognize John’s point yesterday that we still need to be mindful of IPv4 policy given we are still at pre-exhaustion, if we spend too much time on it, I don’t think we are doing enough to encourage IPv6 deployment.

I perceive IPv4 as being on life support at this stage, though I get the impression others don’t share that perception. I do not support the policy at this time.

Second comment is from Anthony Junk of Business Enabled Acquisition and Technology: I think the simple fact is that many of the routers which we mentioned before that can only hold 700,000 routes will not be replaced until they die. A better solution for the Internet in which we route less than /24, although not advocating /32 necessarily, is that we should not be held off in wait of a forced technology upgrade.

Christoph Blecker: Christoph Blecker from Disney Interactive: I am opposed to the policy as written. While I feel that conserving addresses, whether only a few, is good, needed stewardship, I think removing the minimum completely at this time is not operationally practical. However, I would be in support of Kevin’s suggestion of lowering the minimum requirement gradually over time and monitoring the uptake.

Paul Andersen: To address the first question, there was a question about staff resources, and I just remind that because this is only a Draft Policy, staff assessment has not been done. I don’t know, John, if you have any burning concern that you could anticipate knowing the staff concern would come.

John Curran: This doesn’t pose a lot of resource requirements, unless we end up with a huge disproportionate number of transfers as a result. So I don’t see any real resource constraint.

I’ll also note, though, this is not with respect to access the free pool which is going away; this is with respect to transfers which may continue for years to come even after the free pool is gone.

Paul Andersen: Thank you. Rear microphone.

Heather Schiller: Heather Schiller, Google Fiber. And I think that the last part of what J.C. just said is a fair part of why I disagree or do not support this policy. So the fact that dropping the minimum allocation or removing altogether the minimum allocation would potentially encourage more transfers to happen and further extend the demise of before. And so I don’t think that removing the minimum allocation helps move networks towards v6, getting away from v4; it just prolongs the problem we’re having.

Aside from that, what I came up to speak about was the perception about what size blocks providers route and ARIN’s role - ARIN’s policy on how that impacts what providers route.

So a couple of years ago we had a policy that removed the requirement to announce in aggregate in v6, and there were providers who got up at the time and said this is not a good idea, like having v6 is such large space and having sort of no boundary over what any kind of aggregation should be enforced. Until that boundary sort of naturally settles out between providers themselves, it’s going to cause chaos.

And as a result you see people trying to announce /64s, /56s, /48s. Various providers have different policies about what prefix size they accept, and you’re going to have the same sort of issue before in v4.

And I think you might have a situation where a lot of providers keep their filtering for v4 and you have this case where, as R.S. is saying, it works to some extent, it works in some places, it works better than you think it might, but there won’t be sort of a - there should be some sort of soft boundary so that - and I think having it in ARIN policy is a fair place to do that so that it’s not just complete chaos of trying to route /32s.

I disagree with that. I just do. I like Kevin’s idea of sort of like, okay, you want to relax this, start slowly to see what the impact is. But I agree. I think that just sort of pulling the rails off isn’t - can have unintended consequences for various networks that are not prepared to do that. And I just - I think that’s a significant change.

Paul Andersen: So no support. Thank you, Heather.

Last speaker, since the microphones are closed.

Mr. Pounsett, you seem to be inserting yourself after closed mics. How can we help you.

Matt Pounsett: I apologize. I’ll make it very short. Matt Pounsett, Afilias. We’ve been slowly dropping the minimum allocation for years. We’ve heard all kinds of arguments when we dropped it to a /24 about how the world was going to fall apart, and it hasn’t.

Paul Andersen: Thank you for that quickie. And last mic speaker.

Jason Schiller: Jason Schiller, Google. I wanted to come back to the question of what would happen if a small fragment was transferred inter RIR to an APNIC member. And what Owen said is true. Yes, the receiving RIR region has to have a compatible needs-based policy and they have to approve it, but it’s actually stronger than that. Because even if APNIC approved a transfer of a /32 from the ARIN region to the APNIC region, our ARIN policy would prevent this from happening, because under Section 8.4, under conditions on the recipient of the transfer, the first bullet states: The conditions on a recipient outside the ARIN region will be defined by the policies of the receiving RIR.

So if the receiving RIR is APNIC and they have a minimum for a /24, if a /32 is attempted to be transferred from the ARIN region to the APNIC region and for some reason APNIC approved it, our policy would prevent the transfer from happening.

John Curran: Actually, the way that staff interprets that is we ask that RIR to implement its policies. We specifically do not attempt to interpret their policies to the situation.

So even though it says the receiving RIR’s policies will be applicable on the recipient, it’s not our job, that’s in the response we get from APNIC. We would not apply their policies at all.

Jason Schiller: APNIC’s policy should prevent the transfer of the -

John Curran: APNIC’s policy should be the one that prevents it. We will not apply another RIR’s policy.

Jason Schiller: It should be APNIC who enforces that.

John Curran: That’s correct.

Jason Schiller: But that’s per our ARIN policy in the NRPM.

John Curran: No. APNIC applies its own policies to its own recipients.

Jason Schiller: Our policy in ARIN NRPM requires APNIC to apply their policy to a recipient of a transfer.

John Curran: Our policies require that anyone who has a compatible policy for transfers must apply their policies to their recipients. Correct. Yes.

Jason Schiller: Thank you.

Paul Andersen: I’ve taken a quick consultation with the AC chair and we will now take a quick poll. Just as a reminder, since it’s a fresh day, if you can hear the sound of my voice either in the room or online, you are free to put your hand up during this poll. Since we fixed the Internet, maybe we can get a few more hands up for this poll.

The question we would like to ask is if you are in support - I’ll ask two points - whether you are in support or not in support of the AC continuing to work on this problem statement.

I’d ask, A, are the counters in the room ready, and, B, more importantly, though, is online ready? Okay. We’re getting the thumbs up.

With those that are in support of the AC continuing to work on this problem statement, please raise your hands high. That’s great.

Those that are opposed to the AC continuing to work on this problem statement raise their hand nice and high. Indicate your support or nonsupport.

I believe they can lower their hands now. You can lower your hands and we’ll wait for the envelope, please.

Louie Lee: If I may. Louie Lee, Equinix, chair of the ASO Address Council. It sounded like there might be enough support for kind of a slow start to ask if people might be interested in having the AC work on that?

Paul Andersen: I realize there was some discussion, but I know if we dealt it as a discussion, so I think maybe it will just be safer to let the AC take in that input. And if they wish, they can obviously circulate a proposal and we could discuss that.

Steve Ryan: Online wanted the question asked again.

Paul Andersen: It has been reminded as well there is a breakout room I believe just up those - it’s upstairs; that those who are interested in potentially talking about stuff like, oh, slow start could easily go discuss that.

The envelope is coming this way. In the room, 94, on the remote, 12, for a total of 106. On the question of do you support the AC to continue to do work on the policy statement, in favor, 24; against, 10.

This input will be provided to the AC for their consideration. Thank you very much.

ARIN 2014-9: Resolve Conflict Between RSA And 8.2 Utilization Requirements

John Curran: We’ll move ahead to the next Draft Policy. We have plenty of time before the break. Next Draft Policy is ARIN Draft Policy 2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements.

It originated in January 2014. The AC shepherds are Heather Schiller and Scott Leibrand. It was presented at the Public Policy Consultation held at NANOG 60. The AC accepted it as Draft Policy in February of this year. It’s online and in your guide.

As a Draft Policy, it is posted to PPML and has been presented for community discussion. We’re trying to determine if it is fair and impartial, technically sound and supported by the community and should the AC continue work on this or get rid of it.

I’m now going to turn around and invite Heather up to do the AC presentation. Thank you.

Heather Schiller: So the problem statement for 2014-9 is a perceived conflict between the RSA and Section 8.2, where the Section 8.2 requires ARIN to work with address block holders who are doing a merger and acquisition to reclaim or return or aggregate address space that they’re not sufficiently utilized with according to policy and the RSA protects them from any type of revocation.

How do I change this? What this solves is Whois accuracy, so organizations that don’t ever complete transfers out of concern about not being able to get through the process with ARIN or that ARIN will force return of address space, and resolving the conflict that I just discussed.

So the proposed solution is to remove this entire section from 8.2 that - this entire paragraph that would have ARIN work with resource holders to return aggregate transfer reclaim resources.

And this section of 8.2 is what will stay.

And here are the PPML comments against the policy. So one of the sentiments was that it doesn’t - the 8.2 doesn’t say that ARIN will unilaterally revoke resources but they will instead work with the resource holder.

A lot of folks commented that this is a failure of the requester to go through ARIN’s process to complete a transfer and it’s not a failure on ARIN’s part, it’s just a failure of a resource holder to complete the work required of them; that it creates a loophole to acquire v4 addresses without demonstrating need. So you don’t have to go through the process of justifying your resources that are justifying the addresses that are maybe not fully utilized. And folks saying that the transferred block should be right sized to fit the infrastructure.

There were two alternative suggestions that came up frequently. One was a request to modify the RSA. But no one really said whether they wanted to modify the RSA to allow ARIN to revoke. So if the folks saying that - suggesting that might want to comment as well.

And then the other suggestion that came up several times was to remove the terms “reclaim” and “aggregate.”

And then the comments in favor. That not adopting this policy would contribute to inaccuracies in the Whois database; that improperly registered resources have a diminished value. So it’s getting these resources - or removing this policy text and allowing more transfers to complete increases the value of a resource and gives people more motivation to complete the transfer.

And another comment about whether you should have to do technical documentation in addition to just - should you have to do the technical documentation in addition to the kind of merger and acquisition business documentation that you have to provide and what’s the rationale for doing the technical documentation.

So the discussion questions that I posted to PPML were: Do you concur with the problem statement? If you support it, do you support removing the entire section or have some other suggestion? And if you’re opposed, what concerns do you have about implementing the policy.

Paul Andersen: Again, this is a Draft Policy. So staff assessment has not been done yet, but I think it would be useful - it would be useful to have, regardless, John Curran perhaps give his view.

John Curran: It was done but it was done fairly recently, so it’s not out in the package. The proposal would streamline the 8.2 transfer policy, likely result in a larger number of completed M&A transfers and more accurate information in the database.

It does not - the proposal in that way is beneficial.

Discussion

Paul Andersen: Thank you. We’ll open the microphones, both remote and in the room. Oh, and roaming microphone ones.

David Huberman: David Huberman from Microsoft. I’m the policy author. Again. Sorry. I’m going to be honest with you on a whole bunch of things. A lot of transparency here. First off, I’ve totally accidentally opened up a really big can of worms. And it wasn’t on purpose.

I come to this community over the last year as an employee - as an individual contributor in the Internet community as an employee of Microsoft, but

Paul Andersen: Could you hold off one moment.

David Huberman: No. However, I came here as having spent ten years on the front lines of ARIN, working with all of you to help you get the resources and the help you need from ARIN. This comes from my experience as a hostmaster. This comes from a direct conflict that creates a lot of problems because the RSA says ARIN cannot do this. ARIN cannot reclaim resources during a transfer for lack of use.

Policy says we must. Or we can. My intention with the policy is to resolve that conflict one way or the other. The ARIN community can ask ARIN to change the RSA, though there are very good reasons the RSA says this is not allowed, or we can remove - can you go back the last two slides, please? The bottom one. We can remove two words, “reclaim” and “aggregate,” and that would resolve the problem I actually intended to resolve.

Now, when I wrote the policy proposal, I made it a little bit broader than I probably intended. And what I actually did is I removed need basis completely from 8.2 transfers. Now, I’m going to speak in favor of that, but I want you to keep in mind that is a second step that you may want to consider asking the AC to consider separately or abandoning in this.

Paul Andersen: Dave, we’ve got to discuss the policy as it’s proposed right now. I appreciate -

David Huberman: Well, I am discussing it as it’s proposed. And as the policy proposal following proposing the policy, it was pointed out very well on the PPML that this has consequences beyond what was specifically tried to solve.

It’s important to note that John Curran provided very good statistics on transfers and transfers abandonment. In 2013, or the time period that was measured, 40 percent of all transfers submitted were abandoned. And I will submit to you that those transfers actually did happen. Company A really did buy company B. And someone from company - yeah, someone from company A did come to ARIN and say, hey, we bought this company; we’d like to move these resources into our account. And that didn’t happen. And Whois is not accurate as a result. And Whois still shows some old company name for what really is company A. And, no, I don’t think anyone wins on that.

And a lot of - having talked to customers over ten years, I can tell you one of the biggest fears they have is signing the RSA, which ARIN has worked very hard to make better, and I think ARIN’s going to take away my space, because I’m not utilizing a lot of the /16 or I’m not utilizing any of the /16 but ARIN’s going to take away my space if I go complete this transfer. And I’m not sure how anyone wins on that.

Paul Andersen: Dave, you have about 30 seconds in your three, just to warn you.

David Huberman: That’s all I really have to say. We have a high rate of abandonment in these transfers, and this policy would address that.

Paul Andersen: Thus you’re in support.

David Huberman: I’m in support.

Paul Andersen: I don’t see anyone approaching the microphone. Do we have an online, then? Could you go ahead, please.

Andrew Dul: Scott Morizot from the IRS: I do not support the policy as written. I would support the alternative to remove the terms “reclaim” and “aggregate.”

Paul Andersen: Thank you. Always good to hear from the IRS on tax day. Rear microphone.

(laughter)

Sandra Brown: Sandra Brown, IPv4 Market Group. I support the policy. IPs have a value, so they should not be reclaimed when the registry is brought up to date. Because they have a value, I think it’s important that companies are given the opportunity to monetize that value. And I think that’s part of the - making them in line with the RSA is part of that, and ARIN hasn’t reclaimed in the past. So I think that’s an important point to be made.

Paul Andersen: Thank you. So you’re in support.

Somebody on the other side of the stage wants to speak. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I’m opposed to the proposal. I think that this claim that ARIN is trying to reclaim addresses from people who are bringing them in line with reality and updating Whois is rather specious and an unfortunate misperception.

What ARIN actually does is they work with the requester to either voluntarily return the resources to transfer them to a third party or whatever other mechanism is necessary so that the requester is not ending up holding a bunch of resources they’re not using.

I think that that is good stewardship. I think that’s good administration of the address space to the benefit of the community, and I think that is exactly what ARIN should be doing.

Paul Andersen: Thank you. John Curran.

John Curran: Just to note, while characterizing correctly what we’re doing, the plain text of the policy presently has the word “reclaim” in it. And so it may be a misperception of what we do, but it is not entirely without a basis.

Paul Andersen: Front microphone.

Scott Leibrand: Scott Leibrand, ARIN AC, secondary shepherd on this proposal. I haven’t heard anyone seriously arguing that we should leave the words “reclaim” and “aggregate” in this proposal. It seems to be that the operative point of discussion is whether we should also remove the rest.

So as a shepherd, I really would like to hear more discussion from people differentiating between whether they think it’s sufficient to simply stop saying we’re going to reclaim or aggregate - work with the authors to reclaim our aggregate space over the holders, or whether it’s better, as David Huberman suggested, to strike the entire clause about working with the resource holders to transfer or voluntarily return space.

And to my mind the return stuff is not usually what happens anyway. So what we’re really asking is whether ARIN should work with 8.2 transfer recipients to encourage them to 8.3 transfer or 8.4 transfer the space they don’t need. If you think that’s beneficial, it would be worthwhile to say so; if you think that’s harmful, it would be worthwhile to say so. Or if you disagree with me and you think we shouldn’t do anything at all, call that out explicitly, too. That’s the feedback I’m looking for. Thank you.

Paul Andersen: Thank you, sir. Online comment.

Andrew Dul: Marla Azinger, Frontier Communication: Yes, support. This policy should never have existed.

Paul Andersen: Thank you. Rear microphone.

Jason Schiller: Jason Schiller, Google and NRO NC. John, your previous comment, if I interpret it correctly, seems to suggest that ARIN does not reclaim resources when there is a merger and acquisition transfer and the removal of the words “reclaim” and “aggregate” would not change ARIN operating practices; is that correct?

John Curran: That is correct, because the requirement that those resources end up under agreement ends up with a prohibition against us doing reclamation regardless of RSA or LRSA. So there is no operational practice removed. If the words “reclaim” and “aggregate” were to go away, what would be removed is just the appearance of those words.

Jason Schiller: Thank you. That’s very helpful. The other thing that I wrestle with personally is the organization that’s holding the space, either it’s legacy space and they got it a long, long time ago and the justification for getting such space was more lax, or it’s not legacy space and it was justified at the time that they got the space.

And I assume they have since fallen out of compliance. My question is: Why should ARIN treat an organization that has fallen out of utilization requirements differently if it’s being transferred as opposed to its not being transferred? And aren’t there mechanisms for ARIN to do something about - shouldn’t - if there needs to be a mechanism for ARIN to do something about an organization that’s fallen out of compliance, it should exist regardless whether or not there’s a transfer happening.

So I think that we should unbundle these two things, and I would support removing reclaim and aggregate. I might support removing the text in completion, but I think I would prefer the removal of reclaim and aggregate.

Paul Andersen: Let’s get the response to your question first.

John Curran: So recognize you’re presuming that ARIN can do something about an organization out of compliance. I’m going to point out something there. There’s parties you just referred to. ARIN, I know who they are. I know where to find them.

An organization, it’s actually not clear who the organization is in the vast majority of these cases. From ARIN’s perspective, we have a record that was issued in mid ’90s, maybe early 2000s, might be post 2000 ISP meltdown, that points to an organization. There is very little way from ARIN to get from where we are to understanding the appropriate organization and the appropriate utilization to do what you perceive.

Now, if you turn the - it’s like trying to go the wrong way through an exit door that has no handle. Now, if you turn the organization - the problem around to an organization that has resources, may have more resources than it needs and has an opportunity to transfer those resources, they will go through the effort to show that they are the appropriate registered holder. They will go through the effort of making those resources available.

So I understand theoretically how you see they’re different issues, they’re separable issues, but the reality is without an incentive for a party to do a transfer, you actually have very little meaningful way to approach it from ARIN back to organization efficient utilization.

Paul Andersen: Thank you. Online comment. Sorry. Was there any follow up from Jason? Good. Okay. Online.

Andrew Dul: Anthony Delacruz: The transfer process is a PIA ping pong game back and forth in email getting documentation that is asked for by ARIN having completed several last year, and it is not a fun experience. Anthony is from CenturyLink.

Paul Andersen: Thank you. Front microphone. Front microphone.

David Farmer: They were here first, but that’s okay.

Paul Andersen: I’m not always fair.

(laughter)

David Farmer: David Farmer, University of Minnesota, ARIN AC. Removing reclaim and aggregate is an absolute must. I support removing the sentence or paragraph, I can’t remember how much it was, as the policy states, with the proviso that something be added to - there’s a valid concern that people would sort of contractually make an 8.3 transfer look like an 8.2 transfer so that they don’t have to go through the technical validation of their need for the 8.3 transfer.

And I think that’s a valid concern. And there needs to be something in this part of the policy to try to address that. We can’t address it perfectly, and we shouldn’t try to address it perfectly, but we should at least have a small hurdle there.

Paul Andersen: Not in support, at least.

David Farmer: Support moving this forward; don’t support it as written currently.

Paul Andersen: Thank you.

Heather Schiller: Maybe staff or someone else wants to make this clarification, but 8.2 transfers, they have to justify how their resources are being used as well. So either one has that requirement.

John Curran: So under the present policy, we do ask about the resources of each organization and combined. This would remove that, striking the words; just the word “reclaim” and “aggregate” would not remove that. It would have us still do the technical discussion, but people would know it doesn’t lead to reclamation. It leads to discussion of transfer.

David Farmer: Correct. So without the reclaim that removes that looming - while not actually done, but there’s a perception that bad things will happen to you if you come to ARIN.

And so doing that technical evaluation is one form of ensuring that you don’t try to get around the 8.3 transfer by doing an 8.2 transfer.

There’s other ways to do that is all I’m trying to say. If we put one of the other ways in there to do it, I’m fine removing this text, because actually - as it was stated for actually for the organization that was on that, there’s a real amount of work there. It’s business work. But piling on the technical side, too, can be daunting.

Paul Andersen: I’d ask in the interests of time if you want to comment, you need to approach a mic. No more insertees on this one. And I’d also ask that if all future speakers be succinct and maybe be within 90 seconds, if possible.

One more remote comment, and then we’ll go to the rear microphone.

Andrew Dul: Marla Azinger from Frontier Communication: As someone who has personally handled five different network purchases and integration of those networks, this policy is problematic. The process of integration requires more address space than what is ever currently in use with a purchase.

If you are lucky, there’s more address space than is currently in use so that you can easily conduct integration requirements like a lab upgrade, rolls, and more.

Paul Andersen: Microphones are now closed. We’ll close up this queue. 90 seconds. Go ahead.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I have a question. It’s been a couple years since I’ve read the RSA; it’s not a document I - well, any contract I don’t enjoy reading, but my question for staff would be which trumps which? If the RSA says you’re not going to do something and the policy says you are going to do something, which is it?

Paul Andersen: Mr. Curran.

John Curran: ARIN respects its contractual agreements at all times.

Kevin Blumberg: How do we deal with a moot point, then, if the RSA doesn’t or is this for people that don’t have an RSA assigned or -

John Curran: When there’s a conflict, people submit a policy proposal to bring them in line. I believe that’s what this session is about.

Kevin Blumberg: No, what I’m getting at is…

Paul Andersen: Are you asking what the no op case is?

Kevin Blumberg: This a no op case.

John Curran: It is a no op case from a purpose of staff activity. It has a perception issue right now in that some people will not approach an 8.2 transfer because the word “reclaim” is clearly in the language, even though it is prohibited by the RSA and LRSA.

Paul Andersen: Given that feedback, support or nonsupport.

Kevin Blumberg: Neither right now.

Paul Andersen: Thank you. Next speaker.

Rob Seastrom: Rob Seastrom, ARIN AC, Time Warner Cable. I support this proposal but not for any of the reasons that have come up previously. There’s been a lot of attention on what ORG ID a particular resource is associated with, but that’s not the totality of the situation here. I like having working Whois. I like having working Whois that points to contact information that’s not offices that are now closed with phone numbers that don’t work and email addresses that go to domains that have expired.

Having a situation where there’s a disincentive to make that information current is bad. And, yes, there will be some leakage, some folks having address space that if they got a close look they might not be entitled to have, but I believe there’s a higher cause here for the community to make Whois better.

And I’m deeply aware of all of the troubles that it has right now without update data. Let’s please not make it worse so I support.

Heather Schiller: Stay there. I have a question. Do you support this as the text as written or do you support the removing of the reclaim and aggregate words?

Rob Seastrom: I believe that - I support removing the reclaim and aggregate because it seems to me to be a disincentive to getting correct information to the Whois.

Paul Andersen: Thank you.

Rob Seastrom: Not because I believe the organization is holding space which they might not be able to justify as a good thing.

Paul Andersen: All right. Next speaker.

Jason Schiller: Jason Schiller, Google, NRO NC. There was a comment by David Farmer that suggested that we need to tighten up 8.2 merger and acquisitions transfers to make sure that 8.3 specified transfers don’t try to rebrand themselves as 8.2.

I think that bar is already fairly high. You have to show legal documentation that there has been a purchase. You have to show that the company has been purchased from stock or there was a merger or that some division was spun out as a legal entity which was sold, either part of a stock deal or for cash.

And you also have to show that in acquiring a company or a piece of a company that you’ve also acquired the assets that are using the IP addresses, some existing networks, some customer base, some equipment. I think that bar is already fairly high.

I’m not concerned about people trying to reinvent specified transfers under a merger and acquisition.

Paul Andersen: Thank you. Next speaker.

John Springer: John Springer, Inland Telephone, ARIN AC. Part of this existing policy statement is that in the event that the resources are no longer justified, there’s four choices: return, aggregate, transfer, or reclaim. Is there any functional difference between return and reclaim?

John Curran: We use the term return, reclaim, and revoke slightly differently. Return is a voluntary process. Reclaim and revoke have to deal with us taking it back because you meet policy or us revoking for lack of payment.

So there is a difference between return, reclaim, and revoke. Presently this says reclaim, which was us be taking back for noncompliance and policy. That is not possible under the RSA or LRSA. Note it is possible for revocation of resources for people who decide to stop paying us.

John Springer: So somebody trying to go through a transfer request trying to transfer the resources to somebody else, the likelihood of them electing to voluntary return resources is obviously always an option. But perhaps unrealistic?

John Curran: We have had returns every year. I’m not sure if we had one this year yet. Yes, we had returns this year. Having looked someone in the eye pointing them at the transfer page and noting the possibility of value of the resources, we’ve had someone return, which requires us to actually make sure we get some good documentation that they know what they’re doing. But it does happen.

John Springer: During an 8.2 transfer.

John Curran: I don’t know if that was before an 8.2 or not. During. Yeah.

John Springer: Given that this is a draft, I’m in support of continuing to work on it.

Paul Andersen: Thank you, Mr. Springer.

Sandra Brown: Sandra Brown, IPv4 Marketing Group. I wanted to point out that on the PPML on April 10th Jay Moran from AOL made some very good comments that haven’t been raised yet. He supports the removal of utilization request during 8.2 transfers. He says keeping an accurate registry is vital for all of us, which I think the point has been made.

He says knowing internal corporate counsel - so he’s pointing to his own legal counsel - as well as he does, he says that his legal makes it quite painful for those of us running the technologies of the company. If legal sees anything they interpret as risk - so he’s talking about legal assessment of risk within the company - they seek to reduce risk by not allowing the utilization to be looked at. To them - and he’s speaking of his corporate counsel - to them, an external party - in this case, ARIN - seeking information about internal operations such as utilization levels of any resource relied on to do business is a potential risk either on the immediate or future basis.

So he’s saying that in trying to fulfill the requirements of ARIN, providing utilization information, it was very difficult for him to provide this information to achieve 8.2. And I think that’s a valid requirement for some of the companies that are trying to fulfill your 8.2 requirements.

So, therefore, based on Jay’s comments on the PPML, it would seem to me that several of your constituents have difficulty providing utilization information, and that may speak to the abandonment rate of 40 percent of why many of these are not fulfilled.

Paul Andersen: You’re supportive for that reason.

Sandra Brown: A second reason, and I support it, yes.

Paul Andersen: Thank you very much. With that, we’ll close discussion. Thank you very much, Heather, for the presentation.

(applause)

Paul Andersen: We’ll go to a - in consultation with the AC chair, he’s asked for a poll. I remind that this is a Draft Policy at this point, so I’ll just ask the similar question to last time, first confirming. I see counters in position.

First I’ll ask for those that are supportive of the AC working on this proposal and those against the AC continuing to work on this proposal. So for those online, please vote now. For those in the room, those who are supportive of the AC working on this problem, raise your hands nice and high. Like you’re reaching for that candy that’s outside, potentially. Can they put them down? You can put them down. Don’t leave them hanging like that.

Those opposed to the AC continuing to work on this policy, please raise your hand nice and tall. Okay. I believe you can lower. So just - did you want to do - in the interests of time, do you want to do some notes?

I see the envelope has been verified. On the matter of 2014-9, on the support of the AC to continue to work on this problem, 90 in the room, 11 remote; 101 total. 30 in favor; two against. Input will be provided to the AC.

Thank you very much. John.

John Curran: Okay. So we are now at our break, our morning break. Just a few minutes late. Because we’re starting the break late, you have to eat fast, actually, because we’re coming back right on time at 11:00 a.m.

So you have 20 minutes. Go, go, go.

ARIN 2014-2: Improving 8.4 Anti-Flip Language

John Curran: Welcome back. We’ll pick up with our policy discussion. The next one out is 2014-2, improving the anti flip language.

This originated in January of 2014 as ARIN Policy Proposal 194. The shepherds are Bill Darte and Owen DeLong. The Draft Policy was accepted by the AC in January 2014. It was presented at the Public Policy Consultation at NANOG 60. It was revised in March, and the policy is in your Discussion Guide and online.

It’s been posted to PPML and presented for community discussion. The ARIN Advisory Council needs your feedback. Is it good policy - i.e., is it fair and impartial, technically sound and supported by the community. In particular, should the AC continue to work on this or get rid of it.

I’m now going to turn it over to Bill Darte to do the presentation.

Bill Darte: Good morning. So the problem statement associated with this Draft Policy is presented slightly different here than it is in your handout. And the reason for that was that counsel thought that it was too personalized the other way, and so this represents our current thinking about what the problem statement ought to be.

Current policy prevents an organization that received block A in the previous 12 months from transferring to their own organization in another RIR a different block, block B, though it may have been issued years ago.

So the current 8.4 inter RIR transfer policy states: Within the context of the Section 8 of the NRPM in general - which is indicated here in blue - interregional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs based policies, conditions are established on the source and the recipient, which I indicate here.

And the point that is pertinent to this discussion and this Draft Policy and for your consideration here today is that which is highlighted, and I hope you can see.

It says source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 Number Resources from ARIN for the 12 months prior to the approval of a transfer request.

All right. So the point that was raised by the author of this proposal, now a draft, was that because they had received resources in the previous 12 months, they were unable to take a legacy allocation, portion of a legacy allocation and transfer it for need within their own organization to a different region. And they thought that that was an undue restriction.

And so the problem statement suggests that that ought to be overcome somehow. The further conditions that exist in current language on the recipient are not being changed. I present them here just for your review.

Similarly, you notice that there’s a minimum size transfer issue. We’ve already dealt with that this morning. This is not a portion of this particular draft but would potentially be modified in its own right through the other Draft Policy.

So the proposal discussion that went on between the shepherds and in the AC and on the mailing list suggested first that all of the language associated with 8.4 inter RIR transfer ought to be eliminated. We agreed early on that that probably wasn’t a good idea, but we might modify that language. And the first approximation of a modification to mitigate the problem statement was to allow organizations to transfer. It was an organizationally focused mitigation.

It was then suggested that perhaps it would be better - rather than being focused on the organization as a whole, would be better to restrict blocks as opposed to dealing with the organization itself.

So the current modified policy language that’s being proposed in this draft modified what was presented earlier to simply say source entities within the ARIN region would not transfer a block or portion of a block received within the past 12 months. In other words, the block or portion of the block that was in fact acquired in the last 12 months.

It’s been reviewed by legal and ARIN. The legal noted no legal issues. The staff said that it would make it easier to take resources from ARIN and immediately transfer them out of region.

I think that’s slightly misleading. What I think it really does is it suggests that you could get - within the last 12 months you could get resources from ARIN but couldn’t transfer those but could transfer other resources that you already held.

And after exhaustion you would still have to wait to transfer blocks on the 12 month cycle. So effectively this new language allows an organization to transfer resources that they hold but not have received within the last 12 months out of region.

So it is a relaxation to be sure would allow a rinse and repeat transfer of resources from an organization out of region on a 12 month basis.

So you either want to loosen the restrictions on the inter-RIR transfers, as this language does, or you don’t. If you do, then you must decide if the language that’s being proposed right now is the appropriate language or not. And, if not, maybe you could come up with something better. We’d like to hear that from you.

And if you don’t want to loosen the restrictions at all, then you would tell us through your advice and consultation on this floor and with your show of hands that we ought to just abandon this. That’s up to you. I offer no advice. So that concludes my presentation.

Discussion

Paul Andersen: Microphones are open. Please approach. And I’ll ask John to interject first.

John Curran: Could you go back to the staff slide.

Paul Andersen: Yes.

John Curran: Staff review noted that this draft language would make it easier for an organization to get resources from ARIN and immediately transfer them out of region.

The staff understanding actually says this proposal would make it easier for source entities to obtain IPv4 resources from ARIN and then immediately transfer IPv4 resources out of region.

It doesn’t say transfer them. It says transfer others.

Paul Andersen: Okay. With the microphones open, rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. This to me is actually needs to be flipped on its sides. It’s the opposite problem. The whole point for this original text in 8.4 originally was, hey, if you’re going to transfer out stuff, don’t come back to the free pool to ask for stuff. That was the point of it.

So maybe completely removing this language from 8.4 by putting in the restriction that once you go to the transfer pool, you can’t come to the free pool.

So that might be the opposite way to solve the problem, is not have the problem in the first place.

Paul Andersen: I know you’re being ironic by flipping the anti-flip language. Does that mean you’re not supportive.

Kevin Blumberg: I’m in support of working on this at this time, but not the way it’s being proposed.

Paul Andersen: Thank you. Front microphone.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. A great deal of thought, debate, discussion, argument, and several other adjectives went into the discussions of the current language that is in the NRPM, and it was pretty carefully constructed to try and address a myriad of scenarios of abuse of the transfer process to be used as a mechanism to circumvent increasingly restrictive free pool policy.

I support abandoning this proposal. I do not support the proposal as written. I think this is a really, really bad idea.

Paul Andersen: Thank you. No support. John Curran.

John Curran: Just, Owen, a question: Do you support abandoning this until the free pool has run out and working on it then, or not working on it at all?

Owen DeLong: I do not see any reason to work on it at all.

John Curran: Because abuses of the free pool are hard to happen once it’s gone.

Owen DeLong: Yes, but there’s also a potential for abuse of the transfer process even after the free pool has run out.

Paul Andersen: Thank you. Rear microphone.

Matt Pounsett: Matt Pounsett, Afilias. I’m supportive of trying to solve the problem you described, but I’m not supportive of this as written because I think it’s the wrong way to go about it.

I think it’s good to try and - it sounds like we unintentionally created a problem for people moving stuff around inside their organization, and I agree we should fix that. I think doing it this way, it creates a pipeline out of - that we were trying to block, just with a 12 month latency on it.

So I think going back to looking at language related to allowing - explicitly allowing organizations to transfer stuff within their company or to their subsidiaries is the better approach.

Paul Andersen: Okay. Thank you. Front microphone.

Scott Leibrand: Scott Leibrand, ARIN AC. In response to Kevin’s comment, I’d like to point out something that’s in 8.3 and 8.4. Page 47 of your Discussion Guide, very top right: The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval or until the exhaustion of ARIN’s IPv4 space, whichever occurs first.

So while there is a possibility of getting space from ARIN and then transferring different space out, you can’t just rinse and repeat that. There’s another restriction that prevents that.

Bill Darte: You can, but it’s on a 12 month cycle.

Scott Leibrand: We’ll likely be out of free pool by then, but, yeah.

Paul Andersen: Remote participant.

Andrew Dul: Marla Azinger from Frontier Communication: I support adding an exclusion that says ORGs can conduct inter RIR transfers to their own organization or subsidiaries with no timeframe limit. There are global companies that do their best to manage how much address space gets transferred to what RIR, but there are cases where they realize a chunk needs to be used in a different region. If it’s address space they brought in out of a transfer, they should not be limited on how they use it in their organization.

Paul Andersen: Thank you, Marla. Bill Darte wants to respond.

Bill Darte: So that was our sort of first try at this, is to say that it was okay to do this within an organization or its subsidiaries. And there was really quite a lot of backlash against the subsidiary issues saying that it’s so easy to create subsidiaries and so that’s no restriction whatsoever.

So that’s why we sort of went away from the organization and subsidiaries to a more block oriented discussion. But that doesn’t mean we couldn’t come back the other way with suitable language.

Paul Andersen: Thank you. Rear microphone, please.

Sandra Brown: Sandra Brown, IPv4 Marketing Group. Bill, can you comment on the business problem that this policy change is trying to solve? It seems to me if a company has IPv4 resources already allocated more than 12 months and these are the ones they want to transfer and they’re still getting - they’re getting IPs from ARIN for free and yet these are the ones they want to transfer, why do they want to transfer these to another region? Is this because they’re using them in the other region?

I don’t understand why there’s this distinction between these two sets of IPs. Who proposed this and what’s the business reason we’re trying to solve here before we talk about whether or not this is a good idea. Like why aren’t you getting a new block of IPs and talking about transferring the new IPs? What are these IPs being used for that we’re talking about transferring.

Bill Darte: So that was part of the early discussion, is in some of the objection to this was, you know, if they had resources to move, then why were they requesting new resources within the ARIN region, within the last 12 months. And that was a question.

The answer to that is I don’t know. Go ahead.

Kevin Blumberg: I think I can answer Sandra’s question. If you are using a net block that is currently registered in the ARIN region in some of the other regions actively, you will have problems with routing, with filtering, et cetera.

By that IP net block not being registered in the correct RIR’s registry, you’ll have operational issues. That’s the reason why they would want to do this.

Sandra Brown: Trying to solve an operational problem.

Paul Andersen: We can’t hear you if you’re not on microphone, so can you repeat the comment.

Kevin Blumberg: The question is are we trying to solve an operational problem? To a large degree, yes, this is operational, but this is the way the other RIRs operate. So it’s working within their parameters to be able to use that space.

Bill Darte: I’ve heard this conversation before. I’ve also heard people state, rather than emphatically, that it really isn’t a problem to simply announce ARIN resources in other parts of the world and it works out just fine.

So if anybody can speak to that issue, that would be enlightening.

Paul Andersen: That would be useful. We’ll go to - first I’d recommend if you want to comment approach the mic because we’ll close them soon.

Dan Alexander, remote participant after that.

Sorry, Milton. My apologies. Milton, go ahead.

Milton Mueller: I’m masquerading as Dan. Yes, this is Milton. I have something simple to say. Just as a matter of principle, I’m in favor of removing as many restrictions as possible on moving increasingly scarce v4 addresses where they’re not needed to where they are needed.

And I haven’t heard any harms - I’ve heard some concerns about speculation or opening up channels that you were trying to close, but I haven’t really heard any discussion of the harms that would actually be caused by this minimal kind of liberalization of the transfer process.

So I would just - keep your eye on the ball. It’s about increasingly scarce resources, getting them where they’re most needed and removing impediments to that that are unnecessary.

Paul Andersen: Thank you, Milton. Remote participant.

Andrew Dul: Timothy Michael Huffman from Business Only Broadband notes that’s he’s been hearing that we’ll be out of the free pool in 12 months for the past three years.

Paul Andersen: Does he have a support or nonsupport for this policy?

Andrew Dul: Sorry, that was his comment.

Paul Andersen: Understood. Rear microphone, please.

Jason Schiller: Jason Schiller, Google. I would support in concept loosening the transfer slightly to allow transfers out of region within your own corporate reorganization.

But I wanted to speak specifically to what I believe the case is here, and that is that there is a global organization that’s holding legacy space that has growth both inside the ARIN region and outside of the ARIN region.

Let’s say APNIC, for example. And APNIC, their Asian division can’t go to APNIC and get more addresses because APNIC is out. Their US division can go to ARIN and get more addresses for usage within the ARIN region.

I think what they would like to do is be able to take some of their unused legacy resources and transfer them to their Asian divisions so they can use them and put them into service, which will then make their US division out and qualify to get address space from ARIN.

So that is kind of my answer to Sandra Brown about one potential case of what could cause this.

Paul Andersen: I believe you said at least on the first point above that you’re supportive, correct? Loosening the restriction.

Jason Schiller: Loosening the restriction to be used specifically in your own organization.

Paul Andersen: Thank you for the clarification. Thank you. Next speaker.

Martin Hannigan: Martin Hannigan. I’m the director of network and data center architecture at Akamai Technologies. I want to refute what Kevin stated with respect to problems with routing addresses around the world.

IP numbers are globally routable. It just kind of works. For example, if you want to resolve whitehouse.gov in any part of the world, you’re more than likely to find that prefix local and properly register it in an IRR or a database like the RIPE DB and not transfer it.

With respect to Milton’s comment, I completely agree with Milton. We need to be able to transfer the addresses where we need them without restriction. It’s more efficient. It’s more cost efficient. There should be no restriction, at least internally for me, if I need addresses in, say, Africa, to be able to transfer those addresses there if the reciprocal policies are in place to save myself time, energy, money.

In some regions you have to establish a local presence to be able to become a member of the IRR, et cetera, and I don’t see that there’s any need for me to have to do that if I have a presence here in the ARIN region, I’m a member, I follow the policies, and I want to efficiently use my address space.

I support this proposal, thank you.

Paul Andersen: So you’re supportive of the first part and you think this is the appropriate way to do it.

Martin Hannigan: Yep.

Paul Andersen: Thank you. Next speaker.

David Huberman: David Huberman from Microsoft and I’m the policy author. The reason I proposed this is what was echoed in Marla’s comments. When an organization that runs a global backbone, a single AS across multiple continents, they’ll use space wherever it’s needed when it’s needed. And there’s a good example where an organization has space that is being used in a different region of ARIN, outside of ARIN, and wants to move it to that RIR.

And sometimes it’s that dirty word: geolocation. It is really - that’s a difficult problem that everyone in this room I’m sure has come across. One of the ways to mitigate some of the stuff that happens in the geolocation world is especially for End-userswho can’t SWIP is to move space to the RIR where it’s actually being used, and the current restrictions actually forbid that.

The problem is the current restrictions aren’t real, because all you do is you take the space, you do an 8.2 transfer in ARIN, and then you just move them as an 8.4 because that company is not - that new ORG ID is not subject to any of these anti-flip restrictions.

So the current language isn’t operable in those cases. And this is an attempt to try and fix it so that global networks cannot have restrictions to move space between RIRs for strictly operational reasons.

Paul Andersen: Obviously in support. Dr. Cerf.

Vint Cerf: This is not to speak in any direction with regard to this proposal, it’s just to make an observation and maybe ask a question. What David points out strikes me as being a really odd and ironic outcome. When the design of the system was put together, it was carefully done to avoid any geographic characterization of the network identifiers because we assumed some would be global and they would span all kinds of boundaries, and of course country boundaries change, too.

Now, here we are with the geolocation thing, it’s focusing us back into the bizarre situation. Otherwise, there’s no reason to transfer something to another region. You can still use the addresses no matter who allocated them to you, otherwise this network wouldn’t work at all.

But I think David’s point about geolocation is sort of a definitive annoying burr under the saddle. And whoever the jerk was that decided to do geolocation - and I’m afraid my company may have been involved in this, too -

(laughter)

Vint Cerf: - really messed it up.

Paul Andersen: Okay. We’ll go to the rear microphone first.

Sandy Murphy: Sandy Murphy, PARSONS. This is perhaps just piling on some of the previous comments, but I’ve noted a distinction between several comments having to do with trying to distinguish where an address is registered and where it is used. Some comments have said where it’s used has an operational impact, where it’s registered has an operational impact on where you use it.

I thank David for his example of the geolocation. Milton’s comments about we need to be able to transfer things to where they’re needed, well, other RIRs don’t need more registrations. Transferring a registration from ARIN to another region is not an impact on need, it’s the use.

Clarifying the question as to whether or not where an address is registered has an impact on the ability to use the address in the routing system should impact this discussion.

Paul Andersen: Thank you. I’m going to close the microphones after this remote comment. So if you wish to discuss this topic, please approach a mic now.

Andrew Dul: From Timothy Michael Huffman, earlier he wrote in that he does not support the policy at this time.

Marla Azinger writes routing addresses and other registries work out just fine. However, it requires more coordination with other organizations to ensure reachability is reliable. Additionally, everyone wants Whois to be reflective of where the IPs are used, that would help.

Now I’m going to put my own hat on and make a statement.

Andrew Dul, ARIN AC. I think it’s interesting that we are talking about records from an operational nature, and in a previous discussion we were talking about how ARIN shouldn’t necessarily be involved in setting operational precedence for how addresses are used on the network and that it should just be registered and routing should just work. Now we’re talking about putting records in the ARIN database so that things work.

So rather than trying to move addresses to another region, we should be working on, I think, updating the database capabilities in the ARIN region, if they are deficient in any way, to make notations where addresses are being used in other regions regardless of where they are actually registered or what region.

So if there are restrictions that are not palatable to geolocation such that organizations should be making additional records in the ARIN database, then we should fix that problem by allowing them to put additional records in the ARIN database.

Paul Andersen: Thank you. Nice to slide yourself in there. Tricky move there.

Next speaker at the rear microphone.

Martin Hannigan: Martin Hannigan, still the Director of Networks and Data Center Architecture…

Paul Andersen: So your previous comments weren’t held against you.

Martin Hannigan: Yeah.

Paul Andersen: Good to know.

Martin Hannigan: I’d like to refute Mr. Huberman’s assertion with respect to geolocation being a concern. I disagree. Whois, SWIP, all those things are just a small piece of how a geolocation of an IP address is actually established. It’s much like NTP where there are multiple inputs to actually make the determination. It can be a problem, but it’s not necessarily a problem.

Again, I’d like to reiterate Milton’s comments: We should be able to use the addresses where we need them.

This is about money and cost, and that’s it. Thank you.

Paul Andersen: Still the director and still support.

Martin Hannigan: Still support.

Paul Andersen: Thank you. Next speaker.

Jason Schiller: Jason Schiller, Google. I wanted to point out that there are other considerations other than technical routing reasons for why you would want a particular block under a particular RIR.

For example, you may want your Asian division to pay for the addresses that they’re using, and the easiest way to do that is for your ORG ID with APNIC which represents your Asian division to hold those resources and for them to pay the bills for it.

This has tax implications. This has potentially internal budget implications. You might want to draw the money for the resources from a particular bucket that represents your American division versus your Japanese division.

You may prefer to deal with APNIC when it comes to reporting utilization of your Japanese customers, because they understand how street addresses are formatted in Japan, and it’s just easier to talk to somebody who understands those issues that’s local, that’s in country, that speaks the language, that’s on the appropriate time zone.

So there are other factors besides how the block is routed that may make it more desirable to have a particular segment of your address space being serviced by a particular RIR. So I wanted people to be cognizant of that.

Paul Andersen: Thank you. Rear microphone.

Sandra Brown: Sandra Brown, IPv4 Marketing Group. I want to say I’m in favor of working on the policy having heard the business justification. I agree with Milton in terms of reducing the complexity of the ARIN manual. I think that’s a wonderful idea. And I think this is going in the right direction in terms of simplifying the process.

I wanted to add one comment that I don’t think it changes this policy, but I think it’s good to put it on the record. I find that when new allocations are made - in other words, when I had my right hand up last time it was at the microphone - when companies request new allocations from ARIN, I see some simplification of process for larger companies. In other words, larger companies have an easier time getting IPs from ARIN. Smaller companies have a more difficult time.

And same will be true for these transfers to other RIRs. In other words, the big companies are going to be the ones that have the presence in the other RIRs and will be able to do these transfers.

And I’m fine with that, but I do think we in the ARIN region need to address this problem that small businesses have in getting IPs from ARIN. I don’t know what the solution is to that. But there is a couple small businesses in this room today where if they want to get a /22 or a /23 from ARIN, they have a much harder time and they’re told to go elsewhere to the transfer market, whatever, to get a small block.

Separate problem but also needs to be addressed, and it will be the big companies that benefit from this particular policy. Thank you.

Paul Andersen: Thank you. So in support. Thank you. Last comment goes to Mr. Darte.

Bill Darte: So this is a Draft Policy. So presuming that through a show of hands you would suggest that we continue to work on this as the AC, I would just encourage you to forward to the PPML or to me directly or whatever your particular comments so that we can make sure to include them all in our consideration. Thanks.

Paul Andersen: Thank you, Bill. Thank you for your presentation. Okay. It’s that time.

The AC chair has asked that we ask the question. Again, I would note this is a Draft Policy, so they’re just looking for whether or not there’s interest to continue working on this policy proposal.

So seeing the counters are in place, I would ask those online to submit their support now. And for those in the room, those in favor of the AC continuing to work on this proposal, please raise your hand high.

I believe they can lower their hand. For those that are not in favor of the AC continuing to work on this proposal, please raise your hand high. Thank you. You can lower them. We’ll just wait for the results.

Can I get a confirmation from the chat room. Can we get votes from the chat room?

On the matter of 2014-2, Anti-flip language, on the matter of in favor of the AC continuing to work on this proposal, with 90 in the room, 13 remote, 103 total, the record was 36 in favor and two against.

And we’ll note that we had one vote brought out in favor out of band, so it would be 37 in favor and two against.

So we’ll pass that on to the AC for their consideration. Thank you, John.

ARIN 2014-1: Out Of Region Use

John Curran: Okay. Very good. We’re going to continue. We’re pretty good on time. So the next item is the out of region use discussion, Draft Policy 2014-1.

This was originated in December of 2013. The shepherds are Milton Mueller, Stacy Hughes, and Bill Darte. The AC accepted it as Draft Policy in January. It was presented at NANOG 60 in the Public Policy consultation. It was revised in March of 2014. You have the proposal text online and in your Discussion Guide.

It is also a work in progress. The Advisory Council needs your feedback as to whether or not it’s good number policy. Is it fair and impartial? Is it technically sound? Is it supported by the community? In particular, should the AC continue work on this or get rid of it.

I’m now going to turn around and have Milton Mueller come up and do the AC presentation.

Milton Mueller: All right, everybody. This is the continuing saga - where do I point this at? There you go. I point it at John.

This has been the continuing saga of out of region use. One of the problem statement notes that current policy clearly forbids nor clearly permits out of region use, and we went through a couple of amended attempts to restrict “out of region use,” which we’re very far from obtaining consensus. And so now the drafter of this policy has proposed to clearly permit it. But recognize some of the operational issues that would be caused by this.

So this would create a new section X - did I get the problem statement up there?

Seems to go on by itself, doesn’t it? So that’s the policy statement. There’s really - that’s the problem statement. There’s actually two elements to it. We’re going to clear up whether it’s permitted or not, and we’re going to try to address some of the practical issues that have to be dealt with if we do permit it.

What does it do? It creates a new section X that explicitly permits and defines out of region use. Resources are considered to be used outside the region if the user or customer service address or the technical infrastructure address such as a PoP, data center, or other similar location are outside the ARIN region.

There is additional language requiring the applicant to demonstrate that resources from ARIN will not duplicate underutilized resources from other RIRs in the region they’re now trying to use it in.

And there’s other language restricting the utilization rate considered to ARIN registered resources. There are some very specific definitions in here. I’ll just refer you to the policy document for that in case you want to discuss any of them.

These definitions have been modified in response to comments at the NANOG meeting in Atlanta. And so here’s the discussion points, as I understand them. What I’ve seen and others have confirmed on the AC is that we see general support for allowing out of region use for existing ARIN holders.

The staff asked a question: Is the intent to allow transnational companies based in the ARIN region to get all the resources from ARIN, or is the intent to allow any organization anywhere to get resources from ARIN.

And I think we’ve noticed when you try to distinguish between those two, it’s difficult to allow the former without allowing the latter.

How difficult will it be to do this additional coordination with the other RIRs, and have we really fully taken into account the impact of this policy on transfers.

So open it up to discussion.

Discussion

Paul Andersen: We’ll open up the microphones now, please. If you would like to discuss, please approach a microphone.

Vint Cerf: I decided - it’s Vint Cerf from Google. I have a question about this. I do not understand a need to move an address or get an address from a different region. If you’re running a network and it covers multiple regions and you’re the operator of it, it’s supposed to work.

So I don’t understand an argument that says if you’re a multinational operation, you have to get resources from multiple regions in order to run a network. So I’m really puzzled by at least some of the apparent worrying that you would have to go get an address from some other region in order to run a router in that region when it’s part of one network. So help me with that.

Paul Andersen: John.

Milton Mueller: I take that as support for the proposal.

John Curran: Nicely done. Currently the NRPM indicates that ARIN serves as the registry for this service region. As such, our practice is that we, when people seek address resources, expect to see use in the region, and we ask them to justify their utilization based on - generally based on equipment in the region. Though, some people, because of virtualization, end up going to customers instead.

As noted in the past policy experience report in this matter, we are quite willing to change the practice if the community indicates that’s desirable. But to date we have sought use of the resources in the region and have sought that usage as justification when doing the assignment.

Paul Andersen: Thank you, John. Front microphone. Did you want to comment on that as well?

Milton Mueller: I think the general issue we have ended up discussing, and I think Vint put the point extremely well, is that it’s this tension between the need for globally integrated addressing space versus the regional character of the RIRs and their policy making process. And I think this proposal is an attempt to resolve that tension in a particular way.

Paul Andersen: Milton, front microphone. Front microphone.

Gaurab Upadhaya: This is Gaurab from Limelight Networks. I think Vint put this very well. I support this. I think the real question here - this was discussed in previous policy - that the routing system doesn’t care where the address has been assigned from. So today there are a lot of address space that might be assigned by a RIR that is used in another address or different service region.

And it comes back to what Geoff Huston says. As an RIR, all we have is the database, and that database better be accurate. And if we restrict this artificially by saying that you’ll not as address space from ARIN in the APNIC region, it will still happen but the database will then be incorrect.

And I prefer that the database be correct, that that’s what we really have. So I’ll support this proposal.

Paul Andersen: Thank you. John Curran.

John Curran: Just need to clarify one thing. ARIN, of course, has no comment regarding how you use issued address space. It is only the question of what we use for the basis of issuing that space.

And presently, as we’re dedicated to serving this region, we use your use as predicted in this region as that justification.

So I want to be clear. This isn’t a question about I don’t believe there’s any policy requiring that you use number resources a specific way; it’s a question of how you have access to the free pool in the ARIN region presently. It’s an access to the free pool question.

Paul Andersen: Go ahead quickly.

Gaurab Upadhaya: I agree with that. The way I’m looking at this policy is this will be applicable when you’ll probably have run out by the time this goes through the policy process. That’s why it becomes more important you don’t put any artificial constraint to make sure the database is correct.

And as you said yesterday, we can’t really say let’s not do this because in six months it might be relevant, we still need to do it. But I still stand by and say that.

When the free pool is exhausted, then this becomes a lot more important because then people will move addresses around. And that’s the point when you want the database to be accurate and be valuable.

Paul Andersen: Thank you. John Sweeting.

John Sweeting: Yes, so this is from Marla. She’s having problems getting into the jabber again. So Marla says: Yes, support, but can you explain why it’s thought that X.3 through X.5 are needed. I understand what they say; I just don’t see what value it brings to the policy.

Paul Andersen: Milton, did you want to address that?

Milton Mueller: My understanding of the author’s intent was that - X.3 and X.5 are basically defining forms of external or out of region use that don’t count as out of region use. And it’s doing this so that these people don’t have to worry about getting charged extra fees, should the ARIN Board choose to impose extra fees on these kind of out of region use.

Milton Mueller: Or number one, right. So that they don’t have to deal with these higher levels of authorization and so on. Well, the same level of authorization, but they don’t have to engage independent external entities to verify them. They don’t have to report their utilization status to any other RIR.

David Farmer: If you just have a little bit in the other RIR - David Farmer, author, guilty of too many words. The intent there is if you just have a little bit of use, you shouldn’t have to go and report all your other stuff just because you happen to use a few over there.

Paul Andersen: Thank you. Rear microphone.

Martin Hannigan: Marty Hannigan, Akamai Technologies. I generally support this, although it’s overcomplicated. With respect to the documentation requirements, I think we need some more information related to that.

I think it’s fair to expect that the RIR is the registration source - i.e., that’s where the prefixes come from and that I hold them - and that it’s properly reflected in the Whois. With respect to the destination, I already registered my prefixes in the RIR, so the destination is already documented. If I have to document them elsewhere and through some additionally onerous system, it creates expense and inefficiencies for me.

I do support documenting them, but I do think we need to do a little bit more work on how we’re going to document the use.

Paul Andersen: Thank you. So support, but some clarification required.

Next.

Matt Pounsett: Matt Pounsett, Afilias. I’m supportive of doing this work, but I haven’t decided yet whether I’m in support of this as written. I think it feels a little overcomplicated, and I’m trying to work some of that out still.

But we definitely need something along these lines, though. In the past - maybe it’s a little different now, but in the past ARIN has been inconsistent on how this is applied.

We run several networks around the world all using ARIN space, until last year, when expanding one in the RIPE region, we were told no. And so now we’re a RIPE LIR as well as an end-userhere.

And, yeah, that makes our work unnecessarily complicated. And so I think it’s good that we’re working on something like this.

Paul Andersen: Thank you.

Bill Woodcock: Bill Woodcock, PCH. As someone who, like Matt, operates network in all five regions, and Vint, I really don’t want to have to be sitting around at meetings like this ten times a year in order to make sure that things don’t go wrong.

Twice a year is perfectly adequate. I don’t like the idea of doing it with a lot of extra words. This seems like - if we’re imposing extra requirements, it seems like perhaps the requirements can be removed rather than counterbalanced with additional verbiage.

But, so, yeah, like Matt, I’m very much in support of the notion of this and hope it can be done cleanly and maybe with a paring knife rather than a wheelbarrow.

Milton Mueller: I will say, I think the most complicated thing in this proposal has to do with coordinating with other RIRs, and I think there’s been pretty strong support for the idea that you don’t want duplicate usage - or the same usage being used to get duplicate resources from multiple RIRs.

So that’s one element of complication. And also the incidental use may seem complicated, but it’s pretty sensible in terms of its implementation.

Now, parsimoniousness of David’s language maybe you could complain about, but I won’t go into that.

Paul Andersen: Okay. Just a reminder. After our next speaker, we’re going to close the microphone, so now would be the time to approach either of the two microphones - in fact, there are two. So line up at the back of the room.

Next speaker, please.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. This would apply to anything plus one, whether it be a transfer or anything new basically, because the moment you do justification, this would play in.

So I am in support of this. I am in support of a lot more than a paring knife, more like a machete. This has to be completely simplified.

But my actual fundamental question is: Is this a global policy? Can ARIN basically say these things - i.e., you can use our IPs anywhere in the world, no problem - and is that right for us to be making those choices, or should this be a global policy where all the RIRs say the same thing?

Paul Andersen: John, I think that’s paging you.

John Curran: Actually, amazingly, I can dodge that question.

(laughter)

John Curran: So I will say that there are global policies and there are globally coordinated policies. Global policies are policies that apply to the function of the IANA in issuing address space. So it’s not a global policy. Is it a globally coordinated policy? Hmm. Globally coordinated policies is when all the RIRs end up implementing a policy that look similar and have similar characteristics so the world works the same way. And whether it should be that or not is really a question that like the ASO tends to deal with.

Luckily we have several ASO members in the room. I see one in line, one beside you, and I know there’s one more hiding around here somewhere.

If you ask them, they’ll give you a view on whether it should be a globally coordinated policy.

Paul Andersen: So maybe an ASO approach the microphone and comment on said question. There’s the one in line. You get to queue jump, but you get to answer the question at the same time.

Don’t fight about it. Louie, it’s you. I picked.

Louie Lee: If the community feels that it’s useful for it to be globally coordinated. It’s one routing system, really. Why shouldn’t it be - we’ll let the community tell us how we should shepherd this.

Paul Andersen: Milton would like to address that, I believe.

Milton Mueller: Not like I can speak for the ASO or the NRO, but just from the standpoint of a policy person, for example, using the precedent of trade policy, you can have a globally coordinated trade policy that is agreed through the WTO, or an individual country can say I’m just opening my markets. I don’t care what the rest of you do.

And that has global effects and is in effect a global policy in that sense, but that country can do that. If they agree to do that, it happens.

So I view this as more like that case. We’re deciding as ARIN that we want to do this, we can do this. The other RIRs can adjust to it. I don’t think you could argue that it does them harm, but it may do good for this region.

And particularly, since there are transnational entities operating in this region and many other regions, I think it has an overall effect. Even though it can be initiated unilaterally, it has the effect of a global impact.

Paul Andersen: Thank you, Milton.

Kevin Blumberg: Just to comment on

Paul Andersen: I was going to say, Kevin, we’ve already closed the mics. John first and then you, but only for a response.

John Curran: Just to follow up on what Milton said, it’s also true that globally coordinated policies often start as a policy adopted in one region and other regions look at that and use that as a basis for developing theirs.

Paul Andersen: Kevin quickly.

Kevin Blumberg: Sorry, just to say

Paul Andersen: Could you get close to the mic? At least I can’t hear you.

Kevin Blumberg: A better way of putting this in terms of what I was asking for was if the other regions are unhappy with this policy, we could have a backlash in reciprocal policy that we don’t like. So maybe we should ask the other regions before we do something like this.

Paul Andersen: Thank you for the comment.

David Conrad: David Conrad. Affiliation is confusing; currently working on a contract with the FBI, among others, but in no way representing any aspect of the US government in any possible way, if that’s enough of a disclaimer.

So two things. One, I would actually argue with John that ARIN does care because I actually had pushback from the hostmasters when we did, when I was on a contract with Cavalaire, request address space. The address space that - ARIN address space that we were using outside of ARIN was disallowed in the computation of utilization.

So ARIN does care about how the address space is being used. If you want to respond to that.

John Curran: ARIN does implement the current policy, and it does mean that, for purposes of calculation of use, for getting access to the free pool, we do consider that.

But we’re happy to use any other calculation. We don’t care about what the specific policy is, as long as the community is clear what they want that policy to be.

David Conrad: And the other point I wanted to make was that while I have great sympathy for the idea that address space is globally used and works anywhere on the Internet, pragmatically speaking, there is this problem that the two - out of the three remaining RIRs, two of those RIRs do have policies that disallow the use of their address space outside of their region.

The implication of this policy, if it does move forward, it will make address space that much more appealing to everyone on the planet, encouraging people to likely come to ARIN to consume the existing free pool that was dedicated for North American use to be used pretty much anywhere, because the policy would then allow that without question.

Paul Andersen: Not in support?

David Conrad: Not in support but would support continued work on the concept. I think this is an issue that needs to be clarified. I’m not entirely happy with either direction. Haven’t figured out which one I hate less.

Paul Andersen: Good to know. Thank you. Next speaker.

Jason Schiller: Jason Schiller, Google. I wanted to speak exclusively to the question of ensuring people don’t use a single host to qualify for addressing in more than one region. And that seems to be a concern of this policy.

If that truly is one of the concerns, I think you can simplify a lot of things by simply stating you must report the utilization of all resources held in all regions full stop so that we can ensure that you’re not counting utilization in more than one region. Because you could certainly have a case where an organization is using ARIN issued resources exclusively in the ARIN region but also using IP addresses from another region in the ARIN service region.

So I would argue throw out all of this about whether it’s used in region or out of region and just simply request that they report all utilization of all space across all RIRs and make it clear the reason why you want this is to make sure you don’t have duplication of counting of things for both in this region and another region. I think that would be much simpler.

The carve out for incidental use seems to be unfair to larger organizations, because if you’re a very small organization, a /21 is probably all the addressing you’re going to need. So that kind of gives you a free ride from this policy.

I’m not sure I care that much about it. But I think if you’re going to do a carve out, you want it to be more fair. It should be a percentage of resources held.

Paul Andersen: Thank you for that comment. Next and last speaker at the mic.

Sandra Brown: Sandra Brown, IPv4 Marketing Group. I wanted to make some comments what we’re seeing in the marketplace, and I want to say this is so complex. Holy cow. I’m not even sure what it’s really saying and what business problem we’re trying to solve here.

It seems to me we’re trying to solve a business problem very similar to the last policy we discussed, which is to allow a business to use IPs in another RIR. And the condition seems to be over on the last page that says provided that there’s at least one instance, one IP, one something, used within the ARIN region.

Okay. So it seems to be the business problem we’re trying to solve is to allow IPs that are allocated within ARIN region to be used in another RIR.

So company needs that. So we have companies come to us regularly and say: Okay, I want to expand into North America. I’m located in Europe. What do I do?

And we say something like: Well, first you have to set up a presence, form a company in the ARIN region. Then you go to ARIN. You request your /22, your /20, whatever it is you need, and you get your IPs from ARIN. But first you have to create a company.

So that’s the situation where you create - you get IPs in ARIN region and use them here when you’re from somewhere else.

This would also address the situation where you go the other way. So you’re already in North America. You’re a North American company and you want to expand, say, into Europe or into Asia. You already have IPs in the ARIN region. You get more IPs in the ARIN region and you want to use them somewhere else to expand your business there.

So I assume those are the two situations we’re trying to solve here. So I’m looking at this and I’m saying, okay, how can we simplify this, because I can hardly read through the three plus pages of what this means.

And I combine it with the complexity of the previous policy, and I say: Why don’t we just allow - if we’re trying to solve the second problem, why don’t we just allow companies with a head office in North America to get IPs and then to immediately transfer them to other regions. And that wasn’t the solution to the last policy where we talked about, okay, they’ve already got IPs that are in use and I had this hand and they get another allocation.

But it seems to me we’re trying to solve a whole bunch of problems that are very similar and interrelated, and we’re adding all this text and complexity into the manual, the PPML. And I agree with trying to solve the problems, but it seems to me we’ve already got - we’ve already got a PPML that’s much more complex than APNIC has or than RIPE has, and we’re adding text to solve all these problems. And to echo what Mr. Huberman said yesterday, these problems are going to be gone a year from now.

To say what Mr. Curran said, well, I thought these problems would be over in 2011, and here I am in 2014 and I still have the same problem. So, yeah, they might be here three years from now, but we’re trying to solve problems that may be gone a year from now, and we’re just adding complexity to solve them.

I really think we need to come back to the fundamental what are we trying to solve here and is there one solution that will solve all these little nitty things.

And I know you can’t conquer them all at one time because no one can agree, but we’re adding complexity here. We’ve really got to ask ourselves: What are we trying to solve here.

Paul Andersen: Thank you. Milton, any last words before we go to a poll?

Milton Mueller: In terms of the complexity, I think the initial explanation, the under anything else appropriately labeled is very long. I don’t think the proposal itself is that complicated. So don’t be misled by the large two pages of text. It really takes up one page.

Paul Andersen: Okay. Seeing - I think our counters are in place. Good, good, and good. All right.

On the matter of 2014 1, I’m going to - thank you to Milton for the presentation, everybody. Try and keep it moving as lunch is obviously next.

So the question we will ask is, as this is a Draft Policy, whether or not the community would like the AC to continue work on this Draft Policy.

So I’d ask those in the chat room to either say whether they support or do not support that. And for those in the room, if you support the AC continuing to work on policy 2014-1, raise your hands nice and high. You can lower. Seeing everyone’s lowered now.

And those that are opposed to the AC continuing to work on this policy, please raise their hand nice and high. Trying to work off the calories you’re about to eat. There’s one over there. Okay. Thank you.

Just as a reminder as we wait for the result to come in, if you would like to discuss this further with Milton, he’ll be sitting at a table at lunch where you can discuss this informally. And, in fact, I’d remind you that you can talk about any of the Draft Policies. There’s I believe a table for almost all of them, John, or John.

If you are here in person, you haven’t quite got enough, you can feel free to seek that table out at lunch.

Thank you, sir. So the last one of the morning, 2014-1: Out of Region Use. Still, I believe, about the same numbers. In the room, 91, on the remote, 11, for a total of 102. Those in favor of continuing, 28; those against, one.

That feedback will be provided to the AC for their consideration. John, over to you.

John Curran: Thank you. Okay. We are now breaking for lunch. Lunch will run until 12:30 - sorry, 1:30. Yeah, 1:30. We’ll give you a little time. And then we’ll resume with the three more Draft Policies when we get back. So I’ll see everyone back here.

Folks, take your belongings, because the room is not locked, and I’ll see everyone back here at 1:30.

John Curran: If people can come in and get settled, we’ll get started. Okay. So we’re going to get started with our afternoon policy block. This includes - the first one is ARIN - we have some announcements.

So, first, if you’re going to be around tonight and looking for someone to have dinner with, there’s a Dine Around Town program, and you can sign up and you can find each other. There’s still time to sign up if you’re still looking, because we don’t have an organized social tonight. Go out to the registration group and sign up and be able to meet your group in the lobby. Sometimes people want to be able to meet other people. That’s one way to do it out at the registration desk.

We have coming up this afternoon the Internet Number Resource Status Report. We have the Internet Governance Update and an Open Microphone session.

We also have a number of policy discussions including the alignment of 8.3 needs requirements, the anti-hijack policy, and the improved registry accuracy proposal.

So at the head table I have David Farmer; Kevin; John Sweeting; founder of the Internet, Vint Cerf; and Cathy.

ARIN 2014-8: Alignment Of 8.3 Needs Requirements To Reality Of Business

John Curran: We’ll start right in on the Alignment of 8.3 Needs Requirements.

This is Policy Proposal 2014-8. Origin is ARIN Proposal 193 in January. The AC shepherds are Kevin Blumberg and Milton Mueller. It was presented at the Public Policy Consultation at NANOG 60. The AC accepted it as Draft Policy in February of 2014. The policy is online and in your text.

It is a work in progress. And, as such, it is posted to PPML and provided to the community for discussion. The AC council, the Advisory Council, is looking for your feedback: Is this good number policy? Does it facilitate fair and impartial Number Resource management? Is it technically sound? Is it supported by the community? Should the AC continue work on it or should they get rid of it.

I am now going to have Kevin come up and give the AC presentation.

Kevin Blumberg: Good afternoon, everybody. So the basic problem statement and the most important aspect to this policy is in 8.3 transfers to remove “under current ARIN policies.”

I’m actually going to take to you the next slide and we can really dive into this.

Just a second. So here is the current policy statement as a draft that is before the community. What we’ve actually done is, based on staff and legal review, made one alteration, and it actually simplifies everything. So this is the suggested draft.

What is in bold is the things that are changing. So the recipient must demonstrate “the” need, to, the recipient must demonstrate “their” need. And IP address resources “under current ARIN policies,” removing out “under current ARIN policies,” changing “IP addresses” to “Number Resources.” The impact of that, when we go from IP addresses, obviously, is to allow for ASNs. And, more importantly, “under current ARIN policies,” by removing that really simplifies and makes it easier to deal with 8.3 transfers.

The impact of that, when we go from IP addresses, obviously, is to allow for ASNs. And, more importantly, “under current ARIN policies,” by removing that really simplifies and makes it easier to deal with 8.3 transfers.

When we were discussing with the community this suggested draft, one of the issues that came up was the fact that you could have all sorts of fun - and fun in not a good way - if you took out “under current ARIN policies,” because the 24 months would disappear, a whole bunch of stuff would disappear, a whole bunch of things could happen.

And what was added was the transferred blocks plus the amount of free addresses currently registered to the organization must together not be larger than the demonstrated need.

So while we’re removing out “under current ARIN policies,” we are adding in to this policy a limit to basically say, hey, as long as everything that you have together is fitting under demonstrated need, then it’s okay.

And the last thing, obviously, is we’ve added a separate sentence that you still need to sign an RSA.

So the first question is: Will this help new entrants? As an example, right now, if you’re a new entrant, you have to have space to be able to get space from ARIN.

This removes that requirement. There is no - we don’t have any more under ARIN policies. You can go, you can say my need for the next 24 months is going to be this or 12 months is going to be that. You don’t need to worry about many of the other policies that are in play to be able to get the space that you need in the transfer market.

So my questions for you is: Do you feel this helps new entrants? Is this policy useful? The most important one is by removing out “under current policies,” does this create any issues that we’re not aware of? And I would love your comments or questions at this point.

Discussion

Vint Cerf: So microphones are now open. And can I have confirmation that we’re also online.

Cathy Aronson: Yes.

Vint Cerf: Thank you. Any comments or questions?

Kevin Blumberg: I’ll put the text back up.

Vint Cerf: Microphone in the back.

Leif Sawyer: Leif Sawyer, GCI Alaska. In the old version here, you’re saying “IP address resources,” which you’ve changed to “number resources” in the proposed version.

In order - I’m guessing here to say ASNs. But then the following sentence restricts that back down to IP addresses. So I’m a little unclear on really what the attempt here is to do.

Kevin Blumberg: So thank you. It would be more an if statement: if a number resource or an address, if an address resource is - and then use that, because that’s specific to the addresses.

ASNs don’t fit under that same scenario. So we can clarify that. Thank you.

Vint Cerf: Yes, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I’m opposed to the policy as written. Yes, it does help new entrants, but I think there are better ways to do that by modifying Section 4. This is another attempt to remove some important protections from Section 8.3, and I’m not in favor of doing so.

Vint Cerf: That was pretty clear. Any other comments? Are there any comments coming from online?

Cathy Aronson: Marla Azinger, Frontier Communications: I support working on this. However, I don’t believe the second sentence clarifies anything. The transferred blocks plus the amount of free addresses currently registered to the organization must together not be larger than the demonstrated need. This does not remove the 30 day immediate use problem. This just adds another distinct restriction. I suggest you remove that sentence and add: Transferred blocks are excluded from complying with the immediate use criteria.

Kevin Blumberg: So just to clarify, Marla believes or feels that the immediate need request policy is incompatible with this section, because in this scenario, immediate need would not apply, in my understanding. This would be a simple I’m requesting up to 24 months and other ARIN policies don’t apply in this scenario. Yes?

John Curran: Presently the current 8.3 directly references current ARIN policy. So we assess you as if you’re requesting resources from the free pool and then that’s what’s used to determine what you’re allowed to transfer. It’s a transfer approval.

With the revision, the first sentence would be demonstrate their need up to a 24 month of Number Resources. Doesn’t reference ARIN policies directly. And the transferred block plus the amount of free addresses currently registered must be together not larger than their demonstrated need. The question is the demonstration of need and how that’s assessed absent other ARIN policies.

The draft staff understanding of this which we sent to the AC indicates that, much like an end-user, we would end up looking at the circumstance where they estimated their marketing demand. We would not be in a position to rely on past utilization.

So this would be more relaxed than our current policy, but we would still be asking for the justification. But if someone said their future growth for 24 months was based on these marketing projections, we would not be in a position where we could argue with that, per se.

Vint Cerf: David.

David Huberman: David Huberman, Microsoft. If we could go back to a couple of slides. Keep going. Keep going. There we go.

I am the policy author. And the reason I - the main intent of this policy is bullet point - the second bullet point up there, number one up there.

End-user policy 4.3.3 is the only objective criteria in the entire NRPM that ARIN staff used to determine if a block size is justified from an end-user. End-user wants an X, ARIN staff say are you going to use 25 percent of it immediately and are you going to use 50 percent within one year.

If not, you might qualify for a smaller block. You don’t need 50 percent of it in a year. You don’t need that size block.

And that works great. That makes mathematical sense. The 25 percent is the problem. For the last many, many years, ARIN staff have interpreted the ambiguous word “immediately” to mean within 30 days.

So what does that realistically mean? Everybody lies. Because you have to. If I qualify for a /16, I’m not going to use an /18 of it in the first 30 days. That’s my one year need, folks, but I have to lie to ARIN to get it, I have to fudge the numbers.

So Owen is absolutely right: We could solve this problem by changing NRPM 4.3.3 instead. And that is certainly an option that’s available to us.

The other option, the approach I took, was, well, let’s fix it where it’s going to be relevant post exhaustion, which is in 8.3 - where I think it’s going to be relevant, I should say - and let’s just make the mechanism so we don’t have to do this lying anymore.

And that was the real intent of it. Then on the next slide, real fast, then there are also ISPs. ISPs are required to be using space already in Section 4 to get space from ARIN. So a strict technical reading, in my opinion, says you can’t be a new ISP and go buy space on the 8.3 transfer market if you’re not using any space from a provider. But if you can’t find a provider who wants stuff who will give you stuff because they don’t have any, now all of a sudden you’re frozen out.

Kevin Blumberg: Just to ask you one quick question, then. Would putting an exclusion into those two locations, pointing specifically to Section 8.3 and saying 24 month need versus 25 percent initial, would you be acceptable to that?

David Huberman: I’m in favor of any type of solution which makes this moot for 8.3.

Vint Cerf: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. So in response to David’s comments, I think that there’s a misperception about runout inherent in that comment, which is that we hit the wall and then we’re done.

And the reality is ARIN is going to run out of /8s sooner than it runs out of /9s. It will probably run out of /9s sooner than it runs out of /10s and so forth. Certainly it’s going to run out of shorter prefixes before it runs out of longer prefixes in some form of progression.

For one thing, if we run out of /9s and we have an /8 left, we can always split the /8 into two /9s. There’s going to be a progression of runout. It’s not going to happen all at once. And, therefore, Section 4 is going to be relevant after some definition of the term “runout.”

Kevin Blumberg: Let’s keep going.

Vint Cerf: I see Martin in the back. I’m sorry. I’m seeing pink elephants, that’s what I’m seeing.

Rob Seastrom: You’re seeing another big guy with short hair.

Vint Cerf: My glasses don’t work right.

Robert Seastrom: Kevin, can you switch back to the suggested change?

Many people in the room might not be aware there’s an informal competition afoot to be the most pedantic member of the ARIN Advisory Council. Inasmuch as a recipient is a corporate entity which is a collective now and which act as one, the recipient must demonstrate its need for up to a 24 month supply. Thank you.

Kevin Blumberg: Thank you. Mr. Seastrom, in regards to that, do you see a fundamental or subtle difference between “the” and “its”?

Robert Seastrom: I don’t, actually.

Vint Cerf: Apologies to Mr. Seastrom.

Yes, please go ahead.

Sandra Brown: Sandra Brown, IPv4 Marketing Group. First of all, I support the proposal. And second comment is on these two points made on the left hand side, number one and number two.

So, first of all, I agree with Mr. Huberman that everyone does lie. We’ve seen several companies come to us and request /16, /17 and run into these two problems that are listed here.

So, first of all, regarding the first point, I think looking for 25 percent utilization in the first month for 24 months of usage, it seems to me that’s an operational problem. I’m not exactly sure how the change in words will address this. It seems to me that the operational policy manual of ARIN needs to be modified to address it as much as the policy manual.

Second point on the point number two is that we’ve run into this a few times as well, where if a company needs something like a /18 through a /16, they’re handcuffed to getting a /20 before they can get the larger block.

And it seems to me that the economic cost - and I think Milton can express this much better than I can. The economic cost is and should be the constraint, not the ARIN policy on what the initial block size should be that a company can obtain.

So based on those two comments relating to one and two, I reiterate that I support the policy.

Vint Cerf: Thank you. Are there any other - we have one from online. Is it from Marla?

Cathy Aronson: Marla Azinger had a little clarification. She said: My reference to immediate need was in reference to the 30-day immediate need. I think that confused some people with how I wrote that.

Kevin Blumberg: Thank you.

Vint Cerf: Appear to be no other comments. Does that suggest we need to move to find out people’s opinions?

Kevin Blumberg: I actually have two questions, because out of this has actually come a very interesting scenario, which is, one, change 8.3, and I would love to hear using the suggested draft text with the minor tweaks or continuing down that route.

But the second scenario is to insert into the two locations, which are the issues with new entrants, basically carve out that say if it is done through an 8.3 transfer, then you just have to show your 24 month or up to 24 month need, is a different way of doing that.

That would be not playing with 8.3. But it would be now adding more text to the NRPM, more carve out to the NRPM to deal with new entrants.

And I believe the community is concerned about new entrants. So it’s two ways of doing it.

Vint Cerf: Please go ahead.

Scott Leibrand: Scott Leibrand, ARIN AC, Limelight. I support this. I think I support it as written. I definitely support it in principle. I think it’s probably more useful for us to focus on the narrow issue at hand in this policy proposal, rather than trying to change NRPM Section 4 right as we’re about to run out in a way that we think does carve outs but then maybe we want to change it - I think the appropriate thing to do with NRPM Section 4 is leave it alone for the moment.

And once we’re cleanly past runout, we need to dramatically simplify NRPM Section 4, because there will still be people who can get addresses from ARIN via the waiting list, via return space, whatever.

But that, I think, is a separate issue from the issue at hand, which is for the transfer market to work effectively, we need the ability for new entrants and other people who don’t already have space to be able to get it.

We cannot have a chicken and egg problem. I think it’s essential that we do something like this very similar or identical to this in order to make sure that at the time we hit runout we’re not up against a wall of people not being able to get space.

So I think it’s timely and important that we move this forward in the simplest manner which we can, which I think this is pretty close to that.

Kevin Blumberg: Thank you. So I think we can go with the one question.

Vint Cerf: So the question, given no other comments, is whether - since this is a Draft Policy, we’re only looking for guidance as to continuing the work. So if you vote in favor, you will be telling the AC that it should keep working on this problem.

So let me ask our tabulators to be prepared. All of those who believe we should continue this work, please raise your hand and keep them up until the tabulation is done. I ask the same action of the online audience. You guys are really fast. Put your hands down.

May I see a show of hands for people who do not wish to continue this work and believe that the AC should cease. There’s another hand that went up kind of late, in case you missed it. Are we done? Thank you. I’d like to see the tabulated results, please.

John. You weren’t voting; you were asking for permission to speak. Speak.

John Curran: When I do this, there’s no way to know what I’m doing. I could be voting; I could be scratching my head.

We had at least two people do this in that last tabulation, and so I don’t know what that is. I really don’t know and they don’t know and no one knows. This also. The person doing that, that didn’t help either. If you do this, that doesn’t help.

I actually really need people to raise their hands all the way up because the tabulators are behind you. They cannot see unless you raise your hands. I’m very sorry, but I have to be pedantic.

Vint Cerf: No, you’re just being a pest, that’s all.

Well, we had 93 in the room, 10 remote; 103 total. And the response to the question, 27 in favor; two against.

Thank you very much for that presentation.

John Curran: Thank you.

(applause)

Draft Policy ARIN 2014-12: Anti Hijack Policy

John Curran: Moving right ahead. We’ll drop right into the next Draft Policy, Draft Policy ARIN 2014-12, the anti hijack policy.

The proposal originated in February as ARIN Policy Proposal 2002. David Farmer and Cathy Aronson are the AC shepherds. It was accepted in March as a Draft Policy. It is in your guide and online. It has been posted to PPML and presented for community discussion with the questions: Is it good number policy? Is it fair and impartial, technically sound, and is it supported by the community.

In particular we’re trying to determine if the AC should continue work on this policy proposal or get rid of it.

I’ll now invite David Farmer up to give the AC presentation.

David Farmer: I know how to work the remote. So a little bit of context here first, just so that - because when this first came out, a lot of people didn’t know what it was talking about. So there was a presentation about background radiation and IPv6 at NANOG 60. The group got LOAs from each of the RIRs and announced /12s for each of the RIRs’ IPv6 space.

There’s also a related suggestion for making sure that all the information and supporting documentation for experimental allocations are put up publicly. And ARIN - there’s a little excerpt from ARIN’s response saying yep, they’re going to do that.

So the problem statement: ARIN should not give research organizations permission to hijack prefixes. You can read it there.

I can tell you that this was a whoops, and John has said on PPML that this ain’t going to happen again.

And so that’s the problem statement. The policy statement associated with it is clean up 11.7 a little bit to prohibit this. And this is the annotated changes to the current 11.7, basically change the name from “allocation size” to “guidelines” and insert the phrase and a new paragraph.

I’ll let you all read that. I’ll come back to it when we do the discussion.

So discussion. There’s been much discussion about the event but not so much discussion about the policy text and what we should do about the event. So is a policy change necessary or is John saying it’s not going to happen again good enough? Or is this, like I said, just an ARIN procedural issue? Questions, comments, then I’ll put it back on the - oh. If you pull up - there’s some nice links to the details, if you’re interested. These links were also on the mailing list.

Discussion

Vint Cerf: Could I get a clarifying question? Did this research, the way it was formulated, require that there be addresses used that had already been assigned to somebody, or could this research have been done in some other way? Would you not know the answer?

David Farmer: That’s not completely clear to me, what the original intent of the research was.

Vint Cerf: Is there someone who has - Bill Woodcock. Could we allow Bill to respond ahead of everybody?

Go ahead, Bill.

Bill Woodcock: Manesh was shocked, shocked, to find out that he could receive packets bound for other people by advertising their supernet. So he claims that, no, the results were utterly unanticipated.

It’s a little hard to know what the goal of the research would have been other than to discover exactly that result, though.

I mean, what he says is that he’s interested in seeing what would arrive, and the theory there is that everyone else’s more specific advertisements should have trumped that and he only should have seen things that arrive to otherwise unadvertised prefixes, but there’s no actual experiment there, because that is the normal operation of the network.

If you advertise a prefix, you receive what’s bound for that prefix. He was in fact advertising the prefix, not not advertising it, which would have been the experiment.

Vint Cerf: Thank you for that clarification. John had his hand up first. Go ahead.

John Curran: First and foremost, this policy text does clarify some things about resource allocations in general, which might make it something that the community wants to consider and adopt because of the benefits across the board for all research allocations, completely independent of what ARIN did along with the other four RIRs in providing a letter of authority with respect to the /12 IPv6 space.

As I said online in the PPML, we’ve had a lot of people do testing of dark space. We were asked for this LOA to do that sort of testing. The idea that it would be used to do a route across assigned space was something I did not catch. And that was a mistake and I’ve said that on PPML.

We had the discussion at the Board level, and I said it’s a mistake. It’s not ever necessary for ARIN to issue an LOA. This policy text implies we might have to, in the last sentence, an LOA for a research prefix.

But the reality is if the research prefix is in Whois assigned to an entity, they can issue their own LOA because it’s listed to them. So the reality is ARIN should never be doing an LOA except for its own operational space that’s actually assigned to ARIN.

So the good news is this all has been clarified with the Board, and the Board has reminded me that, yes, indeed, this was a mistake and I should remember that at all times.

(laughter)

John Curran: So this won’t be happening again regardless of whether you pass the policy or not.

But that doesn’t mean it’s not good policy. It might be good policy for research allocations in general. Obviously if we receive the request to do darknet testing in the future, we would say identify what dark nets you want and we will allocate them to you for the purposes of the experiment and you can go get your own routing.

There’s a second issue, which is completely unrelated which people need to think about, which is the fact that ISPs would actually listen to ARIN, giving an LOA for all of the space is terrifying and you should not do that, even if somehow that would ever have been issued.

Vint Cerf: They were just following orders.

John Curran: I don’t want -

Vint Cerf: Yes, please.

Heather Schiller: Heather Schiller, Google Fiber, also author of the proposal. So in the RIPE region after a couple days of this block being announced - or RIPE /12s, the RIPE community actually said, hey, this is really bad; why are you advertising our space? And RIPE rescinded the LOA and said, no, you can only advertise the bits that are not actively allocated.

And that didn’t happen in the ARIN region. So I think that, at least in the case of Merit, they fully understood what they were doing; that they were advertising actively in use address space. I think it really was part of their experiment and what they wanted to see. But none of this was publicized to the community and no one knew about it.

There were other problems as well, like they didn’t stop advertising it on time and other things. But besides the point, I think this policy text is needed because today there’s no policy or procedure for ARIN to - requiring them to document the experimental allocation in Whois.

So my understanding is that in the past you’ve issued experimental allocations but they haven’t been registered in Whois and they’re maybe buried on some Web page somewhere that nobody knows about.

This way someone can actually go in Whois and look up the allocation. There’s contact information. It’s documented. It’s much cleaner, easier for people to understand what it’s for. And, again, you won’t have to issue the LOA very likely. You’d also in the future be able to do the whole RPKI and ROAs and stuff, and I think having this text going forward is worthwhile.

David Farmer: One thing there. So they only - yeah, RIPE, some people noticed it and they did it. I’ll note nobody - I’m quite sure if anybody raised this issue to John, John immediately would have made a change.

Heather Schiller: I’m going to go ahead and out the whole thing. I’m sure Leslie is right here, and she said that - she told me that ARIN actually went to Merit and said, hey, this thing happened over in RIPE when they said they rescinded the /12; is that going to be a problem here? And Merit told them no, it’s not going to be a problem. And ARIN said okay.

So that’s not - I mean, in this one case, overall, this whole thing needed to be more considered.

And I think between this policy and the suggestion that ARIN publicly announced experimental allocations and all of this has a lot more sunshine put on it and it gets posted to mailing list s and engineers get to see it and know that it’s happening, you’ll be able to catch problems. I don’t envision this mistake happening again, but you’ll be able to catch things that might be a problem.

I think both this and the suggestion helped.

Vint Cerf: Thank you for that. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I support the policy mostly as written. The concern I have is the redline in the first paragraph that says “do not overlap previously assigned space.” I would suggest we consider “currently assigned” or “allocated space.”

David Farmer: Thank you, Owen.

Vint Cerf: I think that’s a good suggestion.

Bill Woodcock: I agree with - I support -

Vint Cerf: I’m sorry, who are you?

Bill Woodcock: Bill Woodcock. One question, mostly for Heather: If we’re going to have a lot more sunshine and always announce and put research allocations in Whois and so forth, do you suggest then that we create a separate policy for law enforcement use.

Bill Woodcock: Law enforcement use in which law enforcement needs to put up a server that is not obviously law enforcement. A little late for that.

Vint Cerf: Heather?

Heather Schiller: I don’t follow what you’re referring to. In the case of Merit, it’s public and I know what they’re referring to, but I don’t know what you’re referring to. But I would say that law enforcement’s an independent entity that can apply for space. There’s no specific policy that says resource allocations for law enforcement purposes that’s for experimental use.

Bill Woodcock: Correct. There’s no separate policy. There has been no separate policy and there has been no requirement that every research allocation be very publicly heralded.

So because that’s a need of law enforcement, do you now propose there be a separate policy to handle law enforcement research, research allocations that are not publicly heralded, that are not experimented under this nature.

Heather Schiller: Staff can correct me if I’m wrong, but I understand that this experimental resource allocation policy to exist because the allocations are temporary in nature.

John Curran: We actually call them experimental allocations. And they’re not in Whois. Under this, all this says - this says resource allocation guidelines, but -

Heather Schiller: It says research.

John Curran: I believe it means -

David Farmer: It’s under 11, which is experiment -

John Curran: Right, which is research. I believe this is all experimental and it would all be identified as experimental allocations. We would not put allocations that weren’t - we would not do temporary allocations other than under this policy.

Heather Schiller: So my response to it would be that this policy text, the experimental allocations existed prior to the allocation to Merit. So we’re modifying what already existed.

If you want to say it never should be there to begin with, that’s fine. But I don’t know how an allocation to law enforcement would be different than something that already exists today.

Scott Leibrand: May I follow up directly on that? John, does ARIN staff see the need for policy to allow you to comply with legal law enforcement requests?

Vint Cerf: First, that’s a very strange -

Scott Leibrand: Let me specifically.

Vint Cerf: Be a little bit more precise about this.

Scott Leibrand: If this policy were to pass, would ARIN staff see the need for additional policy to allow them to cooperate with law enforcement in whatever activities law enforcement has to do with regard to getting and announcing space? Does this policy - is this policy used by law enforcement and do you need something else, if it is.

John Curran: I’m aware of law enforcement use which is in Whois, although it may not be in the names you expect. I’m aware of law enforcement use - there are cases where they may use addresses that we’re not - we didn’t assign, but that’s not under our control.

This would be - we will use the experimental internet resource allocation section, Section 11, for all of the temporary allocations that are done, including if we get a block from IANA, including if Merit wants to do darknet testing. I’m happy to have all the allocations that are used in this policy.

So the answer is I would presume if it’s not a permanent application and it’s temporary, it would still be a Section 11 temporary one and it would be under this. I don’t know of any need for any others, I guess, if that answers your question.

Vint Cerf: Maybe the term “experimental” here is odd and “temporary” would be more accurate?

David Huberman: No.

Vint Cerf: Let’s wait for your turn. Please go ahead.

Sandy Murphy: Sandy Murphy, PARSONS. This policy has to do with ARIN issuing an authorization for operational use of resources. My mind immediately progressed to other authorizations for operational use of prefixes such as route objects in the RIR and, for example - dare I say the word - ROAs in the RPKI.

Do you believe that this policy would extend to a policy that ARIN should not issue route objects or ROAs for prefixes.

John Curran: Actually, you’re now where I was three weeks ago because the thought that we would somehow authorize a ROA on a block that isn’t in our own name is terrifying.

So the policy has a sentence at the bottom: ARIN will not issue a letter of authority to provide a research prefixes unless an allocation is properly registered in Whois.

Having discussed this with the Board, I’m going to tell you: ARIN is not issuing a letter of authority for any prefix except one that’s registered to ARIN. And that same thing applies to a ROA unless somehow there’s an IETF protocol reason why we would have to do something else like a transfer or a swing condition.

But the reality is that I do not believe ARIN should be issuing a letter of authority in any case other than its own operational resources. And this solves that. This policy makes it very clear.

The last sentence is actually not needed and undesirable of this proposed policy. It should be taken off. Because once you put someone in Whois, they should be doing their LOA or they should be issuing their own ROA.

Sandy Murphy: A /8 that is issued by IANA to ARIN, is that considered in your mind registered to ARIN or not?

John Curran: For our operational purposes, it’s in our pool. It’s not something we should be using unless we allocate some of it to us for our own use or put a temporary assignment to someone else to do darknet testing. So the answer is no.

Sandy Murphy: So that’s a statement of your intent; I’m asking whether you this policy text covers that case.

John Curran: I would need to look. I do not know.

Vint Cerf: David.

David Huberman: David Huberman, Microsoft. This is not the temporary allocation policy. Looking at 11.7, there is an enormous amount of text we’re not looking at right now.

11.1, the very first sentence, very clearly says: A recognized experimental activity is one where the experiment’s objectives and practices are described in a publicly accessible document.

Later in 11.1: ARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed.

There’s absolutely no relevance to law enforcement here today. If law enforcement were to come, it would have to be completely public. It’s not the secret stuff, we’re trying to catch people quietly.

There’s an argument - I fully support the policy with Owen’s change, that has to be currently not previously. I fully support this. But you could make an argument this actually doesn’t belong here because Merit didn’t get an experimental allocation.

But it’s as good a place as any to throw in the sentence for when John is no longer the CEO and the Board has completely turned over and it’s a completely new regime: Don’t do this. But this has nothing to do with law enforcement.

Vint Cerf: Martin in the back.

Martin Hannigan: Martin Hannigan from Akamai Technologies, and I basically support the proposal. I think you should remove the reference to the LOA. I don’t think it needs to be in there at all. The way it’s written actually implies you could still write an LOA.

I’m concerned that the LOA was written, but I am also more concerned that the operators accepted it. I would not have. I don’t know why they did, but that’s an operator question.

I think what Scott was asking about, if I interpreted it correctly, was with relation to Section 2.1.5 and 7.0.1, and I don’t believe that you need any policy to comply with that, and nor should we go in that area. I have some experience in this area, and I’m sure that they’re not worried about it, and neither am I. Thank you.

Vint Cerf: Thanks, Martin.

Any questions from online? I see no more comments here.

I’m sorry, please go ahead.

Kevin Blumberg: John, I have a question for staff: How many experimental allocations have been given out in the last X years.

John Curran: Leslie, could you? I don’t memorize the database.

Leslie Nobile: Yeah. We currently have three active experiments registered in the database.

Vint Cerf: How do you remember stuff like that? That’s amazing.

I don’t see any questions or comments.

Kevin Blumberg: It was two parts.

Vint Cerf: Sorry.

Kevin Blumberg: No worries. The second thing to this is if this is now published in Whois, because historically it’s not been, is that correct, then it would show up in Whowas that a block was used for experimental purposes.

So whether we find out that a block’s been blacklisted across the board because it was used for experimental, would that tie into this new text change, that it would then be registered in Whois properly and would then show up in Whowas.

Leslie Nobile: I need to clarify something. Experimental applications that are applied for under that NRPM 11, whatever - sorry, I don’t know that - they are registered in the Whois database. They are registered.

John Curran: What hasn’t been registered is when we get an address block and we want to test it to see how clean it is, we have just been saying, okay, go forth and test it. And it’s been in our pool but not actually shown as an experimental allocation.

Clearly we should make that experimental application for purposes of darknet testing, and then it would show up correctly.

Vint Cerf: Have we come to -

David Farmer: And just for clarity, I think in that case ARIN is the sponsor of the experiment, which is the darknet testing. Does that sound logical.

John Curran: ARIN or the researching institution, one or the other. Probably the researching institution because they’re the ones who are going to route it.

Vint Cerf: This is a work in progress, so the question is should we continue this work. And if you vote in favor, the AC will get the message; if you vote against, it will similarly get the message.

Let me ask: All of those who believe this should continue, please raise your hand and keep them up. Put your hand down.

Those who feel this work should not continue with the AC, please raise your hand.

Okay, do we have confirmation that we have online votes as well, if there were any.

John Curran: I’d like to thank Dave Farmer for his presentation.

Vint Cerf: Thank you very much, Dave.

(applause)

Vint Cerf: Thank you very much. 94 people in the room, 11 remote, for 105 total. And the response to the question should we continue work, 26 in favor and none against.

So thank you very much, and thank the AC for continuing on this effort.

John, next item.

Draft Policy ARIN 2014-11: Improved Registry Accuracy Proposal

John Curran: Very good. Moving right ahead. We’re going to move to the next policy proposal which is the Draft Policy ARIN 2014-11: Improved Registry Accuracy Proposal.

It started out as ARIN Policy Proposal 203 in February 2014. Kevin Blumberg and Bill Darte are the AC shepherds. It has been accepted as a Draft Policy. It is in your guide and online.

It has been posted to PPML and presented for community discussion. Same criteria: Is it a good number policy? Does it facilitate fair and impartial number resource management? Is it technically sound? Is it supported by the community? In particular, should the AC continue work on this or get rid of it.

Thank you. I’m going to turn it over to the AC presentation, Kevin Blumberg.

Vint Cerf: I have a suggestion. As you look at that list of questions that you ask each time for these cases, why don’t we use a subroutine idea here and you can just announce subroutine No. 123 which references that body of text.

Sir.

Kevin Blumberg: Go to Kevin. Sorry. So the problem statement I’ll start off with: The importance of maintaining accurate records in the ARIN database is recognized as the registries principle task and is not being debated. The registry is unable to responsibly fulfill this task. Many resource holders are not incensed through mutual benefits to participate in the registry, the process or the community and instead operate successfully outside the bounds further hampering the mission of accuracy.

And the intent is: To create a sustainable RIPE 605 like environment in the ARIN region that provides mutual benefits to legacy holders and ARIN and in support of vastly improved and accurate registry services.

So recently the community added to a principle section a number of statements. And this policy change would do two things. It would add to principles a number of areas, as well it would add to definitions, something that the community has talked about for a number of years but hasn’t really done, which is to put in definitions for legacy Internet resources, what a resource holder is and registry service element. Those are the two things, one is the principle side and one is the definition side.

So starting out with principles. To add to the existing principle section accuracy: The principle of accuracy guarantees stakeholders that all reasonable and mutually beneficial steps will be taken - will be taken - that’s a typo there - to ensure that the registry is as accurate as possible.

Fairness: The principle of fairness guarantees stakeholders that they will be treated fairly with respect to whatever class of resources they hold, whether they are pre- or post-RIR assigned addresses.

The value add: The principle of value add guarantees that the registry, in its effort to ensure that all of the principles are applied equitably, will seek to add value to all resource holders and regardless of class by ensuring things such things as rapid update functionalities and reasonably easy transfer administration.

Mutual benefit: The principle of mutual benefit guarantees that ARIN will enter into or dissolve contracts related to legacy resource holders in like fashion of comparable registries.

So we’ll go on to the definitions.

Legacy Internet resource: Any Internet resource obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries.

Legacy Internet resource holder: The holder of a legacy Internet resource. Either by receiving these resources directly or by receiving (part of) legacy Internet resources from a legacy Internet resource holder.

And, lastly, a registry service element: In practice, any legacy resource holder actually avails of a subset of the registry services mentioned above. Where it is necessary to distinguish between the entire class of registry services and the specific registry services actually provided in a particular case, the latter are described as registry service elements.

So discussion. What impact would changing the principles section have to existing policy? As an example, in Section 8, the recipient is required to have signed an RSA as one of the conditions; will this policy supersede that?

Are the definitions of a legacy resource and legacy resource holder correct? What would you add or remove from the proposal? Are there aspects that are outside of the NRPM?

So I guess the question is - this is a lot to digest. This is really a major change to the definitions of actually putting in the definitions of legacy resource holder, as well as carve out for legacy resource holders in terms of how they are handled within the community.

Discussion

Vint Cerf: So the microphones are open for questions and discussion. We have an online one already. So please go ahead.

Cathy Aronson: Hi. Just a second. I’m going to try to be really efficient about this, because it’s somewhat long.

Marla Azinger, Frontier Communications, I don’t support this. I don’t see this as a simple innocent change. I don’t entirely see how this is geared to improve registry use.

In addition, your definitions will end up affecting policy and agreements. Due to this I would like to see how this would affect exactly which policies and which agreements and with details on how they would be affected. You can’t posthaste add definitions without it affecting terms already in place.

I don’t see this as particularly helpful for companies using legacy space. In regards to some specific bullets, fairness, this is impossible to guarantee. It does not happen today and it likely never will.

This is why there’s some variation in the address policy today. Mutual benefit, no support. There are legitimate business reasons for legacy space. Additionally, dissolving contracts is particularly troublesome and it is an act that would be sure to end up in expensive litigation.

Legacy Internet resource definition is so written so that it purposefully excludes transferred addresses from retaining legacy status. This proposal is not a simple accuracy change. It is written in a manner that appears to be created for putting the pinch on companies that have to use new or alternative processes.

These changes would not help companies struggling due to ARIN policy that falls short of supporting members, all members equally. Thanks.

Vint Cerf: Thank you. David.

David Conrad: David Conrad representing something.

(laughter)

David Conrad: But not the US government in any way, shape, or form.

So I think I agree with at least parts of this. But it’s really long, really complicated and involves a whole bunch of stuff that’s way too big for my little mind.

I might recommend - so I’m very, very much in favor of the accuracy of the registry. I think people who know me and have seen my voluminous postings on various mailing Lists know I care deeply about the accuracy of the registry.

I’d like to pull that particular section out, make it an independent policy proposal and deal with everything else separately.

But as it’s written now, I sort of support it, but it’s really, really complicated and long and stuff. But Bullet 1 there I definitely support.

Vint Cerf: Thank you, David. Let me get the microphone in the back, and we’ll alternate between the two.

Matt Pounsett: Matt Pounsett, Afilias. First a nit, I guess, on the definitions. Your definition for legacy resource holder is self-referential. That doesn’t work. Still doesn’t work.

(laughter)

Matt Pounsett: More general comments about the proposal. It is really complicated, and it’s not clear to me how any of it actually helps accuracy. We are adding a bunch of definitions. It’s not obvious what the operational effect is from that, and therefore not obvious how it’s going to fix accuracy problems.

And I think there’s a bit of this in Marla’s comment that I can’t support this until there’s a much clearer expectation of what this is going to touch and what’s going to happen.

Kevin Blumberg: Let me open it up.

Vint Cerf: I’m sorry. I thought you were to about recite -

Kevin Blumberg: No, no, no -

Vint Cerf: Owen, then it’s yours. Then the we’ll go to the back microphone.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I do not support the proposal as written. This is an attempt to essentially create a separate class of resources in perpetuity, surviving transfer, which does not currently exist.

It is an attempt to create essentially some end runs around ARIN policy to facilitate improved monetization of resources that were obtained for free from the community, and I do not see any benefit to doing that whatsoever.

I think any comments claiming that this will somehow improve accuracy in the registration database are relatively specious and lacking in documentation or evidence.

Vint Cerf: And later I assume you’ll tell us what you really think. Thank you for that.

The gentleman in the back.

John Springer: John Springer, Inland Telephone, ARIN AC. As with every other Draft Policy proposal, this one is either going to go to the next stage of the game or not. And I’m for it going to the next stage of the game because there’s some value in here.

I have a particular problem with the mutual benefit section. The principle of mutual benefit guarantees that ARIN will enter into or dissolve contracts related to legacy holders in like fashion of comparable registries, I don’t think that’s a good enough reason to do anything contractual with any resource holder just because a different registry does something in its own way.

Kevin Blumberg: So in the past we’ve had - we’ve brought the RSA and LRSA. Two contracts, one for legacy space, one for regular space. And John - correct me if I’m wrong - has said numerous times the only difference between the two documents was the fee schedule.

John Curran: At this time.

Kevin Blumberg: At this time. But that’s where they are today.

Part of this proposal is to - this is something that the community has looked at in the past and has had a hard time with it, but maybe now is the right time, is the concept that legacy resource holders are different, have been different in the past and should be given different treatment within the policy framework.

Again, in most cases legacy resource holders don’t come to ARIN for new space. They’ve got a lot of space. It was a whole different world back then, but we’re now at runout, we’re in a different scenario, and the question is, for the community, is it more beneficial to have access to the space as easily as possible and to give the benefit - to give benefits to legacy resource holders in return for making it easier on legacy resource holders.

So maybe that’s another way of looking at this without getting into some of the things that have been brought up. Is that something you would be supportive of from a policy text change?

Matt Pounsett: Matt Pounsett, Afilias again. That sounds like a reclamation argument, not an accuracy argument. Right? It sounds like you’re saying we want to get that space out there and get other people using it as opposed to we want to have an accurate database, which is what the problem statement is about.

Kevin Blumberg: It’s a two-fold problem. If you don’t allow for easy transfers for keeping things above board, you’re not going to have an accurate registry.

Matt Pounsett: Don’t we already allow for easy transfers?

Kevin Blumberg: The issue is that the legacy resource - or potentially legacy resource holders don’t feel that. That I don’t know. That is what is in the problem statement.

Vint Cerf: I see we have one more comment. Please go ahead.

John Springer: Kevin, I don’t know how much of that previous comment was directed at me in the context of my comment, but with regard to the status of the legacy resource holders and all the conversations that I’ve been a party to or witness to, kind of the - nothing’s ever become enshrined, but we’ve sort of agreed to live and let live and let the legacy resource holders alone.

This is an attempt to codify that, and I don’t think this is the right way to do it and I can’t agree to it.

Kevin Blumberg: The live and let live when we were in a free pool environment was perfectly fine. The reference to RIPE 605 is because that region ran out and they realized that just leaving it in that scenario wasn’t good enough.

We’re not quite yet at runout, but we’re getting very, very close, and the question is do we need to continue with policy on that.

John Springer: May I respond to that? I believe that needs to be an entirely separate discussion. This has got some benefits. I’m with David Conrad with the accuracy, first component. But if we’re going to actually codify something that essentially does a RIPE 605 type scenario, it’s not going to be buried in a bunch of other stuff that - at least as far as I’m concerned.

Kevin Blumberg: Okay.

Vint Cerf: I have one online comment and I have a comment from the stage here. So let’s take the online comment first.

Cathy Aronson: Okay. Here we go. Scott Morizot, IRS: I oppose this policy. I’ve seen no evidence offered that supports the multiple assertions made in the problem statement, and I don’t agree with the assertions.

I oppose the definition offered for a legacy resource that creates an obligation on ARIN that transfers from one resource holder to a subsequent holder.

I’ve offered alternative definitions of legacy resource and legacy resource holder on PPML that attached the legacy status to the holder and not to the resource and does not make it a status that be transferred to another entity.

We all agree that there is benefit to the community in ARIN providing basic registry services to legacy resource holders defined as entries that actually received the allocation prior to the formation of ARIN, whether or not they assigned the RSA, the LRSA, or ever pay any ARIN fees.

I see no benefit in extending the obligation to anyone to whom the resource is transferred. If someone who buys the resources from ARIN - I’m sorry, resources from a legacy resource holder wishes to receive ARIN registry services, then they need to sign an RSA, comply with ARIN policy, and pay their ARIN fees.

For the record, the IRS is an IPv4 legacy resource holder and an IPv6 resource holder. We have signed both an LRSA and RSA as appropriate. And legacy resource holders who continue to operate will come to ARIN at some point for IPv6 resources.

I know that for us we become more involved with the ARIN process as we work to obtain our IPv6 allocation.

Vint Cerf: Thank you for that. We have a comment from the stage here.

(applause)

David Farmer: So the purposes of policies - David Farmer, University of Minnesota, ARIN AC. The purpose that people perceive for policies frequently are different. I may have one purpose; you may have another purpose.

So there’s more than one purposes for policies frequently. One of the purposes of this policy originally in RIPE was to establish contracts with legacy resource holders so they could do ROAs and do certification.

There are other reasons, too. We already have a process for legacy resource holders to bring their resources under contract and get those ROAs and other certifications.

I think this is an important policy, but I think this is a big chewy thing, and I think we need to carve it up.

Vint Cerf: Thank you for that comment. Jason, is that you back there?

Jason Schiller: Jason Schiller, Google. I’m not sure where I stand on this, mostly because I don’t clearly understand what this policy is attempting to do.

I think this could benefit from having a much clearer problem statement. It’s unclear to me whether this is about legacy holders wanting to be able to get RPKI without planning an RSA, whether this is about legacy holders wanting RPKI without paying $100 a year in fee towards ARIN. I don’t know if this is about legacy holders trying to bring the registration of their blocks as current without signing an RSA so that they can transfer it.

It’s hard for me to understand what’s driving this policy. And with respect to some of the definitions, I’m very concerned about how they would be used, because I don’t think it’s as quite as simple as one might think. You could be a legacy resource holder with only holding legacy space and not under RSA; you could be holding legacy space that’s under RSA; you could be holding legacy space that’s not under RSA but also hold ARIN space which is under RSA; you could be holding legacy space which is under RSA and holding ARIN space which is under RSA.

And this is a very complicated and interesting Venn diagram, and I’m not sure how these definitions will be applied for other things in terms of what services are offered to which portion of the Venn diagram and so forth.

So I’m very concerned about that.

Vint Cerf: So this is a manifestation of Theorem No. 206, which reads: Everything is more complicated.

Martin.

Martin Hannigan: Martin Hannigan from Akamai. I submitted this proposal. Actually, it’s not even a policy; it’s just an addition to some of the definitions that we already have in the NRPM. And there’s no other way to get something into the NRPM other than the policy process, at least that I’m aware of.

David, with respect to benefits through the RSA and LRSA, we’ve failed on - I mean, the registry is less than 65, 70 percent accurate, probably even worse, and it’s because while some legacy holders do participate in signing the agreements, most don’t.

All I intended to do here was just set a basis to have the discussion that Jason just said, what is this? Is it this or is it that? Actually, it’s all the above. And having some common definitions that we all agree on will hopefully allow us to go forward with some adjunct policy to at least the transfer system.

Which, by the way, we’re all going to be using in a relatively short time. And the policy, at least as far as this meeting has demonstrated, is very confusing, not completely, I guess I would say, in consensus. It doesn’t appear to be very friendly to use, and perhaps some of this will be helpful.

If the mission of ARIN truly is an accurate registry and a steward of IP addresses, you would think that we would want to find a way to bring those people in that so far have not come in. We have not done that yet, and this is my attempt at trying to get us to that point where we actually can do what we say we want to do and provide for an accurate registry.

That’s pretty much it. It’s really simple. And I think it’s being overthought a little bit. Thanks.

Vint Cerf: Thank you, Martin. I’m going to close the microphones soon. So if you have comments you want to make, you should queue up. I have one comment from online and then…

Cathy Aronson: Lea Roberts, Stanford University: I oppose the policy as written. I agree with David Conrad that the registry accuracy is important and should be pursued, but I feel other aspects of this policy are major changes that I’m not sure warrant it.

Vint Cerf: For that, let’s get the microphone in the back, please.

Guangliang Pan: Guangliang Pan from APNIC. I just want to share some experience from APNIC. Ten years ago APNIC had a policy regarding to historical resource. We contacted all of those legacy resource holders and ask them to update the record. And if they want to update, they pay $100 to APNIC. If they don’t want to do it, just leave it as it is.

And we’ve received huge response and require of them to pay $100. But we also receive a lot of complaints saying why do I need to pay APNIC at that time.

But nowadays the fee has changed to $200, but we don’t receive many complaint about paying $200 to update those legacy resources.

Just want to share this information with your region.

Vint Cerf: Thank you very much for sharing that.

Could we get the next comment?

Kevin Blumberg: In the ARIN region, how much of the space that’s legacy is under LRSA or RSA at this time? Ballpark is…

John Curran: Allow me a moment. Back up. Give me a moment.

Chris Spears: Chris Spears, Internet2. So in line with that statistic, I’d like to know how many of those organizations that ARIN serves, what percentage roughly are legacy. I saw a number from maybe two years ago that Leslie put together that said I think 44 percent of the Org IDs that ARIN serves are legacy. Doesn’t speak to the number of resources, but I assume it’s a very large number.

I’m in favor of parts of this proposal. I definitely think adding some definition of what a legacy resource holder is, since the word “legacy” doesn’t appear in the NRPM right now, is possibly a good idea, acknowledging such a large portion of ARIN’s constituency. Regardless of their level of involvement in fiduciary contributions, it is probably important to recognize their existence.

But I do have questions around mutual benefit, for example, in dissolving contracts, things like that.

John Curran: Some statistics. Of organizations with directly registered IPv4 addresses, we have 26,000. Organizations 26,148. Of those 4500, 20 or 17 percent are ARIN members.

In terms of the address space, total equivalent of /24s, approximately total equivalent space is 101 /8 equivalents, of which the ARIN members represent about 42 of those 101. So about 42 percent of the equivalent space is members.

In terms of membership count, it’s 17 percent of the organization count. Recognize some organizations have multiple Org IDs, there’s some windage there, but that will give you statistics.

Scott Leibrand: What about non-legacy non-member? He asked about legacy; you gave member. I think there’s a third category in the middle, which is basically end-users. Right?

John Curran: Oh, yes, there’s another, sorry, 14,000 End-users who have relations. They’re not ISPs, but they have relationships with ARIN. And I was not counting that in the count. Okay? Those are not ISPs; those are end user.

Vint Cerf: Thank you for that clarification.

Could we get the last few comments. The microphones are now closed except for those who are in queue.

John Springer: John Springer, Inland Internet, Inland Telephone, ARIN AC. So this is a policy proposal, recommended Draft Policy No. 14. We’ve had really good success here in the last couple of days at advancing policies according to the PDP. I think that this Draft Policy is an ideal candidate for a 14 for 14 sweep. Meaning I would not support abandoning this.

But I’m opposed to it the way it’s written. I think we ought to - the AC currently owns it. I think we ought to take it back and divide it up in chunks that are palatable and pass the chunks that are easy and debate the ones that are not easy and make a bunch of progress that way.

Vint Cerf: Thank you. Last comment other than those that might be online. Go ahead.

Gaurab Upadhaya: Gaurab from Limelight Networks and also a participant of most of the RIRs’ policy process.

I support this proposal in the sense that we need to have definitions behind what legacy means in our world.

I might go back and change some of the wording to make it clearer or less confusing. But in principle I think we need those definitions in place, because increasingly we are seeing address being transferred across regions.

And I would actually argue that the proposers of this should probably - RIPE already has RIPE 605. And I was comparing the language, and it looks like it’s almost the same - Martin can confirm - the same definitions in the 605. Right? Fairly similar. So I would support that something like this goes forward.

And we have a definite definition of what legacy means, what historical means. In the APNIC region, we refer to certain addresses as historical and certain as legacy. And there is a third category, which is David Conrad’s legacy.

(laughter)

Gaurab Upadhaya: To add to the story, there was a period of time when David was assigning address space, ‘93, ‘94, before APNIC was incorporated. And a bunch of people bought addresses during that time, which never actually became APNIC members. So in the APNIC registry, they’re categorized as APNIC legacy. I think we refer to them as historical for some reason. Yes, all of those. And we referred to the addresses that were assigned before that, before DRC became APNIC, we referred to them as ERX address space.

So with all of this, I think having a definition across all RIRs of what these things mean will get my support. So I support that this should be worked on further. The specific language, I think I’ll have some reservations on those.

Vint Cerf: Before we call for a vote on whether this should continue, I want to make one suggestion to the AC. This group working on this proposal might do well to consult counsel about the potential legal side effects of trying to make these definitions. I think there may be devil in the details, and that might be real substance to ARIN as an organization.

So let me now ask for you to cast your votes. If you are in favor of continuing this work in some fashion, please raise your hand and keep it up until the tabulation is complete. All those in favor raise your hand.

I see late voters, so make sure you keep your hands up. Thank you.

May we now see those who are opposed to continuing this work? Thank you. You can put your hands down.

This looks like it may be a close vote.

John Curran: I’d like to take a moment to thank Kevin Blumberg.

Vint Cerf: Thank you very much.

(applause)

Vint Cerf: Thank you very much. There are 100 people in the room and ten online; 110 total. Those in favor of continuing, 11; those against continuing, 15.

So that’s a rather interesting balance. John.

John Curran: Okay. So we’re going to go into break, and you actually - because of your great efforts, you’ll get an extended break. Everyone go out there and enjoy the coffee or cookies - or actually I have no idea what’s out there. Whatever is out there, go enjoy it.

I’ll see you promptly back here at 3:30. Thank you very much. Go.

John Curran: If people will come back in, we’ll get started. I’d like to start out with - let me see if I have any announcements. Do I have any announcements? Good, no announcements. I’d like to start out with Leslie doing the Internet Number Resource Status Report.

Internet Number Resource Status Report

Leslie Nobile: Okay. Good afternoon, everyone. This is the Internet Number Resource Status Report. I haven’t done this in a while. I think we skipped it last time.

This is a global picture of all the assignments and allocations that have been done over the past years. It’s prepared by the five RIRs. It’s updated quarterly. So this is pretty recent, actually.

So the first slide shows the status of the IPv4 global address pool. And I usually start up at the upper right corner where it says 35 are not available. These 35 are in use by the technical community and are not available to IANA and the RIRs.

If you move left to the Central Registry, there’s 91 /8s that were issued, what we call the Central Registry. This is really all of the pre-RIR space that was issued under US government contract to the DoD NIC, the SRI NIC, and by Jon Postel prior to that.

Most of the space is dubbed the legacy space, and much of it has been assigned to the ARIN region since that is where most of the growth in the Internet was in the early days.

You can see that the RIRs, the five RIRs, have 130 /8s assigned to them by the IANA, and it’s broken down below. Probably don’t have to read through those. You guys can read, I know.

Then probably the most important data on this slide is IANA reserved in big red letters. There’s nothing left at the IANA, no /8s left. And I should probably clarify. I know there’s IANA people in here, but I’ll clarify for them. There’s some bits and pieces that have been returned to the IANA over the past year or two, couple of years, so I believe they have roughly 1.21 /8s sitting with them right now.

And that will soon be tapped into because there’s a global policy that allows them to issue even equal amounts of space to the RIRs, and that should be happening sometime in the near future.

As far as available IPv4 /8s in each of the RIRs, AfriNIC has enough space, in the left in gray, with 3.25; APNIC has .79 /8s; ARIN, 1.27; LACNIC has .79; and RIPE NCC says .96. So three of the RIRs have already broken into their last /8.

This looks like the IPv4 address space issued to customers over the years since 1999. Most of the growth in the past several years - well, a few years back, actually, was issued in the APNIC region in yellow. And then it sort of changed a little bit, that landscape. RIPE then started issuing more space when APNIC ran out. And now LACNIC seems to be issuing more IPv4 address space than any of the other RIRs.

This just shows the cumulative total of the IPv4 address blocks issued by the RIRs to their customers. And as you can see, APNIC has issued more /8s to their customers than any of the other RIRs.

This shows ASN assignments. RIPE NCC has been issuing more ASNs in their region for many, many years. It still holds true in 2014 for Q1. So we’ll see where that goes. This year’s accumulative totals of the ASN assignments to the customers, with RIPE issuing more followed by ARIN.

This shows the 4-byte ASN assignments. Okay. Let’s see. APNIC - I’m sorry, LACNIC and RIPE NCC were issuing 4-byte ASNs by default. So you can see the colors there that they’ve been issuing more 4 bytes than any of the other RIRs. But recently APNIC started issuing 4-byte ASNs by default as well.

So those three RIRs have issued the most 4-byte ASNs. However, ARIN and AfriNIC are now starting to issue 4-byte ASNs by default.

And we’re not getting - we’re not having many problems. We’re getting some of them returned to us. We were having many issues in our region for a while where people could not use the 4-byte ASNs and they were returning them and coming back for 2-bytes . But at this point we’re all running so low that we’d have to issue 4-byte ASNs by default.

This shows the cumulative totals. So we finally seeing ARIN registering on this chart because - you couldn’t even see us last time. There was very, very few 4-byte ASNs issued in our region.

This is the total IPv6 address space, the/0. We’re working from a /3 right now that’s been assigned to IANA. There is 512 /12s in that /3 in the global unicast space, and only six /12s have been actually tapped into at this point.

One of them was issued - was used early on to issue small bits of space to the RIRs. Since then a global policy was enacted in October 2006. Each one of us received a /12. To date we are all still working out of this /12, but I have heard that a couple of the RIRs may be ready to request an additional /12 from IANA because there is some clear growth, as you’ll see in the next slides, in IPv6 in a couple of the regions.

So this shows that, the IPv6 allocations to the ISP LIR customers. RIPE has been issuing many, many allocations of IPv6 to their customers. And the interesting thing is that it’s now followed by LACNIC. LACNIC is issuing many IPv6 allocations in their region.

So it used to be ARIN and APNIC, but LACNIC has now come in and is issuing many.

When you look at the cumulative totals of all the IPv6 allocations made by the RIRs to their customers, this is kind of interesting because RIPE NCC has issued more in total, more IPv6 allocations, than all three of the larger RIRs - LACNIC, APNIC, and ARIN. So they are really moving that space.

These are assignments, IPv6 assignments, to our end-user customers. And, again, RIPE is issuing more IPv6 assignments. ARIN was at one point issuing more, but RIPE has recently started issuing more.

This just shows the cumulative total. ARIN and RIPE have issued basically the same amounts to their end-user customers.

So we look at how many of ARIN members have both IPv4 and IPv6 assignments. And the numbers are really interesting. On the left, AfriNIC has a little over 37 percent; APNIC, a little over 47 percent; ARIN, 45 percent - that number has actually moved up, so we’re kind of happy to see that; LACNIC, over 65 percent of their members have both v4 and v6; and in the RIPE NCC, a little over 68 percent have both.

Discussion

Leslie Nobile: And that is all I have. Are there any questions?

David Huberman: David Huberman, Microsoft. A little concerned about something you said. You said ARIN is now issuing 4-bytes by default. I thought we had a policy that stated we will treat it as a single contiguous number pool.

Leslie Nobile: We do have a policy that says that, and we have been issuing low to high, which means 2-bytes to 4-bytes. Because we’re running out, we’ve decided to switch that and we are going to be issuing 4-bytes, high to low, instead.

In the ARIN region we’re saying we’re going to issue - I know there’s supposed to be no distinction, but this is reality, right? We have to do what’s right for the customers. We have to make sure this is working. But we’re running out of 2-byte ASNs. So what are we going to do? We’re going to try to do the best we can for both.

So we are issuing - we are telling people we’re going to issue you a 4-byte ASN unless you have issues with that. Unless there’s a technical problem, let us know.

So it’s been working, actually. We get very few back at this point.

David Huberman: My response to that is, first off, I recently got an ASN. I did exchange it. No problems, thank you, exchanging it.

I guess my concern is I would like that to have been communicated by communications to the community because I now have to go back and prepare - that we’re really, really low and we’re about to run out such that ARIN’s decided to change its policy, because now I have to go prepare a whole AS for, hey, guys, you really need to fix this if you haven’t fixed it already. So communication would have been nice.

Leslie Nobile: Okay. Good to know.

Sandra Brown: Sandra Brown, IPv4 Market Group. Leslie, I think it was you who said yesterday that we don’t have a runout policy within ARIN, and you just showed now that we’re down to about one and a quarter /8s. I know within RIPE and within APNIC they have - or they had a last /8 policy.

So what is the status within - or what are you hearing within ARIN about the idea that when we have, say, a new company, doesn’t have any IPs, after runout comes to ARIN, needs IPs to get the business going - I guess Point No. 1 is you have to have IPs according to the existing PPML to get IPs, so that’s Point No. 1 -

Leslie Nobile: For an ISP policy.

Sandra Brown: And Point No. 2 is there’s a restriction, slow start mechanism, you have to - the most you can get is a /20.

And I think Point No. 3 would be this idea within the other RIRs that they set aside such a large block, /8, and we’re almost down to a /8. So it would take ARIN, it seems to me, longer than the time before we get to that last /8 to institute a policy to set aside the /8. So we’re going to be well below the /8 before we can do something.

So what’s the status of putting aside some number of IPs, which of course brings the runout much sooner? So what’s the discussion within the AC or within ARIN about setting aside a block so that there would be something left for newcomers to the market, such as a /22 or /24, to get their businesses off the ground.

John Curran: That’s a question for this room, actually. It’s a policy question. We gave a policy experience report where we highlighted the fact that ISPs who can’t get IP addresses from upstream might find it challenging to get ISPs from ARIN without having already had a run rate of IPs from upstream. So it is a valid issue, particularly for ISPs when we get to runout.

At present we have a block for a very particular purpose, which is transition purpose, and otherwise there is no policy presently that would have ARIN reserving a block for this reason.

So it’s not a question for ARIN staff; it’s a question for this room of whether or not they want to work on such a policy proposal, whether they don’t think it’s necessary.

Leslie Nobile: That’s all. Any other questions.

John Curran: Any other questions for Leslie? Thank you.

(applause)

Internet Governance Update

John Curran: Next up is the Internet Governance Update. I’m actually going to give that, and we’re going to move from that directly into open microphone.

So the Internet Governance Update is - wow, it’s been a busy period of time. I will try to summarize where we are.

As folks know, there’s been quite a bit of attention to Internet governance and the structures that the Internet ecosystem operates under. And, in fact, this actually reached a pretty important moment on March 14th when the US government NTIA announced that it was willing to consider the launch for planning process convened by ICANN to possibly transition its stewardship over the performance of the IANA functions from NTIA to the global Internet community.

And so that was an announcement NTIA indicated it was willing to consider this, and ICANN announced simultaneously that it would be the facilitator and convener of a process to build a plan so that rather than having these functions being performed, the IANA functions being performed under US government contract by ICANN, they would be performed and the oversight mechanism or the stewardship over it would be handled by the Internet community.

Since that time, ICANN has actually announced a timeline for developing that plan. They’ve announced an initial process about that plan. And they have an open call for comments regarding between now and early May about the process we’ll use to develop the IANA stewardship transition plan.

We announced ARIN almost at the same time. Our acknowledgment and support for the announcement of NTIA to have these, a stewardship responsibility, transitioned and indicated that we believe the existing organizations - the RIRs, the IETF, ICANN, the Internet Society - collectively are capable of performing the stewardship necessary by strengthening our existing relationships and our existing roles. That was also announced on the 14th of March.

So we’re in an open comment period for people to comment on the proposed plan that ICANN has helped convene, and then sometime in May they will close comments and actually launch that plan, and we’ll spend probably the next 12 to 14 months developing the accountability mechanisms and the transition process so that the Internet is actually going to be run by this community, and the oversight for that will also be done by this community rather than the oversight being done by the US government.

So it’s a pretty momentous period. But the devil is in the details. And right now we’re at the very beginning of this process. And so that’s the update. If you’ve been on the ARIN website, you’ll see a number of announcements regarding Internet governance. The same with the NRO website, because the NRO coordinated our announcements in this.

And it’s a busy time and that’s where we are, and we have about - for Internet governance in particular, we have the next 10 or 20 minutes to handle any questions you might have. There’s a number of experts in the room; we should be able to address these.

Vint Cerf: I want to make an observation. The term “Internet governance” can be interpreted in a very broad way, covering a broad range of things that NTIA is responsible for. One of the confusion factors in the course of a lot of these discussions I think has been not distinguishing between the scope of what NTIA has done and the general scope of what might be needed for governance of the Internet including people’s behavior on the net, the content of the network, and so on.

And I think this confusion is going to continue. It may very well turn out in the end that we try to winnow down the specifics that NTIA has done and ask how do we accomplish that portion of Internet governance. But there will still be a need for a continuing discussion about the broader range of issues that are not covered by anything that NTIA has responsibility for or anything that we have a responsibility for at ARIN or the other RIRs.

Thank you, John.

Discussion

John Curran: Okay. I see microphones are open. Milton, front.

Milton Mueller: Milton Mueller, Syracuse University and Advisory Council. So, you’re right, this is a very momentous change and it represents kind of the completion of a period of really 15 years since the formation of ICANN. And some of us have been advocating that this happen a long time, and we’ve been thinking a lot about how it should happen.

So the first thing that happened is that the Commerce Department put ICANN itself in charge of convening the process. And some of us thought, well, that’s not necessarily a bad choice, but we all have to recognize that ICANN as an organization, as a corporation, has a bit of an interest in the outcome. They would like probably to retain more of the functions than to not retain them.

And I also know that VeriSign, for example, is very concerned about this transition and they have a certain interest in keeping certain things that they view as risks under their own control.

So it’s very, very important that ICANN convene this process in a very neutral and impartial way. So I was a bit distressed when I saw the scoping document that they recently released in which they said that any discussion of where the IANA functions might move would be out of scope. And it seemed to me that given the fact that the accountability function now performed by the NTIA is at the center of this IANA process, that they contract with ICANN to do certain things and they contract with VeriSign to do certain things and they maintain certain relationships in place.

You take that out and the whole accountability situation is really something we have to think about carefully.

I would like ARIN to at least make it clear that from their point of view we need to be able to freely discuss various proposals as to how to structure these relationships among the different parts of the system as it now stands. The scoping document that ICANN released has tried to foreclose that discussion by ruling major proposals and major ideas as being completely out of scope.

If we can’t discuss where ICANN - where the IANA - the DNS IANA functions go post NTIA, it’s not clear what we can discuss, what a transition plan consists of.

John Curran: Let me make two brief comments, and then I’ll open it up to others who might want to respond up here or at the mics.

First, recognize that was released for comment. There’s a mailing list for comment. There’s a lot of people - it’s not a case where you write your submission and file it in and we’ll all see it afterwards. There’s a lot of people on the mailing list , so you can comment to the effect of “I have comments about the scoping document.” I’m sure that’s going to be seen by a large number of people.

I don’t consider any of the initial documents - they’re initially released for comment, so we should comment. And if that’s your concern, that’s one you should express.

But, furthermore, something probably at the key to this is that in terms of the roles, one of the things that the RIRs and ICANN and IETF and ISOC said is - or at least the leaders, in the case of ARIN, the ARIN Board - is that the roles that are being performed, except for NTIA, which is the oversight role we’re talking about, the other roles we don’t envision moving.

This isn’t a case of - we’re trying to focus on the stability of the system, so we don’t see any reason why changing NTIA’s role means any other role needs to change.

Now, some people may have different ideas, but any ideas you go - because of NTIA’s change, any ideas you go to change the nature of the roles of the system have to be balanced with the stability of the system.

And the I* organizations have come out and said we believe all the existing organizations are doing a fine job in their role and should continue in that role.

I guess other comments?

Milton Mueller: Just to respond to that, though. The roles as currently performed are defined by and supervised by the NTIA. It’s sort of like saying, John, I’ve just contracted with you to mow my lawn. You do a good job of mowing my lawn, I pay you for 15 years. And all of a sudden I say, John, you’re going to continue to mow my lawn, but we’re not going to have a contract. Because you’ve been doing such a good job, I have no need to supervise you anymore and no need to be able to withdraw money from you or anything.

It just doesn’t make sense to me. Right?

John Curran: So that’s an open topic for people to respond to. Back microphone.

John Springer: John Springer, Inland Telephone and ARIN AC. To what extent is ARIN and the RIR system and the NRO involved in the upcoming NETmundial discussions and to what extent is that going to have a bearing on this specific ICANN process.

John Curran: I can answer one of two of those; I’m not sure I can answer both.

The first one, to what extent are we involved, I will actually be at NETmundial. I will be monitoring it. I have an obligation to make sure ARIN can perform its mission. That means watching these developments and apprising the Board and you if there’s anything that endangers our ability to do our mission. I’ll be at NETmundial. I’ll be watching the conversation, and hopefully it will be a productive one and won’t do anything that adversely affects us.

Regarding how does NETmundial interface with these discussions, that’s up to the NETmundial program and executive committee. And I don’t know if that’s been set at this time, yet. I haven’t seen anything if it has. It’s an open question. It’s really NETmundial’s question what they want to consider on or off their agenda.

In the front.

Sandy Murphy: Sandy Murphy, SPARTA. In terms of - shoot. Sorry. Sandy Murphy, PARSONS. Darn it. I’ve said it - so the scoping document is interesting. And the complaints about the scoping document are interesting. NTIA’s statement included a NTIA is not interested in giving up their current role in terms of a intergovernmental body and statement like that.

So I get the sense that NTIA reserves to itself the right to say, well, thank you for trying, but we don’t like that. We’re not going to give up our role.

Is there a place in this process where NTIA is going to say yea verily.

And the pretty picture on IANA’s page that shows a very long timeline ends up with the IANA contract expires. Is there a deadline here, NTIA by that point will say yea verily, it’s good, or nope, try again? When does the transition - sorry.

John Curran: I will give my understanding, the best I have, and it might be imperfect and people who may have read more than I have can correct me.

My understanding is that NTIA has laid out specific criteria, four specific criteria, for the stewardship transition plan. We have to actually have a plan that meets the criteria that we have to present to NTIA for them to be able to say yes, we shall go.

Sandy Murphy: And they reserve to themselves the right to approve or disapprove.

John Curran: I imagine if we present a plan that doesn’t meet the criteria -

Sandy Murphy: According to them.

John Curran: - I can’t imagine them proceeding, so by definition that wouldn’t fly, yes.

And I understand we have some 12 or 14 months before we need to produce a plan. Now, that brings us to a particular date with respect to NTIA and ICANN and the IANA function contract. But that contract also has extension periods. So I do not know if any date is set in stone. I don’t know if 14 or 15 months are necessary to get this job done.

But the fact is that we definitely, if we want to catch this next pass, have about a year and a little more to get the job done.

Sandy Murphy: Right. Right. So -

John Curran: Yes, Vint? Sorry. Go ahead.

Sandy Murphy: Sandy Murphy, PARSONS. Second question. I understand that there was not time between ICANN and this meeting to put this discussion into this agenda. I’m also a little disappointed that the comment period is ending before the RIPE meeting. So the public response is all going to be pretty much the mailing list , is that correct, or are there other fora -

John Curran: There are people from ICANN who are interested in public engagement, and we’re having a discussion about this. So I don’t have anyone - I don’t have any more information regarding the timing other than I see the same dates you do. This is an opportunity to discuss. People have our open mic tomorrow also to discuss. But there is a deadline for getting comments on the process and the initial scope and all of that.

And we have to get past setting the process up in order to move on to following the process to develop the plan.

So, yes, I believe it’s about a month long we have before we have to actually pull the trigger on the resulting plan.

Vint.

Vint Cerf: I’d like to try to add a little bit. First of all, it’s my understanding that NTIA - Sandy, you don’t need to stand there. It wasn’t in direct response necessarily to you, but -

Sandy Murphy: I have a third question.

Vint Cerf: I see. Well, I would like to reserve the right to respond now rather than wait for another question from Sandy, if you don’t mind.

Sandy Murphy: No.

Vint Cerf: First of all, NTIA asked ICANN to conduct a consultation, so this wasn’t ICANN grabbing territory; it was responding to NTIA, as I understand it.

Second, I want to emphasize once again that not all governance and oversight of Internet is in the NTIA scope. There’s a huge amount of governance and oversight that every one of us performs in ARIN and similarly so for the other RIRs and similarly for others who participate in the operation of the Internet.

So we want to be careful not to overstate the scope and importance of the NTIA role as important as it is.

Third, this has turned into quite a hot topic in the American Congress, and so there are all kinds of bills flying around and having potential effects on this. The GAO, for example, is deposed to review this whole proposition from NTIA, and it could take a year to do that which could have a potential impact on the schedule as has been laid out.

John is correct that there are provisions in the NTIA contract with ICANN that would allow it to be extended twice for a two two-year periods. So when the September - end of September rolls around next year, if this is not all sorted out, it’s probable that NTIA would continue the contract with ICANN.

And finally there are rather a large number of other fora in which this discussion is taking place. NETmundial is coming out, as you know, in the third week of April in São Paulo. There’s the World Economic Forum has conducted something which is a two year timeframe. There’s a high level panel which Fadi Chehade set up that I vice-chair, and the Chairman of that is the president of Estonia, and that will be - group will be meeting again in Dubai in May, after the NETmundial happens.

There’s the Internet Governance Forum which will take place in Istanbul in September, which is a fairly large scale event. And the ITU Plenipot comes along in South Korea.

There’s an extraordinary amount of discussion going on all during the period during which the plan and planning process is undertaken. So it’s not as if we’re the only forum in which this discussion is taking place.

Thank you.

John Curran: Your third question, and then I’ll go to the back mic. Go ahead.

Sandy Murphy: Sandy Murphy, PARSONS. The scoping document notes the oversight areas where NTIA practices and includes domain name system and address allocation in that oversight, but frequently in the document it restricts comments, the statements it’s making to the domain name system.

Do they recognize the position in address allocation? One thing says NTIA plays no part in policy development for the domain name system and leaves out address allocation.

John Curran: I’ll let Vint respond, and I may follow.

Vint Cerf: So the answer is that when ICANN was being created, when the white paper came out from the White House, the people there didn’t seem to understand that there was more to the domain name system than just names - or they lumped everything together under domain name system.

I was - I won’t say I was beside myself, but I wasn’t too happy with this lumping together of very different concepts into that one term.

But the answer is that’s what they thought at the time. So, yes, it includes everything, even though most of us would look at that and say you didn’t get this right.

John Curran: There are multiple NTIA documents that say the domain name system, with a footnote down at the bottom that says including protocol parameters and IP addresses as well. Thank you very much. Come along.

So just want to let you - it’s a term of art.

Back microphone.

Joe Catapano: Joe Catapano with ICANN. I am one of the ICANNers interested in public engagement that John was speaking of. So I am the coordinator for global stakeholder engagement for North America focusing on the technical civil society and academic community. That’s part of why I’m here. And I’ll be here the rest of today as well as tomorrow. So please come talk to me if you have questions; I’ll do my best to answer them. If I don’t have an answer for it immediately, I will find it for you. And, yeah, so please come talk to me.

And the deadline for the comment period is - this first comment period is May 8th, midnight UTC.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC, speaking for neither but strictly myself as an Internet citizen.

The present situation with domain names is a bit of a mess, but I don’t care. It mostly works, and I can kind of ignore what happens there for the most part.

The situation with numbers is quite different. Presently number policy is run entirely bottom-up. The community stakeholders get together. And the various RIRs, they work through the policy process in the RIR. Policy gets developed. If we want policy that affects ICANN to get developed, we run around the world in all five RIRs and get them to pass at least substantially similar policy, and then we negotiate the differences and coalesce it into something through the NRO NC/ASO AC that turns into a global policy, and then we hand that to the ICANN Board for ratification. And life is mostly good.

I would hate to see this turn into an opportunity for ICANN to invert that flow of power in number policy. That would be very, very bad.

John Curran: I would consider anything that requires a material change in either how we do policy or how we do global policy to be a risk, and I would be reporting it back to this community for their discussion.

I will tell you, though, of course, this is an open call for input. So your thoughts on this process, what’s going on, the scoping, the document, all of that you should be participating any way, but at this time we don’t see any untoward risk posed to ARIN. If that changes, you will see me coalescing comments collectively and getting the Board to sign off on something we file to prevent any harm from being done.

One other little nit. I just want to point this out. It has to do with keeping an open mind. In the last four months, I’ve had the opportunity to hear someone say: ICANN and the DNS Policy Development Process is the embodiment, it’s the reference implementation of multistakeholderism. It is the best example of it. Followed immediately, almost 24 hours later, on a mailing list of: The IETF is actually the true multistakeholder process and is the best at it. Followed immediately, within about three days, by someone saying: The RIRs are the embodiment of the multistakeholder system.

So we actually all have slightly different systems. They’re all open to everyone. They’re all inclusive. They allow anybody to participate. Some of them have more representative bodies than others. Some are completely flat, almost a meritocracy in terms of the view.

I would not prejudge that the processes being used in any of these areas for Internet identifier management are any better or worse than others. The point is as long as the community supports them, that’s the right outcome.

So just keep an open mind even if they’re different than how they do it than from us.

Yes, Milton.

Milton Mueller: Milton Mueller, Syracuse University and AC. By the way, I would like to meet this person that thinks that the DNSO - or the domain name process is the ideal embodiment of multistakeholderism. But that’s another subject.

John Curran: I’ll send you a message.

Milton Mueller: So I want to ask a very specific question for you, John, and I hope I can get an answer.

So you said that the I* organizations had come up with a statement that basically said we want to preserve existing roles during the transition as much as possible. That’s fine. What I want to know is do you believe that during the ICANN convened process that people who don’t believe that these roles should be preserved, can they advocate that position? Should they be able to advocate a different position? Or should that be ruled completely out of scope?

John Curran: I will tell you that I’m going to give you my personal belief, and I’m going to tell you I had a chance to chat with the ARIN Board about this in the last 48 hours.

This is a public process. Everyone is part of the public. If you’re part of the public and you feel that the process should be different or should have different scope, I implore upon you to comment.

At the point in time that we actually end up with a final process and we actually move from developing the process for the next year to executing that process, then we need to all execute the same process so that we don’t end up running in different directions.

Milton Mueller: You’re ducking my question. There are people who have different views about the roles of the different actors in the current system. Your view and that of many I*’s is it should be pretty much the same as it is now, even though it’s going to change in significant ways. Other people have views favoring structural separation in different ways. Is it out of scope to debate those different views.

John Curran: Are you talking about between now and when the process is set?

Milton Mueller: No, I’m talking about as a matter of principle should there be in the process now, should it be ruled in scope, that you can have different views about that.

John Curran: ICANN has convened the process. They’ve put documents out there. I don’t know what is in or out scope for this comment period. But there are ICANN people here, and you should ask them since ICANN is the convener.

Milton Mueller: I’m asking you.

John Curran: I believe everyone should be able to have any say they want. Absolutely.

Vint.

Vint Cerf: I would just make the observation that there’s no way of shutting Milton up anyway -

(laughter)

Vint Cerf: - and so the consequence of that is that you should and probably will say whatever you want to, and I think that you’re free to do so on that mailing list .

Milton Mueller: It’s not about what you can say; it’s about what’s in scope in the process.

Vint Cerf: No, no, I think that the process will - I hope it comes to a conclusion, and it will have to absorb literally all the input that shows up on that public distribution list. So I don’t think that there’s any limitation as to what you can say. As to what comes out of it, it’s a function of how that process resolves itself.

I guess Sandy’s next.

John Curran: Sandy from PARSONS.

Sandy Murphy: Sandy Murphy, PARSONS. NTIA offered to give up their role and define their role in oversight. They did not offer to give up someone else’s role. They asked ICANN to convene a process to decide how NTIA could transition their role to someone else. ICANN’s doing that. They’re answering that question.

If there’s a larger governance role, that’s something different. Right now ICANN’s convening a process to answer that one question. Nothing says there couldn’t be a parallel process, but this process is supposed to answer that question.

Vint Cerf: So I agree with that basic statement that that was - I believe that was ICANN’s intent. But I do want to reiterate that there are a whole bunch of other parallel processes currently going on addressing a much broader range of issues which could indeed address some of the things that Milton mentions.

Again, Milton is free and others are to say whatever they want to in this ICANN convened process.

But I think you’re correct that its focus was intended to be on what to do about translating the NTIA role into something different that the multistakeholder community could undertake.

I want to also reiterate that NTIA was very careful to lay out its criteria and to say that it reserved the right to reject proposals that didn’t meet those criteria. And I think that’s a - however you might feel about that, it looks on the surface to have been a responsible thing to stay.

John Curran: I’m going to do last call at the mics for Internet governance. Last call at the microphones for Internet governance. Closing in ten, five, three, two - microphones are closed for Internet governance. I see no other questions. Any remote? None. Wonderful. That concludes the Internet governance session.

Open Microphone

John Curran: We’re now going to move directly into open microphone. I’d like to congratulate everyone after two days of policies. Everyone’s done a really great job. The open microphone is available for any topic, and that includes topics such as issues that might have arisen in the consideration of policies.

We do have tomorrow our Member Meeting. We’ll be giving reports in more operational natures to ARIN. If you have something directly related to ARIN operations, I’d ask you hold it.

Microphones are open for any topic. Please approach the mics. This is sometimes our liveliest session, actually.

Vint Cerf: Sometimes not.

Chris Spears: Chris Spears, Internet2. So in the discussion of 2014-11, brought up a statistic from one of the ARIN presentations at ARIN 31, Registration Services Update, where it says that 44 percent of all organizations served by ARIN are legacy, another 44 percent are non member customers, and only 12 percent are ISP members.

So, again, I think Jason Schiller pointed out there is a very complex Venn diagram of the overlapping nature of some of these groups because there are different assets held, but I think that addressing legacy is very important.

John Curran: It’s an important issue. Recognize we do have about 4500 members who are members, ISP members, and that also includes about 500 legacy organizations above and beyond that.

We then have 1400 End-users who are also under agreement. I’m sorry, 14,000 end-users. 14,000 End-users who are also under agreement with ARIN. So that’s why we have a lot of parties under agreement. They’re not members because we don’t provide members to End-users automatically.

And then there’s about 16,000 legacy organizations. And I can’t say that legacy is end-user or ISP, because some legacies you really would consider an ISP and some you’d really consider an end-user. They come in once they’ve signed an agreement effectively looking like a legacy organization with fees similar to End-users and similar.

We have, so if you all total, 36,000 organizations. About 20,000 have formal relationships with ARIN and about 16,000 do not as legacy not under any agreement.

It’s a very important component, but it’s also those people who have relations prior to 1998. Recognize in many cases the counts of those organizations are no longer existing organizations, and so it’s very hard to know in terms of actual organizations how many those are or whether or not they’ve come to ARIN because they have a concern or whether they literally just use their IP addresses and don’t have a need to come and work with ARIN.

I do think it’s an important issue, but the demographic is a very large demographic.

Okay. Microphones are open.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. So this was from a question from earlier. Is there community support for reopening the austerity question? Because I know this has been debated years ago before austerity was really on anybody’s mind. There was a lot of debate, and it was kiboshed, the idea being that the longer we hold out on - and, again, this is my understanding - the longer that we hold out with IPv4 the worse we make the transition to IPv6, and that was the feeling years ago.

The question is: Should we set aside a /10, /11, whatever, a /9 - you pick the number - for new entrants? We’ve done it for IPv6 transitional technology. Is this a benefit to the community, or are we just holding space back for people that could actually use it now.

John Curran: Recognized as a very small - we’re getting down to the end, so if we’re going to do it, we’d have to reserve it pretty quickly. But comments. Yes, back microphone.

Martin Hannigan: Martin Hannigan from Akamai Technologies. I do think we should set something aside, but I don’t think that we should set something aside from the current free pool. I don’t know what you’re expecting to get from the IANA. I believe that there are some resources there that you may get.

And my suggestion would be that - I believe you’ll be exhausted before the next meeting. You won’t be able to get a policy done through the community before the next meeting. That leaves you with potentially using Board powers.

If you were to do such a thing, my recommendation and something that I would support would be that if you receive something reasonable from the IANA, that the Board would take that and set that aside and that perhaps we would - I have no idea how that would work, John. I have no other suggestions than that, but I think that it’s game over at this point and if we were to do something that that would be the way that I think that I would support you.

John Curran: For people interested in this idea, at the top of those steps is a breakout room, the Astor Room. At the back of the room, up the steps, a policy breakout room for brainstorming ideas like this.

Kevin, if you wanted to convene a time - 5:00, 5:15 - and get people in the room, you could brainstorm it out.

Kevin Blumberg: That sounds great. I’ll be there at 5:00.

John Curran: Wonderful. Microphones remain open. The open microphone session.

David Huberman: David Huberman from Microsoft. I have a quick request for you, John, or counsel - you can’t hide.

We do these policies and sometimes we put this artifact of text in them: The receiver must sign an RSA.

And it bothers me a little bit. Can you give us guidance - you don’t have to do it now, but can you give the community specific guidance on whether or not that language is necessary, unnecessary, op, no op, et cetera.

John Curran: Acknowledged. I think we can do a better job in making sure people understand that that language is not needed because it is required in almost every case, and maybe we need to enshrine that in some place so the AC can rely on it.

But it’s a good point. We shouldn’t be repeating it throughout the NRPM and every policy that involves moving of addresses. Thank you.

Vint Cerf: If I can try to support this, but I want to understand what the rationale was. One possible reason for making it appear in one place and making it clear it applies all the time is if you keep saying it, it might give people the impression that there are some cases where it’s not required, and I think that may be part of the motivation for fixing this.

John Curran: Microphones remain open for open mic. Yes, remote participant.

Cathy Aronson: Andrew Koch: There have been several emails on open request to ARIN and priority. Is there any reporting from ARIN on the status and priority list?

John Curran: Can you repeat that just for me? I’m having trouble parsing.

Cathy Aronson: I was going to ask him a question, too.

There have been several emails on open requests to ARIN and priority. Is there any reporting from ARIN on the status and priority list.

Vint Cerf: This may have to do with first - the approved first out or first to arrive and first out, a question about what that meant.

John Curran: I would ask for clarification from remote.

Cathy Aronson: I asked him priority of the suggestions and the suggestions -

John Curran: Oh, suggestions, yes.

Cathy Aronson: - and he said correct.

John Curran: Yes. We actually have very good reporting online. We gave - yesterday Richard gave an update as to the ones that are outstanding right now, and Nate highlighted all the development of what’s gotten done.

All of the suggestions and their current status are online in the suggestion queue. There are some that are - staff are busy trying to figure out how to integrate into a plan somewhere. If there’s a particular one that someone’s worried about, they can drop a note to ARIN-consult and say what’s happening with this or drop it to me, and I’ll be happy to respond. No problem. But we have been knocking them off pretty quickly now.

Chris Spears: Chris Spears, Internet2. I have a question about something that was anomalous in the 2013 report. I don’t know if it’s the right forum here.

John Curran: Sure.

Chris Spears: There was something on the order of a five-fold increase in SWIPs processed in 2013 over previous years. This is on the order of like 2 million SWIP delegations or SWIP templates processed.

Does ARIN have any insight as to what the cause of that was or what precipitated that.

John Curran: Mark, do you want to talk about a five-fold increase in SWIPs.

Mark Kosters: Actually it’s coming out in a report tomorrow, but I’ll be happy to talk about it here. One of the things we’ve had, and I think there’s two parts of it. One is actually templates being processed and the other is RESTful transactions through Reg-RWS. We’re seeing a lot people use a lot of uptick with Reg-RWS, for example.

So people are using that system and perhaps actually starting to update their information a little bit more frequently given that it’s much easier to use. So that’s a hypothesis, but it seems like a pretty reasonable one.

John Curran: Microphones remain open. Yes, center rear mic.

Sandra Brown: Sandra Brown, IPv4 Market Group. John, I’ve been writing for the RIPE area for some time an inter-RIR transfer policy, as you know. It’s being resurrected. As you know, there are not like needs assessment policies between the two regions.

So if and when the RIPE inter-RIR transfer policy is implemented, past implemented and so on, which could take quite a bit of time, what is the thought if, at an operational level, a situation should arise where an entity in North America with no contract with ARIN chooses to engage with a, I guess the right term would be an LIR in the RIPE region and make a private transfer following policy in both regions, so to speak, in terms of how they look at the situation.

Can you comment on that situation and perhaps what we need to do at some point before the policies go too far is go off line with the leaders of both regions and talk this through at a very serious level before it comes to a head publicly and so on.

John Curran: When the RIPE region contacted us to say is the transfer approved, we’d indicate that the resources are in the registry in this region subject to the policies of this region and there’s no approved transfer.

You would not end up with the resources moving as a result, because the resources are subject to the policies of this region, and we would not acknowledge to RIPE that it was okay to transfer. Unless this community changes policy, obviously.

Sandra Murphy: Okay. I’ve seen comments written by some of the leadership of RIPE that says that ARIN has a very small stake in that situation. So what’s your comment if RIPE should choose to follow the policy with that kind of outlook; in other words, they choose to register and you have a conflict? I think, still to my point - I’m not trying to be - I’m being controversial but I’m not intending to.

I think we have a situation where there’s a relative surplus of IPs in North America compared to Europe. And there’s a situation where entities want to transfer IPs and you have a company with no agreement with you that wants to transfer to an LIR in Europe and there’s a situation.

And I’m suggesting that it may be better rather than having an open conflict for the two organizations to talk it through rather than publicly make that statement.

John Curran: That’s actually something for the communities in both regions to talk through, not the organizations. We don’t have a choice in following the policy.

So we’ve been able to maintain uniqueness for decades. I suspect we’ll be able to still maintain uniqueness even in this case. But it’s something for this community to seriously consider. Because obviously it’s a stress point that will occur. And I don’t expect to see any actual problem with duplicate IP addresses, if that’s the concern. Unlikely, but it will be a cause of consternation, no doubt about it.

Center front.

Jose Alvarado: Jose Alvarado. Just a couple of comments on how we’ve been spending the last couple of days on IPv4 and the various policies we discussed more or less today. Seems to me we’ve been trying to, or we’re trying to Band Aid solutions with making or stretching IPv4 as much as possible.

But we need to - I will say that we need to encourage various levels, the adoption of IPv6 as an optimized solution.

Few years ago, 2011, the Internet Society conducted The IPv6 World Day which was an introductory to how things would work.

Later in 2012 there was another event but we’d like to know if ARIN will have any involvement or encourage the players out there to continue with these tests, to continue with this adoption. Because up to today my desk report will show that from at least my network’s perspective, from my ISP that I work for, we only have I guess 0.003 percent of IPv6 traffic. Meanwhile, we are almost by default giving our customers both IPv4 and IPv6 but really they don’t care about the IPv6 today because they don’t have any work to go out today. They don’t see any use for it. It’s like do you want fries with it. So it’s somehow just an add-on. So I guess that’s one of the things.

John Curran: Let me respond to two aspects of that, then I’ll turn it over to Vint. First, recognize that the work in policy for IPv4 is not necessarily to make IPv4 last longer. It’s recognition that people will be seeking IPv4, either through requests to ARIN or through transfer requests and that that will continue even as we get to smaller and smaller, even when we get to runout, people will be seeking transfers.

So it is not a goal to extend v4. It’s a goal to try to face up that the policies that exist when you have a free pool available to everyone and the policies that exist when you don’t might have to be different policy. So it should be expected to surge in policy development related to v4 in and around the runout event, because the policies that apply before and after may have to be different policies.

With respect to v6, ARIN has a huge IPv6 outreach. And we do quite a bit. We participated in the ISOC World IPv6 Day. We were actually involved in both the original day and the follow up day. We go and do trade shows and speak both to the consumer Internet industry and the ISP industry and the enterprise industry to promote, encourage v6.

We by no means are giving up on v6. In fact, the traffic in North America, many people indicated it’s much more successful. We’re seeing now across the board, if you go to the World IPv6 website, you can see, for example, Google’s traffic number which is now up and around three percent, which is fairly significant, and there are select ISPs who have 20 or 25 percent of their traffic is IPv6 today.

So the work on IPv4 policy does not imply ignoring IPv6, it’s that IPv6 policy doesn’t need the same amount of changes because of the event we’re going through.

Vint Cerf: First of all, I agree with John’s assessment. I just wanted to observe, with regard to IPv6. Google was pushed pretty hard to try to get services up and running, all of our services on v6 as well as v4. So many others have also tried. The three percent number sounds like it isn’t much, but I’ll tell you a year or two ago it would have been almost invisible.

You know how these exponential things look: You can’t tell a thing, they look like nothing and then all of a sudden and blam, you hit this knee.

Some of the estimates right now, based on observations, are that we might actually hit 50 percent penetration of IPv6 by 2018. That might turn out to be a significant turning point.

David Farmer: David Farmer, University of Minnesota, with this hat. We’re one of those 25 percentish ISPs and we’re doing over 500 megabits a day peak of IPv6 traffic.

With my ARIN AC hat on, like I said before, not all policies have the same meaning to everybody. I want to be very clear that one of the policies I authored, the 2014-1, Out of Region Use, I could care less about the meaning of it for v4. It’s about v6 to me personally. We need to deploy v6.

And getting this craziness that’s being caused by the v4 runout out of the v6 way is extremely important.

John Curran: Front and center, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. As some of you may know, I’ve had a little bit to do with IPv6 over the last few years.

We’ve actually had a lot of policy development work in the IPv6 arena in just the last two to three years. We pretty much completely rewrote from scratch first the ISP and, second, the end-user policy.

And I seem to recall David and I being the primary people pushing those two drafts up the hill and over the cliff and into policy in the NRPM.

So basically I think that work is largely done and those policies are actually now working relatively well for the community. If you have a concern about the existing v6 policy, please, by all means approach myself, David or any other AC member and we will be happy to help you turn those into a draft so they can get an airing among the community and possibly turned into policy modification as well.

Certainly we have no intent of avoiding work on v6 policy if work on v6 policy is needed. But we have tried to make the v6 policy as good as we can. And we’re continuing to try and adapt the v4 policy to rapidly changing circumstances.

And I think I can speak for many people here when I say that we will be very glad when we don’t have to tinker with v4 policy anymore and in fact can stop dealing with the mess that is v4 all together.

John Curran: Excellent. I’m going to be closing the mics soon. Go ahead, rear mic.

John Springer: John Springer, Inland Telephone, ARIN AC. If people continue bringing us IPv4 policies, we’re powerless to refuse them. If people want to bring us v6 policies, we’re powerless to refuse them.

All the people who have comments about deck chairs and Band Aids, and other rebel balancing type of things, bring us policies you want us to advance; we will. But we can’t stop advancing v4 policies only the community can do that.

John Curran: Center front, Heather.

Heather Schiller: I think he wants to respond. I’m on to something else.

Kevin Blumberg: I believe in another region there was a policy to end policy. So, yes, it would be possible to end policy for a time.

John Curran: But that policy was ended.

(laughter)

John Curran: Heather.

Heather Schiller: Heather Schiller, Google Fiber. We turned v6 on by default for all of our customers.

But on to something completely different. So I’m so sorry, I don’t remember who said it. But sometime yesterday somebody mentioned something about ASNs being used that weren’t allocated.

So my question was, does ARIN monitor basically unallocated things that are have been allocated to ARIN from IANA but haven’t been bogons effectively? So either ISPs or ASNs that you have not yet allocated.

John Curran: Systematically, no. Do I look at the same CIDR and PGP bogon reports as everyone else? Yes. Do I send mail to people occasionally, yes, but it’s not a systematic process.

Heather Schiller: I know the answer. It’s going to be sent in as a suggestion. But, I mean, like - you’re supposed to be stewards of the resources and I guess you do it at the time you go to allocate it, but in the meantime it’s getting used for bad stuff. So kind of like keep up after the stuff you’re stewards of.

John Curran: If it’s being abused for bad stuff - okay, give me a little more detail.

Heather Schiller: If someone goes in, announces a /24 you’ve not allocated and spams from it for 24 hours and then stops announcing it, uses it for other badness, but you’re not pursuing that -

John Curran: Let’s say hypothetically we saw that this /24 was in use and it hasn’t been allocated, continue, that’s A. Now what’s B? What’s the next thing we do.

Heather Schiller: Next thing you do is you find out - if it’s being advertised from an AS that it’s properly registered, you notify the holder of the AS, say this block hasn’t been allocated, please stop announcing it. And then you notify their upstreams as well. If it’s an ASN, you notify the upstreams who are announcing it.

By the way, the people who have like legitimately held ASs, who are the upstreams, they’re also your customers, they should be interested in going after this.

I know from previous experience at a prior employer I would get notifications from hostmasters saying, “hey, you’re allowing advertisement of this block that’s not allocated, we’re about to issue it”. All I’m asking is you do the same thing proactively even on space that you’re not imminently about to issue.

John Curran: Wow. I guess my question is:

You don’t need to send in a suggestion if you don’t want, send an email. Please send me one so I remember this.

I do need to understand from other people in the room: Is that important for us to be monitoring the routing table for misuse of resources and hunting them down? Yes, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric yes.

John Curran: Okay. I see other people -

Kevin Blumberg: I think you should send them LOAs showing that you -

(laughter)

John Curran: I don’t have a problem setting something up to do this and having a team do it but it’s nontrivial to take on that job. I just need to know if you folks think that’s our job, it’s something we can do. Center rear mic.

Matt Pounsett: Yes, I think it’s a good idea. There’s lots of organizations out there that are already monitoring the PBW tables. You could probably just suck in their data and process it.

John Curran: I read some of the reports. But I’m saying to do it systematically, means people paying attention to it every week. It’s not like, hey, John’s looking at the CIDR report tonight.

Okay, front and center.

Andrew Dul: Andrew Dul, ARIN AC. This is slightly different, so I’ll wait until if someone has -

John Curran: No, Andrew.

Andrew Dul: Earlier we talked about the 14,000 direct assignments that are legacy that have no current relationship.

And there was a comment that some of them are probably what I’ll call ghosts. Has ARIN actively identified which ones are ghosts and which ones are not ghosts?

John Curran: No. Center rear mic.

Rob Seastrom: Rob Seastrom, ARIN AC. I have a question for the people who want ARIN to proactively look for stuff that’s not announced that should not be, et cetera. The question is: What do you propose ARIN do about it. Sort of and then what?

John Curran: Remote, Cathy.

Cathy Aronson: Kevin Otte, Flying Penguin Technologies. Would the community support policy that requires organizations to have IPv6 allocations in order to seek further IPv4 allocations; that is, we’ve been trying the carrot, do we need to try a small stick?

John Curran: Austerity policy, 5:00, Astor room. Kevin is in charge. Everyone who thought about revisiting that, actually actually he’s going to be at the top of the steps on the right. Center front.

Sandra Murphy: Sandra Murphy, PARSONS. The response to your previous comment: Will there be remote participation in the room right up the stairs?

John Curran: No. Breakout for people who want to have a discussion here and do it someplace other than the bar from an orderly meeting, less orderly meeting.

Yes, front and center.

Sandy Murphy: This is me entertaining my info junkie. Andrew brought up the 14,000 end-users. And Leslie and her statistics feed my addiction.

The ARIN XXX report on registry services noted the RSA coverage in terms of address space, not Org IDs. And 50 percent of the address space in the database has no formal relationship with ARIN, which is a different way of characterizing it.

It’s by population. Uniqueness: Uniqueness is presently guaranteed by the willingness of the five different RIRs and their policy and execution of policy to maintain that.

We did have one occasion - I say we - ASN numbers. There was a conflict. It caused a whole lot of consternation in the community and some changes in execution of policy to make sure that didn’t happen again.

John Curran: I agree. A good reason to work for policy alignment.

Sandy Murphy: If it should ever happen that one RIR deliberately did such a thing, the world would fall apart. So I certainly hope it never happens.

And I forget what the third one was.

John Curran: We should avoid the world falling apart. Thank you. Microphones are open. I’m closing them shortly.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Being a little more serious than my LOA comment. The problem that I face with the discussion is that the solutions that I see are operational solutions like the IRR database as an example.

One of the things might be for ARIN to provide a BGP feed for members that included a list of ARIN bogons that it was actively seeing or, depending on how much you can compact, it, a list of ARIN space that was not addressed. As it started getting used, you could remove it out. I don’t know if it would be practical or not. Again it’s an operational way to deal with a problem.

John Curran: I actually get some of that right now from other reports, not from ARIN, but from other organizations.

So organizations that wanted such can get that today. You’re saying there’s a difference if ARIN issues it.

Kevin Blumberg: Yes, there’s a trust and there’s also a cost difference.

John Curran: Okay. Front and center.

Heather Schiller: Team Cymru provides such a list. They proved a nightly list of bogons from all five RIRs, of space that’s not currently allocated from the RIR perspective, which I guess is not really - well, it’s not really empty.

There’s a short list of RFC 1918 space. But there’s a more granular list of this space has no entry in the RIR database.

In response to the question about like what I would expect ARIN to do, I think that a lot of times that providers just don’t know. And that I found it helpful in my old position of being at a very large provider to get this notification that said, oh, hey, by the way, you’re doing this and you might not even be aware of it.

Some providers may not actively be monitoring the bogon lists. I think it’s a friendly heads up that says can you take care of this and, by the way, you can remind them when they ask you for space, hey, by the way, you’re allowing this bad thing to happen.

John Curran: I do know providers pay attention because I’ve gone through the list, sent individual emails, and you folks realize: If I send you an email, you should respond.

It does work. I probably wasn’t going to send them all out myself, but we’ll have to work on that.

Go ahead, David. Sorry. Rear.

Andrew de la Haye: Andrew de la Haye from the RIPE NCC. Wanted to answer about the last comment. We have created the RIRs the excellent delegation stat files, which contain all the address space, which has been held by the RIR, including what is available, what is being reserved and what has been issued. So those, for example, could be used for this kind of situation.

John Curran: Center front.

David Huberman: David Huberman, Microsoft, as I earlier said. I’m a little concerned about our community’s level of participation. I started participating in the ARIN community in 1999, as a staff member, and back then there was a really high level, in my opinion, of operator participation and of really technically good input.

There were a lot of folks who built the Internet who participated in ARIN in a meaningful way, at least when I got here.

I’m worried right now, we’ve seen statistically a bit with Leslie’s NRO and with your presentation, we might not be sufficiently representative of the entire community that ARIN serves.

John Curran: What do you mean by that?

David Huberman: Here, I’ll get to it. You asked about ideas. Well, we’ve got 14,000 RSA signers; is that correct?

John Curran: Yes.

David Huberman: How many are members.

John Curran: We have 4500 folks who have signed RSAs who are members, ISPs. We have 1400 End-users who are not members.

David Huberman: And the ASN holders.

John Curran: Sorry, 14,000 End-users who are not members.

David Huberman: Then there’s the how many legacy holders.

John Curran: About 16,000.

David Huberman: We have 30,000 and 4500.

John Curran: Correct.

David Huberman: Throwing out ideas out here, because you asked for solutions, trying to throw solutions.

Would it help if those 30,000 folks were afforded membership? Would more people think they could be brought into the fold if they had membership, including voting rights.

John Curran: That’s a great question. The other side of the problem, if you afford membership - now we have 15 percent of the 4500 members, we get between 14 and 15 percent at every election. Extremely high turnout. But we’ve worked over time to do that.

A lot of ISPs look and say: As long as I have my addresses, I don’t actually have - I’m not going to vote, I’m not going to show up. So you can add 10,000 more people and say they have the opportunity, but the reality is that they already have the opportunity; you don’t want to avoid them membership and say you’re a member if it’s not something they have an interest in participating in.

David Huberman: 15 percent of 1/7th vote. 6/7ths don’t have a vote. Some of them have an opportunity because they may be ISPs and have direct allocations, but the vast majority have direct assignments or AS numbers.

John Curran: And for $500 they can be a member and vote if they wish.

David Huberman: I would probably assert in my experience most don’t know that. My question is - it doesn’t have an answer. It’s really rhetorical. It’s for thought.

We need a way to bring more people into the fold. I understand the argument that we can only do so much and people have to show up, right, but I don’t think we should just give up on what we’ve already done. I think we should keep trying new things. One of those new things may be is give more people automatic membership. At least some have signed an RSA. Maybe it will bring them in. Maybe it won’t.

John Curran: Given the participation and the policy meeting is open to everyone - and we don’t have 4500 people here, it’s hard to say whether we’ll have a bigger room. But it’s a point worth discussing, I agree.

Center rear mic.

Matt Pounsett: I think you’ve just done what I was going to do which is to point out that membership is not something that’s required to participate here.

While it might be worth discussing, I’m not sure what kind of outcome we might expect in terms of public policy participation from handing out more memberships.

John Curran: Okay. Center front. I am closing the microphones soon. Go ahead, Owen.

Owen DeLong: Owen DeLong, org ID DeLong Z. ARIN AC.

Speaking as the proprietor of DeLong Z, a legacy holder that did sign the LRSA, does not have an ARIN membership, does not get to vote for the AC, does not get to vote for the ARIN Board as DeLong Z, I’m not willing to pay a $500 poll tax just to vote for the Board and AC.

Now admittedly I personally cast three votes in most elections for Board and AC, but those are related to other organizations for which I’m the DMR also.

John Curran: I assumed it was because your heart was pure. But I’ll take your explanation, okay.

(laughter)

Owen DeLong: We’ll go with that too. But in terms of the way the rules work, it’s because I’m the DMR of membership organizations.

I would like actually to see DeLong Z afforded the ability to vote. I do not think that DeLong, another Org ID which I’m the proprietor and DeLong Z should get separate votes or memberships necessarily, but I do think that as a resource holder I should be entitled to vote on the people that are administering the policy process and the people making the decisions how the organization is run.

I pay my fees like everybody else, and I don’t see why I should be subject to an additional $500 poll tax that the ISPs are not subject to.

John Curran: You pay reduced fees like everyone else. But, yes, acknowledged. Okay. Center front.

Closing the microphones in 15 seconds. Go ahead.

Sandy Murphy: Sandy Murphy, PARSONS. I’m embarrassed to notice that I seem to have missed the proper point to ask this question during the NRO report.

I make it an unpleasant practice to ask this question during the NRO report at every RIR meeting I attend. And that is:

The NRO sent a message to ICANN requesting some dialogue about the operation of the global trust anchor for the RPKI. And, gee, how’s that going?

John Curran: It’s going slow. In fact, in the case of ARIN, we have, as you heard, moved resources significantly away from RPKI for this year to catch up on our non-RPKI work, because last year was our RPKI year and pushed everything else. It is going slow. I do know some of the other RIRs are working with the team at ICANN, the IANA team, and there is a lot of work to be done because we need to document how this will work.

We’re still committed to it. We’re not currently actively pushing resources at it.

Sandy Murphy: Timeline.

John Curran: I don’t have a timeline off the top of my head. But I’ll talk to Mark.

Sandy Murphy: Thank you.

John Curran: I’m closing the mics now. Mics are closed. And the last comment, Elise.

Elise Gerich: Elise Gerich, ICANN. I just want to compliment ARIN on the ARIN On the Road sessions you do. Those of us at ICANN, Leo, Felina and I that come to these, we rotate. We don’t all show up at all of them.

I went to the ARIN On the Road in Portland where you did it with NANOG. It was really well attended. New faces and new voices. I think it’s a really good outreach activity that you guys are doing. And I wanted to thank you for it.

(applause)

John Curran: The praise is to Susan whose brain child and idea behind all that. Thank you very much. I do think the program is successful.

This concludes the open mic session. That concludes our program for the day. I think I have final slides.

Closing Announcements And Adjournment

John Curran: Oh, look at that. Thanks for our sponsor: ServerCentral and RCN. The next slide will say thank you to Google for the webcast.

(applause)

John Curran: I’m slow, but I can be trained. And so meeting guests. There is a list info, you can subscribe if you want to coordinate your transportation to the airport regarding tomorrow and exiting.

We also have a meeting survey. You’ll get an email link if you have the ARIN 33 event app you’ll get a notice there.

All responses received by April 23rd will be in a lottery for an Xbox One. So worth thinking about.

Reminders: We’ll start tomorrow, the meeting at 9:00. Breakfast at 8:00 a.m. The meeting is open to everyone, member meeting, give a status of the organization but everyone’s welcome to attend. You can see the materials for it online.

That is it. I’m told it’s warm and sunny, 80 degrees outside. Everyone enjoy the evening. And I’ll see you tomorrow. Thank you.

Network Sponsors

Webcast Sponsor