ARIN PPC at NANOG 59 Transcript - 8 October 2013 [Archived]

“This transcript of the PPC 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 Announcements

John Curran: Okay. If people will come in and be settled, we’ll get started. We’re going to get started in just a moment.

Okay. Good morning, everyone. I’m John Curran. I’m the President and CEO of ARIN, the American Registry for Internet Numbers. And today we’re going to have a Public Policy Consultation at NANOG.

So I’d like to tell you what exactly that is. It’s where we hold a discussion to get input for developing policies for use for Number Resource administration.

It is in‑person and facilitated by remote participation. We have scribes set up. We hold these at ARIN policy meetings and other forums like NANOG, as approved by the ARIN Board.

Today’s agenda, we’ll give you an update on the ARIN Advisory Council activities. And then we’re going to go through three policies, Recommended Draft Policy 2013‑4: RIR Principles; Draft Policy 2013‑6: Allocation of IPv4 and IPv6 Address Space to Out‑of‑Region Requesters; and Draft Policy 2013‑7: Merging IPv4, ISP and end‑user requirements.

Welcome to our remote participants. We have a webcast of this. There’s a live transcript. You can download the meeting materials, which includes the Discussion Guide that we’re all holding here. There’s a chat room online, where you can participate in the virtual microphone and participate in the show of hands.

Rules and reminders: Okay. Simple courtesies. The Chair, in this case Vice Chair Paul Andersen, will moderate the discussion of the Draft Policy so everyone can speak and everyone be heard.

State your name and affiliation when you’re recognized at the mic. Please comply with the rules and courtesies in the Discussion Guide.

Okay. At the head table, Paul Andersen, Vice Chair and Treasurer; myself; Chris Grundemann of the ARIN AC; Dave Farmer, over here; Scott Leibrand, over here; and John Sweeting, right here.

Okay. And this is ‑‑ I’ll be the Staff representative. Paul will moderate the discussion.

John is the Chair, obviously. And our AC members are going to be talking about the various policy proposals.

So first one is update on Advisory Council activities: John Sweeting, AC Chair.

Update on Advisory Council Activities

John Sweeting: Good morning, everyone. I also would like to recognize Rob Seastrom, on the far end down there, running the jabber. He wasn’t on the list. He snuck up.

All right. Good morning. So update on Advisory Council activities.

So at the current time, there are no proposals on our docket. And we have three Draft Policies, one is a recommended draft, and the other two are just regular Draft Policies. The difference being the recommended draft can be sent to Last Call following these meetings this week.

Part of what the AC does and what we need your feedback on to help us determine what to do with these Draft Policies and what the next step is for each one of them, is we need your feedback to help us figure out if they’re fair, technically sound, and supported by you, the community, and Einar.

At the AC meeting on Friday, we’ll be taking all that feedback and evaluating the three policies.

As I said, the recommended Draft Policy for the RIR principles that will be eligible to go to last call ‑‑ of course there’s other things that can happen to it. It can be abandoned. It can be left on the docket where it can then be petitioned to go to Last Call or abandoned after, I think, 60 days.

But don’t quote me on that. Check the PDP. And then the two Draft Policies, the allocation of IPv4 and IPv6 to out‑of‑region is still in progress and would have to go to another meeting before it could go to Last Call, and it would have to be promoted to a recommended Draft Policy before that.

Next meeting being the PPC at NANOG in February. And the same thing with the Draft Policy ARIN 2013‑7: merging IPv4, ISP and end‑user requirement. That is also a work in process, which also can do any of the things I just mentioned about the other Draft Policy.

That’s all the slides I have, but I would like to take a second to remind everybody that the ARIN elections are happening this week, and the AC will have five of the positions open for the elections. And I’d also like to at this time congratulate Chris Grundemann on his recent move over to the Internet Society.

(Applause.)

John Sweeting: And thank him for his three years on the AC, because he has chosen not to run again. So for all the stuff on the elections and nominees and all that stuff you can find it all on the ARIN site.

And please go to the ARIN site. Check it out. Check out their bios. And also if you support any of those currently running, please leave a statement of support for them prior to the elections. Thank you.

Oh, any questions, I guess? I’ll answer them.

John Curran: Any questions for John? Thank you, John.

(Applause.)

Recommended Draft Policy ARIN-2013-4: RIR Principles

John Curran: Okay. So we’re now going to cover the first policy. This is a recommended Draft Policy.

Recommended Draft Policies have been deemed by the Advisory Council to meet the requirements of good policy. They may be sent to the Board for adoption after Public Policy consultation.

This means a recommended Draft Policy is potentially a very soon new future policy, something worth considering.

And so the one that we’re talking about today is 2013‑4: RIR Principles. It originated in April 2013 as Proposition 187.

The AC shepherds are Chris Grundemann, Cathy Aronson and Owen DeLong. It was accepted as a Draft Policy in May.

It was presented at NANOG 58 at another ARIN PPC. It was revised in July and August. The Staff assessment was prepared in September. The AC recommended adoption in September. And it is online and in your Discussion Guide.

Staff summary: It adds text to the NRPM which codifies guiding principles for the registry system, adds registration conservation, routability and stewardship.

There’s a new status at other RIRs. There’s a similar proposal at LACNIC: Principles governing distribution of Number Resources, LAC 21302. Purpose: To group the principles governing the distribution of Internet Number Resources in a single initial paragraph. You can see it online here.

Staff assessment: Staff notes the proposal does not appear to exchange any existing Staff processes or procedures. Inclusion in the Policy Manual will make it more clear to the community the principles under which we’ve operated. We note that registration, conservation and routability already exist in the NRPM. But the term “stewardship” is new for the Number Resource Policy Manual.

Note that the ARIN PDP contains the following: Principles of Internet Number Resource policy. Internet Resource Policy must satisfy three important principles: Specifically, fair and impartial Number Resource administration, technically sound and supported by the community.

Additionally, there are principles in RC 7020 which refer to allocation pool management, hierarchical allocation and registration accuracy. So both our Policy Development Process and IETF RC7020 have some principles via applicable overlap.

Minimal impact: Updated guidelines and Staff training.

Legal assessment: Does not create a material legal issue for ARIN. Any effort to accurately incorporate in writing the concepts that animate ARIN’s activity is a positive development.

PPML discussion: No comments since being recommended for adoption. The earlier comments include comments such as all three previous principles must be balanced with one another and stewardship is a principle which informs that act. Don’t call it stewardship, call it what you just called it, balanced; better yet, curb from NRPM 638 and tell us how to weigh the three principles. Is this intended to be a global policy?

So that’s a couple of comments on the list and Staff introduction. I’ll turn it now over to the AC to do the policy presentation. Chris.

Chris Grundemann: Thank you. Excuse me. So as John indicated, I’m going to talk a little bit about what ARIN 2013 is.

A clear definition of the common principles and goals which guide our community, was the intent here.

Obviously placing those into the NRPM so that they can be owned by the community and that also provides an established change process. We understand how to change policy within the ARIN region.

So placed there where it’s easy to get to where it’s very clear what they are and in the future we can also move forward if we need to.

The principles as defined are registration, conservation, routability and stewardship. So starting with registration and routability, there seems to be pretty wide consensus on both on what they mean and on the fact that they’re needed.

So registration is basically the database entry itself to ensure uniqueness of the number space and routability then is handing out address space in a way that allows for scaleable routable Internet. Not necessarily guaranteeing routability but helping as much as possible.

So one of the conversations that came up was around conservation and what that means and if that’s the right term. And so I wanted to start with just a little kind of plain language, English language definition of what conservation means.

And here from dictionary.com: Prevention of decay, waste or loss. The careful utilization of a natural resource in order to prevent depletion.

And then from the Science dictionary I think it’s fairly clear it says, the protection, preservation, management or restoration of natural environments and so on.

And I think that can be applied to a public environment such as IP space or ASN numbers just as well.

The kind of counter‑argument was that sustainability was a better term. So I wanted to look at the definition of that here as well. So sustainability says the ability to be sustained, supported, upheld or confirmed. And sustainable is capable of being somehow supported or upheld as having this great born from below.

We look at these two ‑‑ going the wrong way. Went backwards. Sorry about that.

So we look at the two together. The objection was that because the free pool of IPv4 is depleted, the conservation is no longer the wrong term; you can’t consider anything because it’s gone, and now we’re looking at sustainability. And I think the response that I’ve seen is that sustainability is actually more of a property of a resource, whereas conservation is the activity of providing sustainability.

And so they’re not really opposing viewpoints, they’re kind of orthogonal and different meanings.

So conservation still seems to be the right principle to include and the right word to use. And then a couple more notes that were made was that we’re not conserving the free pool.

So whether or not the IPv4 free pool is empty, not to mention the fact we’re also talking about ASNs and IPv6, which have lots of free addresses, lots of free numbers left.

But we’re not protecting just the free pool, we’re protecting the number space as a whole. So the free pool was actually a buffer against abuse in the past.

So if somebody was hoarding addresses or using addresses in a malicious way, there was a safety valve to allow more addresses out into the Internet. And so once that free pool rolls up, conservation actually becomes even more important in a lot of people’s view.

And then, finally, just the statement that IP addresses are a public good. So stewardship kind of requires conservation, which is protection, preservation and management of that resource.

The other word that came up in the last comments was “stewardship” and whether or not stewardship was what we really meant there.

Again, dictionary.com said it’s the responsibility overseeing and protection of something considered worth caring for and preserving.

I think that sounds exactly like what ARIN, both the organization and ARIN, us, the community, is doing with number resources.

So within 2013‑4, stewardship becomes the overarching principle that kind of guides and both allows for and requires flexibility and balancing the other three principles.

Those principles need to be balanced differently for each resource type. IPv4, IPv6 and AS numbers are all somewhat different, trade‑offs there, and each unique situation is a little bit different.

So aside from the principle of stewardship, there’s a whole lot of detail of how to actually effectively meet these principles.

And that’s what the entire NRPM is for, specific policy for specific situations, for just these top-level principles.

So one thing to point out here is we’re not changing any principles with this policy. The idea here behind this proposal when it was submitted and the conversation that’s gone on the list since then is that this is like putting the principles in a place that’s easy to find that provides clarity to the community as to what those principles are.

And again, per the Staff assessment, this doesn’t change any practice at ARIN. This actually isn’t an operational change required by these. It’s just defining the principles themselves in a clear and easily findable place and also a place that’s owned by the community, rather than outside of it in the PDP or in an RFC somewhere, it’s actually in the NRPM, which is this community’s document.

Also, if the principles need to be changed over time, right, that’s something that can be addressed separately once they’re defined and clearly marked, as they are today.

So we define the principles as they are today. And in the future we can come back and it actually becomes easier to change if needed.

With that, I want to pause. And again in response to some of the comments on the list and from the Staff assessment, there’s a couple of changes that we’d like to propose after this meeting, because we’re in a text freeze, so we couldn’t make them before the beginning.
One is around the question of whether or not it’s a global policy. It was suggested that we change Internet Registry System in the title of the policy to ARIN itself, because these policies obviously are specific to ARIN, and so that’s something that we’d like some feedback after this meeting on, on that change.

And then also the example within stewardship, the Staff report says that might be unnecessary and better handled within the specific IPv4, IPv6 and ASN sections, which probably need to be cleaned up after this is put in place anyway.

So with those two changes, that’s what we’d like to discuss.

John Curran: So our Vice Chair Paul Andersen will moderate the discussion. The microphones are open.

Paul Andersen: Microphones are open. I know it’s early in the morning. This policy, the AC is looking to see that there’s a clear community consensus.
We can only do that if you approach the microphone, state your name, your organization and whether or not you’re in favor or against and any other comments you’d like to make. Center mic.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I’m in support of this proposal. I’ve read it a lot, seen t the discussion a lot. And when you are talking about especially about the dictionary definition, it sort of tweaked ‑‑ not tweaked ‑‑

Paul Andersen: What a visual.

Kevin Blumberg: What I do note is each definition from the dictionary had multiple bullet points, what they could be.

You put three people in the room and three people will pick three different bullet points. Over time, those bullet points change, their meanings change, how people interpret them change, and it becomes a sliding thing that you go from one word to one of the two examples to how that person perceives that example. And my only suggestion would be to possibly adding in the specific definition.

Paul Andersen: Into the policy text itself?

Kevin Blumberg: Into the policy text itself to not have any ambiguity as to which of the specific meanings you have.

Paul Andersen: Any feedback?

Chris Grundemann: Advance two slides. In the last version of the text, the first sentence in each one of the four sections, provides what would be the NRPM definition of each of these words, so what these words mean specifically for the NRPM.

It’s not the broad, full level definition. But like in this case the principle registration guarantees the uniqueness of Internet Number Resources. That’s what we’re talking about. Registration is about guaranteeing uniqueness of Number Resources.

If you go on to the next slide real quick. The conservation guarantees sustainability in the Internet through efficient utilization.

So we tried to do that somewhat. I know it’s not quite a full definition, but do you need something additional?

Kevin Blumberg: Talking about the sustainability, it would be twisted over time. And this wonderful discussion we’re having today will not translate five years from now, or it will get morphed five years from now because it’s meant to be a long‑term goal, saved ‑‑ not saved, but right.

Paul Andersen: Thank you for the feedback. Again, center microphone.

Owen DeLong: Owen DeLong, ARIN AC, Hurricane Electric: I support the policy. I do think that adding a few keywords that are ambiguous to section two would be a potential improvement as long as we don’t go too far overboard with defining every word. In general I support the policy as is and I would support the admission with that addition.

Paul Andersen: Thank you, Owen.

I would ask you again ‑‑ I know you all don’t want to rush the microphones at once. It’s simple enough just to say I’m in favor or against.

You don’t need to make any comments. But the AC is looking for clear feedback on whether or not there’s community support. So I’d encourage you to approach the microphone now or start typing remotely if you wish, and ‑‑

John Sweeting: Prefer people other than the AC?

Paul Andersen: I wasn’t going to say it

John Sweeting: But I will.

Paul Andersen: Again, this policy will be soon going to potentially considered by the AC for Last Call.

David Farmer: I’d also be really interested in anybody’s comments that isn’t going to be here for the follow‑on ARIN meeting. This is your opportunity to let us know what you think.

Paul Andersen: Are you approaching the microphone, sir, or just taking a walk? It’s hard to tell. He’s going to the microphones. Whenever you’re ready.

Andrew Sullivan: I am Andrew Sullivan. I work for Dyn. The microphone back there has a big echo so I’m coming up here.

I guess I support this policy. The truth is my real reaction is ‑‑ I don’t see a big advantage to it. It codifies the number of principles. When you start to codify principles, of course, then this is a massive opportunity for later arguments about principles. And that’s actually my biggest concern about it; that this is a denial of service for some future policy development just sitting here waiting to go off under our feet in the future.

That’s really my own reservation. But apart from that, the principles seem fine.

Paul Andersen: Supportive or unsupportive? Thank you.
Next gentleman.
Mike Joseph: Mike Joseph, Google. I support this policy. I think it does an important job of capturing the guiding principles for the policy work we do.

Particularly in light of the changes to 2050. I think we should amend the policy as is so we can capture them now.

Paul Andersen: Thank you, sir. Any remote comments, R.S.?

Rob Seastrom: No remote comments.

Paul Andersen: Most of the comments so have been in favor. Anyone who wants to speak against or give any reason why the AC might not want to advance this policy?

If you wish to approach the microphones, I ask you do it rapidly, it’s almost time to close the microphones. Going once, twice. Start typing quickly on the remote. Closed in the room.

Seeing none, I’ll call it closed. It’s now audience participation time in that we would like to take a poll of those in this room.
And if you can hear the sound of my voice you are allowed to vote. So please do. I’m going to ask first for those who are in favor of the proposal as written and those who are opposed to the proposal as written. So I will first just look for a sign that our counters are ready and armed. I see the thumbs up.

So online, please vote now. And those in the room, if you are in favor of the proposal as written, please raise your arm high. Keep it up. Stretch break. Going to do this three times, so you can practice with both arms.

Okay. You can put your hands down. Those opposed to the policy as written, could you please raise your hand nice and high. Going once, twice. Give us a moment.

Our crack team of tabulators are ‑‑ on the matter of 13‑4, all those in favor, 28. Against, 0. Total number of people in the room, both in the room and remote, 80.

Feedback is being provided to the AC as we speak for their consideration. Thank you.

Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors

John Curran: Next policy to discuss is a Draft Policy. Draft Policy 13‑6: allocation of IPv4 and IPv6 address space to out‑of‑region requesters.

Originated as ARIN Policy Proposal 189 in May 2013. The shepherds, David Farmer, Bill Darte and Martin Muller. Accepted as a Draft Policy in June. Revised, September.

The Staff assessment came out. It was revised again and it is online and in your Discussion Guide.

The policy requires requesters to provide proof of legal presence within the ARIN region and demonstrate that a majority or plurality of their technical infrastructure and customers are within the ARIN region in order to qualify and receive IPv4 and IPv6 resources.

Staffs at other RIRs: In AFRINIC, AFRINIC resources are for AFRINIC service region and any use outside the region should solely support the connectivity back to the ARIN region.

APNIC, no specific policy text. In LACNIC, there’s a proposal, principles governing distribution of Number Resources. The Number Resources, number and resources under the stewardship of LACNIC must be distributed among organizations legally constituted in service region and mainly serving networks and services operating in the region.

External clients connected directly to main infrastructure located in the region are allowed.

RIPE: Membership is open without conditions. Staff assessment: Legal assessment of the 4 September version. Formalized as ARIN’s existing practices with respect to requiring the requests to have a legal presence in the ARIN region and operate a network in the region would create a new practice and processes via inclusion of the statement of plurality of resources requested from ARIN must be justified by technical infrastructure and customers located within the ARIN service region.

This could create a scenario where a network cannot get IPv4/v6 addresses from any RIR since we would require plurality. And it’s possible, depending on your network distribution, you wouldn’t qualify for a new allocation from any RIR. Unclear on how the location of hosting customers is defined. The customers, one place. The servers in another place. If it’s virtual server, that’s where the problem may come up, because the virtual server doesn’t have a physical presence.

There are potential implications with respect to IPv6 and the proposed policy text in particular: Does the community want an organization to get all the space from one RIR when it comes from IPv6.

So that was the Staff assessment. Legal assessment: It does fill an important gap in ARIN’s policies. It provides policy guidance that clearly describes the degree to which our proposed recipient of Number Resources from ARIN has to reinstitute installations and customers in the region.

From a legal standpoint, we want to avoid the extremes. We don’t want to have an inadequate policy guidance that would leave it subject to Staff interpretation. But we don’t also want to have overly prescriptive guidance. So in the middle is a good place.

And this seems to be in the middle. In particular, the current text, plurality of resources requested from ARIN, must be justified by technical infrastructure or customers in the ARIN Service region.

Should be carefully evaluated. It sets a policy requirement of plurality that may be unnecessarily restrictive in some cases.

A lower standard is recommended to otherwise avoid valid requesters for address resources from being precluded from obtaining Number Resources. Note the policy language which provides reasonable restrictions and meaning a real presence and clear intention to make use of the resources in the region.

It can be adopted without creating a serious legal risk. Kind of a long review. But policies that create circumstances for ARIN to say no tend to get longer legal assessments than others.

Work in progress. This is still ongoing. So we’re really talking about what improvements can be made or if it’s ready to go. And it’s been posted to PPML and presented for community discussion, of which there’s been a bit.

Is it fair and impartial? Is it technically sound? Is it supported by the community? We will do a Staff and legal review once we get the next revised version from the AC.

Recent discussion: Let me see how recent this is. Relatively recent discussion. Plurality is a precisely defined mathematical concept. The part I have a problem with is the network located within the ARIN service region. As far as law enforcement agencies are concerned, the problem is not so much a question of depletion of IPv4 pool, but traceability.

Maybe ARIN’s policy should be consistent regarding the allocation of both v4 and v6 addresses requesting that stakeholders have sufficient attachment to the region prior to receiving addresses from ARIN.

And ARIN 2013‑6 would be a change to existing policy, would make clear that customer growth in region would be necessary to justify a request, where presently we have some folks requesting resources using nominal equipment within the region and backed by extensive customer growth external to the region.

Okay. That concludes the Staff introduction of the policy. I’m now going to bring up the AC to speak to it.

Paul Andersen: Let’s start out with a quick discussion of what the problem is. And as John mentioned earlier, right now the existing operational practices are fundamentally based on Section 2‑2’s definition of a Regional Internet Registry.

This really isn’t the policy. This is simply a definition of what an RIR is. But it’s the only thing that staff really has any guidance in the NRPM to create its practices.

And so there’s really no clear policy that defines who is eligible to referee sources under ARIN and under what conditions.

Do we want to fix that? For the most part, the intent is to formalize existing operational practice.

But as we’ve gone through the discussion, I’m not going to say that it’s clear we don’t have consensus, but it’s not obvious to me that somebody’s paying close attention that we have clear consensus for the operational practices. Otherwise I think this discussion would be pretty easy.

I’ve pointed out on the list, and on the list there’s actually a video clip with a timestamp reference. A lot of people think that, and I think mistakenly think, they can’t use ARIN resources outside of the region, but there’s nothing in policy that clearly states this one way or the other. And it’s not a stretch to interpret Section 2.2 as saying you can’t.

So the current text I’ll read here real quickly, but it’s on the screen and in your discussion guides. Organizations requesting Internet Number Resources from ARIN must provide proof that they, one, are an active business entity legally operating within the ARIN service region, and, two, are operating a network located in the ARIN service region.

In addition to all other applicable policy requirements, a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region. And located outside and any located outside the ARIN, any located outside the region must be interconnected to the ARIN service region.

The same technical infrastructure or customers cannot be used to justify resources in more than one RIR. So there’s really four major parts to this policy, the presence in the region, some amount more than a trivial amount of resources must be justified from within the region, a plurality.

Something I’m going to talk about is should that be lowered to a minimum percentage. And then there’s out‑of‑region use is explicitly allowed. It’s clear now that you can use resources out of the region, but there’s some requirements about infrastructure being interconnected, et cetera, and that there’s a plurality of it inside.

And then the same customers or infrastructure cannot be used to justify overlapping requests. Okay. So let’s talk in detail about the presence within the region. There’s really two parts to this. The sort of legal operation and then a network. Current operational practice is the business entity needs to be formed within the region. This relaxes that to any business entity legally operating within the region.

So this would mean an entity formed in another RIR’s region can get ARIN resources for use in the region, et cetera.

This was a concern that was raised. This addresses that concern. And then you need to be operating in network in the ARIN service region. I think that’s kind of self‑explanatory. If you’re not operating in the network in the ARIN region, what are you doing asking ARIN for resources?

So out‑of‑region use. The policy explicitly allows out‑of‑region use. The current lack of clear policy here is unclear and confusing. I’ve got to revise that. Clear and unclear in the same sentence ‑‑ okay. Many people ‑‑ as I said before, many people assume they can only use ARIN resources within the ARIN region, even if this is not the technically superior solution for them or the Internet as a whole.

A number of people in the example I asked, provided on the list, there’s a number of people saying can they get IPv6 for their global enterprise and do they have to get resources from all five RIRs. This would mean you have to have five prefixes when one might do.

That’s going to create some routability issues, eventually. Out of the region ‑‑ in the out of region should be interconnected to the region. The idea here is discrete networks in another region should use that region; in other words, not connected to the ARIN region, they should use resources from the other RIR.

Overlapping requests. Again, this is fairly explanatory, but there were some questions brought up on the list. One is here. Basically the intent here isn’t to prevent a Web server or router, some sort of technical infrastructure from having addresses from two different RIRs. It’s obviously going to be necessary in some cases from a router perspective.

So we’re not trying to get too locked down here. So some help with this language could be ‑‑ would be very useful to me.

So here’s the key question we have in front of us. The current language uses a plurality ‑‑ I have problems with that word ‑‑ and it requires that basically more of the ARIN‑issued resources are used in the ARIN region than any other region. But there could be a total of more ARIN resources used outside the region.

Then the other option would be minimum percentage. This would relax that a little bit and would require a more than trivial amount of ARIN resources used within the ARIN region. 20 percent seems reasonable. This just comes from that would be the smallest plurality you could have. But this would mean you could have more resources in another RIR than you’re using in the ARIN region. I know some people have problems with that. I personally don’t.

So a couple of other issues. Current operational practice is that individuals cannot receive allocations or assignments. This is what we want. There were some questions of that on the list. And there was no intent for this to be retroactive. The AC comments in the AC comment section, this is made clear and just calling it out here. And the policy has no intent to require an overall plurality but how new requests justified. I think this actually addresses one of the staff comments. But ‑‑ and so the big question is plurality versus minimum percentage and if we do minimum percentage what’s the right one. I highlighted 20. Your thoughts. Ready for discussion? Vice chair will moderate.

Paul Andersen: The AC and shepherds are looking for any input that might be useful and whether or not you think in general this is a good idea to be pursuing or not. So, once again, please approach the microphones, and remote participation, and we’ll start with center microphone, please.

David Huberman: David Huberman, Microsoft Corporation. I don’t think that’s the big question. And I think the reason I completely agreed with what you said in the beginning which is you don’t have a good feel for whether or not there’s consensus or lack of consensus, and I think the reason is because we’re discussing the wrong thing. In 1997 ARIN was formed, right? And from ‘97 to about a year or maybe a year and a half ago, this wasn’t an issue.

And the reason this wasn’t an issue is if you operate a network in the US or Canada or the Caribbean, you came to ARIN. You operated it in the Netherlands or Germany, you went to RIPE. If you operated it in Asia‑Pacific you went to APNIC. It was all very clean and very easy. But then the APNIC ran out of addresses. They will move to their last /8 policy. And it made things difficult for the growing economies that exist in APNIC.

The genesis of this policy proposal comes from staff experience which states that organizations of the Asia‑Pacific region are petitioning ARIN for addresses for use primarily and in some cases exclusively by customers located in Asia‑Pacific with equipment mostly located in Asia‑Pacific who are using routing tricks to get around some of the rules that the ARIN staff have created to try and keep the registry system fair. So the question is, if you’re an ARIN region network, do you want the addresses, the two /8s of IPv4 addresses that are available to you today to remain available to you as an operator in this region or do you want them to go to the next network in line, regardless of where they’re located. Because the folks in Asia‑Pacific are coming over and taking significant amounts of addresses. I believe Mr. Curran posted to the list the other day ARIN has fulfilled 52 requests of more than a /11. That’s an eighth of a /8. And they’re going to keep coming, we all know that. The economies, they are growing fantastic.

So, bottom line, are the addresses that are available in the v4 free address pool ‑‑ are they for ARIN region customers or are we agnostic to that issue and are they for whoever needs them. The policy on the table isn’t perfect, but I support it in principle. It needs some wordsmithing. I have full confidence in the AC to take care of the wordsmithing.

Paul Andersen: You said we were asking the wrong question, though, you said we’re not supportive of the policy.

David Huberman: I just stated I’m in full support of the policy. I think it has some wordsmithing issues, and the AC has my full confidence that those wordsmithing issues will be taken care of.

Paul Andersen: Thank you, then. Any comment? Go to the next slide. In the center.

Andrew Dul: Andrew Dul speaking for myself. I do not support the policy as written. I do not support the inclusion of the plurality statement or any sort of procedures. I support the legal entity of the service region, being put into policy, I don’t think it’s our duty to stop RIR shopping because it’s going to happen regardless of how many hurdles we throw up.

So let’s provide services to legal entities within the ARIN region, and at this point this policy or this issue will I believe likely go away once ARIN runs out as well.

Paul Andersen: So you’re supportive of the problem trying to be solved, but you wouldn’t solve it ‑‑ you would want that text revised.

Andrew Dul: That’s correct. Drop all the plurality and the network requirement followed.

Paul Andersen: Before you run away, hold on one second, one of the pieces I put in the early part of what the problem is, is it’s not clear anywhere in the NRPM whether you can use ARIN resources in region or out of region. I think that’s a problem.

Andrew Dul: I do not believe that’s a problem. We should not be telling networks where they should be or shouldn’t be using the address space. If they’re a legal entity in the ARIN service region and wish to obtain address services from our region, then they should be permitted to do so and operate their networks as they see fit.

David Farmer: The problem I see with it is that a bunch of people are making an incorrect assumption that they can’t use them out of region. I think a little bit of guidance that it’s perfectly okay to use them outside of region is in order.

Andrew Dul: I think if you want to put that in policy, that’s different than having it in the best practice or something else. Maybe that’s a better place for that type of information.

Paul Andersen: Thank you for your comment. We’ll go to a remote participant next.

Rob Seastrom: We have a question from Frank Bulk, actually two questions. The first question is: This proposal was drafted by law enforcement. Does the proposal, as currently written, meet whatever their reasons were for drafting this proposal. I’d like a response from the shepherd before I ask that question.

Paul Andersen: The shepherd’s response, their consultation with the original author on this.

David Farmer: My understanding of the latest discussions I’ve had with them is they support this ‑‑ the plurality standard wasn’t what they had in mind originally, but they understand the change and why the change. And they basically support it as written ‑‑ well, the latest changes haven’t heard on them, but there was some minor intent changes, only like two or three words. So I will summarize saying, yeah, I believe they support it as written.

Paul Andersen: Second question.

Rob Seastrom: Second question is Frank notes that posted on PPML this morning what if Akamai Hosting, Inc., located in the Silicon Valley found a niche offering virtualized servers for Asian customers who want to have their Internet‑based services hosted more closely to North American market, Akamai Hosting and their infrastructure are clearly in the US, but their customers are not in the ARIN region. Does this policy as currently written preclude Akamai Hosting from requesting more address space as their Asian customer base grows?

Paul Andersen: John Curran?

John Curran: I just responded to PPML on this, and the complete answer is there, but the short answer is under the current policy they may request additional addresses as the customers grow. They’re virtualized, their customers are virtualized host. Under the revised policy text we have not considered their customers were not in region, there’s a side effect there. People who are doing hosting with virtualized equipment for customers outside of the region have no new customers in region and have no new equipment, and so that side effect would mean that they would not qualify for additional address space.

I’ll have people think hard about whether or not you wish to have addresses issued to any virtualized things as they tend to be spun up pretty quickly, and so the constraints of virtualized equipment that’s actually not supported by customers is very difficult to administrate.

Paul Andersen: Very correct. Far microphone.

John Springer: I’m John Springer, Inland Telephone, ARIN AC. In thinking back on the genesis of this process, the original concern of law enforcement was that they weren’t able to put the arm on people, not that the resources were leaving the region.

And it’s my recollection, and I’ll be happy to be corrected, that this whole process of plurality and resources remaining in the region is sort of an artifact, the development process. I don’t like it.

In terms of keeping resources within the region, we gave back nearly a /8 a while back. If we were going to try to keep resources in region, we might not have done that. I think anybody with a legitimate use for addresses should get them. We should be going to v6.

So ‑‑

Paul Andersen: So you’re not in favor as written?

John Springer: I like to be in support of law enforcement, but, like I say, the original concern was being able to get ahold of resource requesters, and they were finding situations where they were fictitious and/or had no ‑‑ not enough English‑speaking skills in order to determine any sort of standing.

So I appreciate the amount of work that’s gone on in this and I commend specifically David Farmer for his rigor in this process. We should all take a lesson from his book on developing the process. But, no, right now it needs more work, and I do not like the business about plurality.

Paul Andersen: We’ll get a quick response.

David Farmer: Plurality ‑‑ the original text from the authors have majority of a full 50 percent. Plurality’s relaxing that a little bit. I think the feedback I’ve gotten on the list is that should be relaxed down to a minimum percentage. And the reason for any of those majority of plurality or a minimum percentage is to ensure there’s some reality to the request and there’s some reality of the basis in the region.

And so because you’re right, they’re worried about fictitious requests, and so some analysis of the actual request in that there’s some basis in reality in the ARIN region is the purpose for majority, plurality, or a minimum percentage.

John Springer: May I respond?

Paul Andersen: Very, very quickly.

John Springer: Again, I believe that the law enforcement is anxious to get their hands on people, and they don’t care what the method is. And I suggest that the method that they have suggested might be less valid than some other members.

Paul Andersen: Center microphone.

Owen DeLong: Owen DeLong, Hurricane Electric. I generally support the policy. I do think it’s not quite ready for prime time and needs some work, especially in light of the virtualized comments. I do have a concern, though, and that is that a lot of the conversation has centered around how the policy affects the v4 free pool. Correct me if I’m wrong. This is currently a draft, not a recommended draft, correct?

Paul Andersen: That is correct.

Owen DeLong: So this policy is unlikely to affect the v4 free pool, even if enacted. Because it’s going to be at least six months before it gets to the point of being reviewed at a meeting as a recommended draft, which means eight to ten months before implementation.

In eight to ten months, we are unlikely to have much of an IPv4 free pool based on current trends.

Paul Andersen: ARIN does not make predictions on such things, but John might have some words of wisdom on that.

John Curran: I’m looking for Geoff Huston in the audience. Geoff, do I have eight to ten months or don’t I?

Paul Andersen: Mr. Huston, do you have a prediction by chance?

Geoff Huston: You have about 16 to 17 months because I’m assuming that IANA is going to hand back its 20 million addresses, so that gives you until January the 3rd, January the 4th of 2015.

John Curran: At 3:00, tea time.

Paul Andersen: Thank you, Oracle Huston, for that.

Owen DeLong: So we have maybe six months after this policy is implemented that there’s still some free pool for it to affect. My argument is that that’s not much of an IPv4 free pool for it to affect. On the other hand, this policy will have significant impact on IPv6 and IPv6 distribution. And with the increasing level of things that are being virtualized, I think that the side effects on virtualization merit very, very serious consideration prior to implementing this policy and that there is much work to be done not just at the wordsmithing level but the actual intent level before we actually put this forward as a recommended draft and put it into practice, lest we shoot ourselves in the head.

Paul Andersen: Not supportive of the text but supportive of the cause, so to speak?

Owen DeLong: Yes.

Jason Schiller: Jason Schiller, Google. I oppose as written. I think there’s a lot of confusion with regard to this policy. It’s been said a number of times that this policy really doesn’t change the ARIN current practice. And we heard this morning about a use case of a virtual hosting provider offering services to customers that are in Asia and how under current policy it was allowed and under this proposed policy it would not be allowed.

I think there’s other use cases where the ARIN practice will change. I think what would be the most effective way to move forward is to talk about a number of use cases, how the use cases are today, and how they will be changed, how you propose they should be changed in the future.

I think the origin of this discussion started with the observation that there was an Asian tunnel provider that was providing tunnels to Asian customers and that they today under ARIN policy are permitted to get addresses because they have two tunnel ladders in the US and LA.

And I think really what we need to do is fundamentally step back and say, do we want to prevent this type of customer from getting resources from ARIN; is the community nodding, yes, we do or, no, we don’t.

And that I think the next step is to figure out if you do want to block that use case, how do you block that use case without blocking other use cases?

Paul Andersen: With unintended consequences, so to speak.

Jason Schiller: My big concern is for those networks that are truly in global in nature and where they truly have a significant presence in the US and truly have a significant presence outside the US, how do those companies continue to operate a global network? And I think the policy as written very negatively impacts them.

My understanding today is if there’s a global network that is in part in the ARIN service region and you’re using those addresses, in that global network that is in part in the ARIN service region, that those are justified.

It’s unclear to me if that’s still true with this new proposed policy, because I can read it two different ways and it can be parsed two different ways and mean two different things.

Paul Andersen: Mr. Curran?

John Curran: So as noted in the staff assessment. This formalizes some things we’re already doing with respect. Legal presence is something we’ve already asked for. Use in the region with respect to routing we already asked for. And this codifies something. It does think a change to existing practice, which is the part clearly called out in the staff assessment, which is when we ask you for customers or equipment, we will clearly be asking for customers or equipment in the ARIN region. So global network will suddenly have to say what am I supplying that is in the ARIN region if I’m asking for ARIN addresses.

So there’s very definitely a change in practice, because of this text, and people ‑‑ off to the side ‑‑ is that appropriate or not.

Paul Andersen: I direct you to the Discussion Guide where the staff assessment details some of that. Did you want to discuss responding on Jason’s comment? Not at this time. Thank you, Jason.

Going to R.S., a remote participant, please.

Rob Seastrom: We have a remote question from Anthony Delacruz. What does or would the guidance look like on a US‑based company that has also international sites? Since folks assume they’re not to be used outside even though that’s permitted but not explicitly written, allowed or denied.

John Curran: One more time, please.

Rob Seastrom: Certainly. What does or would the guidance look like on a US‑based company that also has international sites since folks assume they’re not to be used outside even though that is permitted but not explicitly written, allowed or denied?

John Curran: So to answer the question I think I heard, again, this is at the time of request. At the time of request your international sites would not be counted for purposes of this. Neither would ‑‑ international being outside of ARIN region since we have 25 economies in our region if you count all the Caribbean ones. But outside of ARIN region, those sites’ end customers would not be counted.

Once you received addresses, we’re unlikely to note how they’re actually used. If they’re used in a way that clearly doesn’t match what you told us and someone notes that fraud report or something, then, yes, you could actually be up for resource review and have them taken back, that would be bad. But in general we’re only talking about the allocation of resources.

Paul Andersen: Thank you, quick commentary, then we’ll try to get ‑‑

David Farmer: John, you said they wouldn’t be counted, and they need to be counted, it’s just that they can’t be more than what is in the ARIN region.

John Curran: Right. To be clear because of the plurality requirement or majority or whatever you end up implementing, they are counted. They’re not counted on the positive side of the numerator.

Paul Andersen: Next question from the center mic.

Victor Kuarsingh : Victor Kuarsingh, Dyn. As an original question, I would probably prefer the plurality being used versus minimum percentage. I would prefer the word plurality used instead of minimum percentage because minimum percentage, I think there would be a lot of debate as to how that’s cogitated, how it’s calculated, how do you ascertain what size is, and there will be a lot of unique ways of dictating it.

The other quick question based on what Owen said, I agree you need to understand the impact of virtualization. I know that there seems to be a lot of skirting around that issue, but virtualization is ‑‑ you’re talking about ‑‑ although it’s virtual in nature, it’s a real element within the Internet systems. It actually has a use within the Internet system so it has to be considered within the Internet system. Respective of how it exists, it does impact the Internet system. We have to consider that. Because how this is going to survive into the v6 world, we have to consider that, in my opinion.

Paul Andersen: Victor, for the direction the text is taking, in favor or against?

Victor Kuarsingh: Supportive in general of the cause. I think there’s a lot of work to be done to make sure we do the right job here. Because this is going to impact a lot of folks for a long time, well beyond the v4 pool.

Paul Andersen: Thank you. All right. John and then ‑‑

John Curran: Just one. Note that we presently handle people just fine who do virtualization, who manage IP address pools. It’s not a problem. But because it’s possible to say this customer has five servers, 50 servers, 500 servers, we have to make sure things are credible.

If your past record in customer growth and your past use of DSLAMs and (indiscernible) addresses or Wi‑Fi nodes, we know how to average dynamic pools.

So it’s not that we don’t take them into consideration. The point I want to make is that organizations whose business model are highly virtualized, right now we spend time asking ‑‑ we just asked for their customers, and we can normalize that to determine what their address demand is.

In cases of a company that’s highly virtualized where the customers are outside the US, there will be an impact. So we don’t worry about it now. It’s not a problem with ‑‑ about virtualization, per se, it’s a problem about adding criteria about what customers are supporting that demand.

David Farmer: Intent of the minimum percentage isn’t just to put that word in. It’s minimum percentage X, and we need to figure out what X is.

Paul Andersen: Thank you.

Dani Roisman: Dani Roisman with SoftLayer. I thought I understood the proposal before this discussion began, but now I’m more confused as to what we’re trying to do. My understanding, what I do support is a policy that mandates use, plurality of use within the region. I don’t necessarily know that I understand whether or not the organization to which the addresses are assigned ‑‑ I don’t understand why the organization has to be an organization that exists within the region and registered within one of the ARIN region countries.

I think it’s perfectly legitimate for a region, for a business, an organization, to do their business offshore outside of the country that wanted to expand their business into the ARIN region, Canada United States, et cetera. So how will this proposed policy affect a business that doesn’t necessarily have a registered organization within the ARIN region, but does intend to purchase servers or provide hosting or whatnot on equipment that is located within the ARIN region.

John Curran: So, remember, there’s two different ways that that organization in the past ‑‑ so two different ways that organization is going to be looked at. In the past, if we didn’t count customers and infrastructure and we weren’t looking at the location in the region, then we would look at their growth, like, for example, if they were in someone else’s datacenter and using their prefix, that use of IP is the track record we go from. It’s still possible it doesn’t impact them.

But the other point to make is that over time, when an organization is moving in to a brand‑new organization moving in to this region, if they have nothing here, then it’s slow start and that’s what it’s about. They get an allocation, they grow over time. So unless they’re on someone else’s infrastructure and they are using their IP addresses, we’re going to look at them as a brand‑new organization with no history.

That may be unfortunate, but it’s the fact of restricting them to what’s in this region.

Paul Andersen: Does that address your concern?

Dani Roisman: No, no, because it sounded like, from what I picked up the last 15, 20 minutes, sounds like we’re precluding an organization. The organizations themselves aren’t registered for business in the region from actually receiving ARIN addresses.

John Curran: Organizations that can operate in the region, legal presence means you need to have organizations very quickly set up shell companies, very quickly set up a shell corporation. As long as they’re a legal entity, and then we can provide them IP addresses. We’re not talking about changing that. That’s existing practice. Existing practice is you have to have a legal presence in the region. We’re codifying that in the NRPM, however, by doing this in the policy. This doesn’t change the practice, but it does make it explicitly. We already enforce that because of our own definition of being an RIR set to serve organizations in the service region.

Dani Roisman: So my support would be for a policy that allows ‑‑ that mandates that the plurality of use ‑‑ the resources needs to be in the region, but I do not support codifying that the organization receiving the resources must be a legal entity.

I think based on the way the global dictionary is working you don’t need to have a legal organization, for example, in the United States in order to do business on the Internet with equipment in the United States using infrastructure service providers.

Paul Andersen: Thank you for the feedback. Others may want to address that. Next in queue waiting patiently.

Mike Joseph: Mike Joseph, Google. I oppose this policy. As we see here, we definitely need clarity. There’s certainly a lack of information available about what ARIN and operational practices are in this area. And we’ve seen a lot of questions raised this morning. But I would point out that this policy doesn’t seek to answer them very well if we’ve already had in the course of 20 or 30 minutes a lot more light shed on what this policy really does.

If this policy isn’t clear enough for us to understand without John’s clarification, then it just isn’t clear enough.

Moreover, the policy creates circumstances in which a provider may not be able to get addresses from any RIR, particularly imagine the case where one RIR chooses to require the presence of equipment in their region and another such as ARIN chooses to require the presence of customers within their region. In that case such a provider would not meet the following criteria for either RIR.

I think we should work hard to try not to adopt policies that would make it impossible for a provider to acquire resources and finally it puts restrictions on the operation of otherwise legal entities within the ARIN region. Imagine a US‑based provider who now has to decide whether or not they’re going to accept customers outside the US simply because of this policy. And not only have to make that decision but then has to further track and monitor that utilization.

It creates ‑‑ it requires that provider to act with restraint in the form of how they engage in their business activities. And I think that’s a really unfortunate practice for ARIN to sort of push forward on their members.

So I would oppose this policy. I think that doing something to curtail the hemorrhaging of addresses may be reasonable but certainly not as written.

Paul Andersen: Thank you for your comment. John, very quickly, then we’ll take one more at the mic.

John Curran: I want to respond to a prior speaker, which is with respect to getting addresses from ARIN, in order to execute an agreement with ARIN, you have to be an organization. And you’re going to need to execute an agreement to get addresses assigned. So I’m not sure we can go as virtual as one might want. I just want to point that out. The legal team isn’t going to sign with an entity it can’t confirm.

Paul Andersen: Thank you, John. Center mic again.

Aaron Hughes: Aaron Hughes, 6connect in this case, small business owner and service provider of anycast services in many countries, and I have ARIN resources. Thinking about this, in terms of a v6‑only world, I’ll just ignore v4 for the moment, I think the impact of this is unknown. I am not in support of anything that stifles an organization, certainly not in support of anything that stifles the growth of virtualized services or anycast services, and I can think of a number of use cases where this causes significant problems in providing services that are good for the global Internet. That’s all. Thank you.

Paul Andersen: Thank you. Remote participant, please, R.S.

Rob Seastrom: Frank Bulk has a comment in response to a previous speaker many back. While existing policy doesn’t preclude ARIN resource holders from using address resources out of region, ARIN members should know that current practice is for ARIN staff to ask if all the address space will be advertised in region. And from my perspective ‑‑ that’s from Frank’s perspective ‑‑ that’s too restrictive.

So if the proposed policy as currently drafted does not receive broader support, ARIN staff does need to review their current verbiage, which John has already promised to do. If after review ARIN’s current practice does not substantially change, something ought to be done from a policy perspective to line up the ARIN community’s perceived policy flexibility with ‑‑ this does not make any sense ‑‑ with prefixes with actual staff practice.

Paul Andersen: Thank you for that comment. Center mic again.

Andrew Dul: Andrew Dul. I came into this meeting sort of roughly supportive of this general gist of this proposal with some reservations about details, but I thought we could fix it. And this conversation has actually convinced me this is a bad policy and we shouldn’t pursue it.

Paul Andersen: Should or should not?

Andrew Dul: Should not pursue it. The worry that I have is essentially that it boils down to hard cases making bad law. Seems to me we’ve got a lot of cases here that this thing is designed to clarify and what we’re going to do is make solid rules that we can’t sort of decide, oh, well, this is an exception case and we need to do something about it.

If you wrote a policy such that ‑‑ and there are a lot of exceptions and it would effectively not be a policy at all, therefore we shouldn’t have a policy about this and instead we should have much clearer staff practices around these things with sort of an idea of how to be flexible in those cases. Because every single example here at the mic has been, oh, what about this case with like someone over there but they have this thing over here and also they do the tootsie wootsie on Thursdays.

And seems to me those are all compelling examples of a problem that if you make this policy that’s all encompassing you’ll end up with a big problem. I don’t support the policy.

Paul Andersen: Nor do you support pursuing the problem, so to speak.

Andrew Dul: Not as a policy matter, no.

Paul Andersen: Thank you.

Peter Losher: Peter Losher representing Internet Systems Consortium. So I’m one of those weird corner cases. We obviously ‑‑

Paul Andersen: You specifically or ‑‑

Peter Losher: One of many. Anyway, so we operate at a root server and we have many allocations from ARIN. So we deploy those in areas where we can’t get local space, because of policy.

So we would like to say expand into Africa, but AFRINIC’s policy says you must have a legal entity in that region. So in theory what we would do is use ARIN space.

So under this proposal, I’m not 100 percent sure if critical infrastructure is exempted from it or do we need to be worried about it? Because otherwise I would be strongly against this proposal as currently stated.

Paul Andersen: Thank you for that.

John Curran: I need a minute to look at that.

Paul Andersen: I just ask before you go, we’ll have to wrap this up soon, so we’ll close the mics. I’d ask you if you wish to make a comment you start typing madly into your browser or approach a mic. Next.

David Conrad: Would it be possible to display the policies of the other RIRs on this, specifically APNIC and LACNIC ‑‑ I’m sorry, AFRINIC and LACNIC policies, if it’s too hard?

Paul Andersen: Say when.

David Farmer: It’s in the staff portion.

David Conrad: I actually agree with Dave Huberman here that the question that’s being asked is sort of the wrong question. If you look at the RIRs with remaining free pools, you’ll see they have policies that essentially require in region use of address space. If ARIN does not have a similar policy, that means that people who are currently out of address space, namely folks in the AP region and European region are going to descend upon ARIN like locusts because they’re the only ones with a free pool that is relatively easier to obtain than in the other two regions with address space.

That obviously implies that folks within the ARIN region for which that address space was originally allocated will run out of address space sooner than they would otherwise.

If people are aware of that and that’s acceptable, then the policy should not move forward in some modified form or another. If people feel that that isn’t the intent of the RIR system, then something similar to this policy, maybe not this exact implementation, or description, might be worthwhile.

Although, I do actually note Owen has a very good point in the fact that this may be rearranging deck chairs into fractal patterns, and that’s probably not a useful way to spend your time.

Paul Andersen: Thank you, sir. Mr. Oracle.

Geoff Huston: Geoff Huston, APNIC staff. I’m neither for nor against this proposal. But I would note that I’m one of the folk who over many of the years had to defend the RIR system. And the one particular venue we’ve had to defend it the hardest has actually been in venues where nation states have traditionally done this role. And the argument that we’ve gone through is that the Internet removes barriers. It removes barriers to trade or removes barriers to activity. It gets rid of a whole bunch of artificial sort of impediments to doing business.
And you heard folk doing virtualized services. I put up staff here. I have customers there. And this is the way it’s worked. Why don’t we have just one registry? And logically I suppose it would be consistent, we just do one. Why do we have these regional registries? We’ve argued in those spheres that this is all about better service. Service in time zone. Service in language. It’s about providing folk who need addresses the ability to do so efficiently and quickly and they can use them wherever they want, because that’s the way the Internet has worked for them and for us and for you.

Think very carefully about what you’re going to do for the next 14 months of v4 and what you’re going to have to live with for the rest of your lifetimes and everyone else’s. Because if you provide a signal to nation states that addresses are not just regional but national assets, you’re going to find it very hard to defend a system that says, well, if you get addresses from this entity you can only use them in that location. Because nation states say: Really? I didn’t think it worked like that. But if that’s the case, why shouldn’t I do it, too?

And, as I said, if someone had to defend this system in many places I would actually argue that what AFRINIC and what LACNIC have done maybe needs a little bit more thought in those venues about what they’re trying to achieve, because in the long run, if what we really want is an Internet that removes artificial and insane barriers to activity, to just doing good business on the Net, then maybe these kinds of restrictions around addresses make the problem we’re trying to solve with the Internet so much harder. Whether you’ve got 12 months left, 14 months left or eight months left or even three months left ‑‑ so what?

Paul Andersen: Thank you. The microphones are now going to be closed. Jason, you’ll be next, but first ‑‑

John Curran: Just to get back to the past request regarding the applicability of the proposed policy text to requesters for critical infrastructure. It would be applicable to requesters for critical infrastructure as written. It’s a general guidance regarding people requesting resources. Unless otherwise exempted by provisions of the policy text, it would apply to all requesters for resources.

Jason Schiller: Jason Schiller, Google. So I previously discussed about how concerned I was about the confusion involved and different edge cases and how they get space and how they command the new policy. But I want to talk about one in particular. That is the case where you have a global network where there’s a significant portion inside the ARIN service region. I want to do things like have consistent addressing. They want to use the addresses throughout their network. They want all of the loopbacks for all data devices in the US as well as Europe and Asia to come out of one block. They want a number of point‑to‑point ranges. They want customers to come out of a specific block. Is it the intent of this policy to no longer allow global networks to use ARIN addresses throughout the network to serve customers and infrastructure in the ARIN region as well as outside the ARIN region? Because my understanding is today under current ARIN practices, the global network that is in region, part of a company that operates legally in the US can get addresses that are used in the US as well as outside of the US footprint.

Paul Andersen: Any quick response?

David Farmer: I would say it’s not the intent to prevent it. It’s the intent to limit the scope of it. I think what the plurality clause would be. So there will be some cases where entities will have to get resources from more than one RIR. That’s basically what this is saying. But that I would think the vast majority of use cases should be able to fit inside the plurality clause.

Jason Schiller: To be clear on the plurality clause, today, out‑of‑region use by out‑of‑region customers on out‑of‑region equipment, that’s part of the global network that’s in region is counted as utilized.

John Curran: Correct.

Jason Schiller: Under this proposal that usage would not count towards plurality.

John Curran: Correct.

David Farmer: This is where John and I disagree a little bit. It’s utilized ‑‑

John Curran: You know how that works. As it turns out, you’re not the one answering the requester. The policy proposal as written, as written, it’s infrastructure or customers. And so when we look at that, out of region because of the policy text would not be counted. It would be counted in your total request, but it would be not considered favorable for the plurality measurement. So existing organizations currently using ARIN as their global source of IP would potentially be impacted if their network is predominantly lobed outside the region.

Paul Andersen: I would say if there’s text and staff interprets one way, that’s the trump. If the AC disagrees with interpretation, they should probably clarify it a little bit.

David Farmer: What I was going to say, disagree with the way he characterized it.

Paul Andersen: Jason first.

Jason Schiller: I think it’s pretty clear the text is not clear enough and needs a lot of work. The other portion I’m concerned about is where is the customer located. And I don’t know how to define that. If I’m a transit provider and I have a T‑1 that goes to Tempe, Arizona, is that where my customer is? What if the bill gets sent off to the headquarters in Spain, is my customer in Spain?

And it gets even more complicated when there’s no presumable connection to the customer. If they want to host their server in a colo that’s in LA, is my customer in LA because they brought their equipment to LA even though their home office is in Spain? Or is my customer where the bill gets sent? What if my customer’s in Spain but they set up an office here and send the bill here, is my customer now here in the ARIN region?

I’m not really sure where the customer is. And I think it becomes even more complicated when you look into virtualization and anycasting. How do we deal with the case where my customer wants to provide a service but they want that service to be in every datacenter worldwide?

Paul Andersen: John Curran.

John Curran: I explained this on the list. We’re going to ask you for the customers who have IP addresses assigned to them statically. We’re going to ask where it’s signed and what equipment that’s on. And that’s pretty easy to do. For customers that don’t have addresses, statically assigned to them and they’re in a dynamic pool, we ask where that pool is located.

Jason Schiller: So if I have a T‑1, static customer, my edge router is in New York, and I statically route that IP space to my customer port in New York and the far end of that T‑1 is in London, my customer is in New York because that’s where I’m routing the static route to?

John Curran: It’s not having to do ‑‑ we ask you to give us a customer list, and we ask where those customers are. For most transit providers, those customers are providing us the customer location, the other end of the link.

Now, since we don’t spend a lot of time worrying about customer locations, because we haven’t had to worry about this, it’s never come up. We’re going to attempt to implement the policy as written, which means if your customer’s in London and you say he’s in London, we’re going to tell you he’s not going to count favorably for measuring the plurality.

Paul Andersen: London, England, I assume, since London, Ontario, is in the region.

John Curran: It’s wonderful. If you tell us he’s out of region, he’s going to be considered out of region.

Jason Schiller: Thank you.

Paul Andersen: With that we’ll give R.S. one last check if there was any late breaking remote comments. None. I’d like to go to small public service announcement. I know you’re all busy emailing and Web surfacing, but for the cost of raising your hands for a few seconds, you too can give valuable feedback to an AC member. I’d ask you all now to consider the question of should the AC continue to work on the Policy 2013‑6. Obviously they’ll have to continue on the text because I think there’s been some consensus on feedback, but the policy itself, should the AC continue to work on that? I think our counters are ready. So I’d ask all those in favor of that raise their hand high. For just a few moments. Nice and high.

You can lower your hands those who do not believe the AC should not continue work on this policy. Please raise your hands nice and high. Thank you very much. You can lower your hands.

Just give us a moment for the tabulation. Thank you, Richard.

The matter of 2013‑6, should the AC continue working on this policy: In favor, 12; against, 16. 84 people in the room, remotely. This advice is being provided to the AC.

Thank you very much for your participation on this proposal. Thank you very much.

John Curran: Thank you, Paul.

(Applause.)

John Curran: Okay. We are now at the next point of our meeting where we have a break. We’re going to have a break. Outside refreshment break. It is 30 minutes in length and we’re going to come back in promptly at 11:30 and we’re going to pick up our last policy proposal at that point. So half‑hour break, everyone. Thank You.

Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements

John Curran: Okay, people, come in and get seated. We’ll get started. Everyone come in and please be seated. Okay.
Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements

This is a continuation of the ARIN at NANOG Public Policy Consultation. I’m John Curran, President and CEO, ARIN. We’ve gone through two policies so far. And we’re on the third policy for the day.

So we’re going to consider Draft Policy 2013‑7: Merge IPv4 ISP and end‑user requirements.

So it originated in July of this year as ARIN Policy Proposal 190. The shepherds are Scott Leibrand and Bill Sandiford. Accepted as a Draft Policy in August and it’s contained in your proposal and Discussion Guide.

Staff summary. Proposal attempts to reconcile differences in requirements for obtaining PA and PI IPv4 resources, provider‑assigned and provider‑independent IPv4 address resources.

One similar proposal under discussion in the RIPE region, the PA/PI unification IPv6 address space, similar, but IPv6.

This proposal removes the difference between PI and PA sub-allocation and assignment. Draft Policy 2013‑7 is still a work in progress. This is Draft Policy, not a recommended draft. It’s been posted to the PPML and presented for community discussion. It will be worked towards the criteria of fair and impartial Number Resource administration. Technically-sound and supported by the community.

The staff legal assessment will be performed upon request when the draft is fully developed.

Recent discussion. A unified set of requirements is a big step in the right direction and should simplify things.

That actually concludes the staff introduction for 2013‑7, and I will now have the AC come up and present it, Scott Leibrand.

Scott Leibrand: If I start speaking too quickly, please raise your hand and I’ll slow down.

So the ‑‑ thanks, Kevin. The rationale and the reason for doing this policy proposal is there’s been some recent discussion around the differences between ISP and end‑user requirements in the policy manual and the implications that those have had. In some cases that has resulted in organizations pushing to have themselves classified as an end‑user network rather than an LIR or vice versa.

The document seems to be fairly complex. There are a lot of detailed requirements in both cases and in many cases they overlap and many cases they don’t. And the reasons for the differences are not always entirely clear.

There’s also the possibility that given the requirements in the policy manual and the realities of IPv4 exhaustion that some small networks may not be able to get addresses from their ISPs because the ISPs simply don’t have any more and yet they don’t qualify for addresses from ARIN because of the minimum allocation sizes and such, unless they re-qualify as an LIR or some such.

So the attempt here is to simplify a portion of the policy manual, make the requirements the same in as many cases as is feasible. There’s still many details around reassignment tracking, SWIP and Whois that are going to be different between what ISPs have to do and what end-users have to do. But in the cases where we’re talking about how much space do you qualify for a network of characteristic X, the idea is that you could do that without having to decide whether network X is an ISP or an end‑user network that happens to have customers.

So the attempt here is to keep it small enough that we’re not going to be changing the entire NRPM at once, but there’s still quite a bit to be changed in order to make this happen.

As we’ve discussed with previous proposals, this is a Draft Policy, not a recommended draft. We’re not trying to send this to last call after the meeting. We’re trying to get feedback from the community as to how this should be developed and get the text ready for possibly recommending it in the future, but first that means getting feedback from all of you guys on what we want to do in a conceptual manner as well.

This slide we may come back to, has a summary of what is currently in existing end‑user policy and existing ISP policy and what this proposal suggests we do to make them compatible. So in the first example, whereas the minimum allocation would be a /20 for single‑homed or /24 for multi‑homed, the proposed policy would be /22 single‑homed or /24 multi‑homed for both ISP and end-users.

In that particular case there’s a change for other reasons from both the ISP and end‑user policy, but in the case of the multi‑homed, we took the one that we felt was more appropriate for everyone based on the realities going forward. So there are a number of things in the policy manual that we have to choose between if you’re going to attempt to consolidate ISP and end‑user policy and make allocations and assignments have the same types of requirements.

We’ll probably get back to these details in a minute. The AC needs feedback from the community. I’m sure you’ll answer a few questions not on this list.

From a high level, do you like the idea of consolidating the policy between ISPs and end-users, allocations and assignments? Which of these requirements do you think we should keep? Are there any other distinctions besides the ones remaining with regard to reassignments, et cetera, that need to be maintained, keeping ISPs and end-users distinct? If so, what and why?

So with that I’d like to open it up for discussion. There’s a number of supporting materials here that I can reference or that Paul can reference if we get to that point in the discussion. But I think at this point it’s good to have a fairly open‑ended discussion about whether this is a good idea and what direction we should be moving.

John Curran: Microphones are open for discussion. Vice chair Paul Andersen will moderate the discussion. I ask ‑‑ even though I don’t myself do this, I ask everyone speak slowly because we are ‑‑ we are having this transcribed and that’s happening on the other end of the remote link. So to be nice to people, it would be nice to speak slowly and clearly. Thank you.

Paul Andersen: Sorry. Some quick caffeine there. Center mic.

Owen DeLong: Owen DeLong, Hurricane Electric. I do not support this policy in concept or in its current text.

Paul Andersen: Could be you be a little clearer?

Owen DeLong: This is a really bad idea. We’ve spent a lot of time and effort developing policies that serve end-users reasonably well. We’ve spent a lot of time tweaking those policies, and this would essentially undo almost all of that in favor of subjecting end-users to criteria that really don’t apply to, for the most part, in favor of simplifying the policy text to make everybody look like an ISP.

And realizing we’re having trouble dealing with the line between true end-users and ISPs are getting blurry with different kind of hybrid organizations.

The bottom line is doing this to the average end‑user that is truly an end‑user and only an end‑user would be very detrimental to the community.

Paul Andersen: Thank you for your feedback. Far microphone.

Louie Lee: Thank you, Paul. Louie Lee, chair of the ASO Address Council. Would you mind flipping back to the slide listing the different ‑‑ there we go, summary of changes. Perfect.

Paul Andersen: I aim to please.

Louie Lee: And my initial gut reaction is I do not support the policy for at least the reason that Owen mentioned. And I do not see enough reason to make this drastic change.

Another item that we need to be considered is membership status for end-users, you’re not automatically a member. If you get an allocation, then you are a member. So that’s also going to need to be considered if we make a change like this.

Paul Andersen: I appreciate that that would be the current state, but I would assume if there was a change like this then the Board would have to probably reevaluate ‑‑ anytime a policy change is made like this, you have to assume fee schedules and membership schedules could be visited by the Board to accommodate.

So always good to keep in mind, don’t pass a policy thinking that specific outcome will come into those specific items. Thank you, Louie. Back to center mic.

Dan Alexander: Dan Alexander, Comcast, ARIN AC, and the author of this policy. And some of the comments that have already been made. If you read the policy, it doesn’t attempt to eliminate the distinction between end-users and LIRs. All it’s actually talking about is eliminating the different requirements around network operators obtaining resources. Once they have them, the Whois requirements, the reporting requirements, how utilization is evaluated all remains in place.

All we’re talking about here is the requirements for network operators to obtain resources either via the free pool or from transfers. So I’m actually curious, some of the earlier comments about how this would be detrimental or undo the work for end-users, if you look at that comparison chart right there, it doesn’t actually take anything away from anybody. It actually makes it a lot easier. So I’d be really interested in some feedback on how this is specifically detrimental.

Paul Andersen: Scott, did you have any feedback on that? Or those that want to give examples of detrimental feedback can approach a microphone. I’ll go over there and come back to you, sir.

Majdi Abbas: Majdi Abbas, Brightroll but speaking for myself here. Deck chairs. This is not a simplification. You’re actually making things more complex by creating a two‑tiered system where the v4 policies are merged and v6 is untouched. And I can’t support any policy that contains v4 only anywhere.

Paul Andersen: You’re not supportive. Thank you. Back to the center microphone.

Drake Pallister: Hello. Drake Pallister, Duraserver Technologies, New Jersey. I’m with ARIN. I’m an ARIN resource holder, vis‑a‑vis, an ARIN member. I just want to express concern. I don’t want to criticize or critique any comments or works that have been presented, but I don’t want to lose the distinction between ‑‑ I would be concerned, I don’t want to see us losing the distinction between an end‑user and ISP. The ISP is in business and traditionally has been to provide Internet service, which includes connectivity, routing, transport, and, of course, IP numbers.

Now, we don’t want ‑‑ I don’t want to see any end-user be their own ISP. There also may be challenges whereas if the ISP that an end‑user is using can’t supply v6, how is that end‑user going to make use of that v6 allocation or assignment, if they’re an end‑user, if the ISP that they’re using can’t transport it to them unless via tunneling?

Perhaps look towards a different ISP who could provide the transport of that v6 mechanism to their business establishment and they will find a different ISP who could or would provide that v6 capacity to them and, hence, in changing or finding the ISP who will provide it, already have the provisions to supply the end‑user a reassignment of their own inventory. Thank you very much.

Paul Andersen: Thank you for your feedback. It will be very valuable to the AC. Far microphone.

David Huberman: David Huberman from Microsoft Corporation. A couple of things. I’d like to reiterate a point that was made earlier by Owen. ISPs and end-users is a very difficult terminology. It’s very difficult vocabulary in 2013 and beyond. So this is the first attempt we’ve seen to try and bring some sort of sense to NRPM about what it means to operate a network versus a 1995 definition of ISP. So I think it’s very important we continue having these discussions.

This policy proposal, which I strongly support, does not make anything more difficult for anyone. It does not take away anything that the policy community has worked on for the last 15 years, 16 years. It actually makes things easier from a mechanics standpoint of how do I request space.

And what prompted me to walk up to the microphone was my friend Majdi’s comment about this is a v4 only, which is a very good observation. What you need to think about, what you really need to consider is this sets up the transfer process up for better success.

One of the key roles ARIN will take over the next one, two, and five years is as a clearinghouse of transfers. And transfer policies, the way it’s written today, relies on Section 4 in the NRPM in order to transfer IPv4 addresses, which is a huge part of what ARIN uses today and over the next five years.

So it’s really important that we get business rational policy that people can understand and work within, because today I would stipulate that NRPM is too complex. It’s too granular. It needs to be made simpler. The guidelines need to be streamlined. Some of the barriers of the actual math of /20s, those need to be lowered, which this policy does.

And I would urge you to consider when you’re thinking about supporting this kind of policy or not is how does this affect the transfer market. That’s all.

Paul Andersen: Far microphone.

Barry Dykes: Barry Dykes with ViaWest. Looking at the 80 percent rule in three months, you have 12 months before you can go for additional space. So let’s say that as an ISP you ‑‑ at three months you’re only 60 percent utilized at that new block and does that mean you take it back? What does it mean? And then after that, does that mean there’s still additional 12 months before you can ask for additional space? There’s a lot of ambiguity here.

Paul Andersen: One of you pick. Scott.

Scott Leibrand: Scott Leibrand, AC shepherd. The way generally this has worked, and John can clarify, is that the requests are evaluated based on both projections and more importantly on previous run rates. So if you are on track to use this much in a certain amount of time, then you would be allocated the addresses based on that run rate or if run rate is not available on good projections.

If your run rate changes and you end up not needing the addresses in the timeframe that you estimated, then that will not result in revocation, necessarily but it will result in the new run rate being evaluated for the next subsequent request after that.

Barry Dykes: Is this also to be applied to the open resell market now that’s going on for IPv4?

Scott Leibrand: So the way the policy is currently written, in order to get a transfer on the transfer market, you must qualify for the addresses from ARIN. So with one exception. And if you bring up the little chart again, the three‑month thing at the bottom center for ISPs is for addresses directly from ARIN. That is 24 months for addresses on the transfer market. So that is the only distinction at the moment that I can recall between addresses that you get via from ARIN versus addresses you get via transfer. Otherwise you must meet all the same requirements.

Barry Dykes: So I’ll tell you what the results of this will be to a business, which you should care about because in the end that’s who pays you is businesses.

Basically the business who runs out of IPv4 space first is no longer marketable to all of these companies out there that cannot afford to retool to get to v6. I hope I said v4. Did I say it backwards? Whoever runs out of v4 first is the first one whose business slows down to a crawl based on the way this thing is written.

Scott Leibrand: I’m not understanding how you think this makes things worse for acquiring space on the transfer market.

Barry Dykes: Let’s put these two together. I choose not to use the transfer market. You go out to try to get space and what I’m finding is that, here, go ahead and take, I don’t know, a /24, which could last you how long with customers? Not very long at all. You ask the customers to come directly to you. If you’re asking for a /22, you’re not lasting very long at all as a service provider.

Scott Leibrand: So if you qualify for space from ARIN and you need a /18 to meet your six‑month requirement, then they will approve you for a /18. If the /18 is available in the free pool, you’ll get that. This doesn’t change that portion of how things work. I don’t understand ‑‑

Barry Dykes: That clarity helps.

Paul Andersen: The policy is only affecting since transfers or free pool require the justification, this is just talking about the justification.

Scott Leibrand: I think maybe the misunderstanding there is the first row is the minimum. There’s no maximum defined in this policy or in current policy for the general free pool.

Barry Dykes: Thank you, that clarity helped.

Paul Andersen: Sir, are you in favor or opposed to this policy or would you like to noodle on it a little bit?

Barry Dykes: I’m noodling.

Paul Andersen: Thank you. Remote if there’s any by chance. Center mic, please.

Mike Joseph: Mike Joseph, Google. I strongly oppose this policy. First off, as a matter of good policy making, this falls far short. It’s a complex omnibus proposal that purports to harmonize the LIR and end‑user policy but in doing so introduces a number of changes to both. It chooses the worst of each policy. And we end up with something that is so incredibly hard for any of us to parse, we need a chart to explain what it does. And it ends up changing so many areas of the policy beyond simply merging those two. If we’re contemplating this level of change, it needs to be much clearer and it needs to be spread out amongst a number of policies in draft proposals, because we shouldn’t ‑‑ this is a wholesale rewrite of both LIR and end‑user policy that dramatically changes both.

Also, as a matter of good policy making, I oppose policies that would tweak only the v4 and not the v6 policy. And I know that was already articulated.

Paul Andersen: Good to stress again.

Mike Joseph: Secondly, this policy has the interesting side effect of eviscerating the needs basis for initial allocation because it uses forward‑looking criteria only. It’s not captured well here on this chart, but if you read the policy language, you’ll find that that holds true.

And finally I think more fundamentally this policy strives to solve a problem that’s much more easily tackled in other ways. Seems to be solving the problem of having difficulty identifying whether an organization should be an LIR or an end site, and historically ARIN has mostly deferred to the organization to self‑identify when there was a gray area. In fact, R.S. has been quite helpful in providing guidance when appropriate in that respect.

And I don’t actually see that as a big problem. I don’t think we have that many organizations out there that easily qualify for both and are just making the wrong choice. I’m not even sure what the wrong choice is.

So I think to try to introduce this level of dramatic change simply to ‑‑ merely simplify how an organization chooses to classify and receive resources is far too much and it changes things too much. I strongly oppose this policy.

Paul Andersen: Thank you for your comment. We’ll close the mics shortly. If you’re going to make a comment, either remotely start typing as soon as you can or approach a microphone.
Sir, are you just lurking or are you ‑‑

Louie Lee: No, I’m making sure I defer to the center mic since Kevin was up before I was.

Paul Andersen: I like to encourage the other mics. So the chair recognizes the stylish hat. I think I’m friends on Facebook with that hat or something. That’s excellent. Who are you and what’s your affiliation and what’s your comment, sir?

Louie Lee: I will defer to Kevin since he did step up. He’s letting me. I’m Louie Lee, and I’m with Equinix and chair of the ASO Address Council. Thank you to the author for clarifying this attempts to only synchronize the criteria and not make any other changes such that membership doesn’t actually have to be considered.

I could be in favor of this policy proposal, but I’m afraid it looks like it’s like eight policy proposals in one and if you add v6, that’s two more. So for a lot of people I think it’s already too much to do in one and others want two more.

Paul Andersen: So opposed at this point?

Louie Lee: Remote participation.

Robert Seastrom: We have a remote comment from Kevin Otte: I concur with the assertion that v4‑only policies are a bad idea. Furthermore, any policies should strongly encourage the option of IPv6 rather than keeping IPv4 on life support.

Paul Andersen: Center mic.

Kevin Blumberg: Kevin Blumberg, The Wire, AC. I believe that the policy ‑‑ I’ll be a little ambivalent, not pro or against at this time because I believe this policy needs a lot of work before I could support it, but I believe this is missing the evil that lurks below. We do have one key differentiator between IPv4 and v6, which is we’re not out of IPv6. We’re at end of days with v4. And there are aspects of the current NRPM that fundamentally don’t work in runout and especially don’t work for end-users in runout.

The slow‑start mechanism is a critical issue because it doesn’t work in the transfer market when you’re looking for a /24 or /22.

So I believe that, yes, we do actually need to do work on v4 that is separate from v6. But what we’re looking for is this is not 2013 issues, this is 2014 and 2015 issues and we need to clear out the aspects of the NRPM that conflict with reality which is a transfer market versus a free pool.

Paul Andersen: You’re opposed?

Kevin Blumberg: I believe this policy, if it dealt with cleaning out the non‑free pool issues, I would support. I don’t believe tweaking some numbers to synchronize is beneficial.

Paul Andersen: Last call to approach a microphone. Going once, twice, third time. Center mic. Microphones are closed as well.

Jason Schiller: Jason Schiller, Google. I applaud the effort to try to simplify the NRPM and to streamline things where things are happening. I feel a lot of work ‑‑

Paul Andersen: I feel a “but” coming up.

Jason Schiller: I oppose this policy. I oppose this policy because I think it’s doing a lot more than what the chart on the screen addresses.

I’ll address other things, but there’s more than just these three. The first I want to talk about is a removal of slow start. Yikes. Slow start is very important. I don’t think we should be removing it. In fact, I think we should be figuring out how to make it work in a transfer market. I think that’s a movement in the wrong direction.

Second thing I want to dwell on is moving to a 12‑month supply as opposed to a quarter. A long time back we had 12 months. There was a discussion to move it to a quarter. I opposed that. I felt you shouldn’t change the rules of the game so close to the finish line and we should just do business as usual and run until we’re out. But, nevertheless, we changed it. Now we’re talking about changing it back.

I oppose changing it back because you shouldn’t change the rules of the game so close to the finish line.

Paul Andersen: Even though it’s what you originally wanted.

Jason Schiller: The principle is we shouldn’t be changing it.

Paul Andersen: The principle is it shouldn’t be changed, I understand that.

Jason Schiller: I think that’s a bad change. And the third thing I wanted to dwell on is right now all justification is based on your current utilization. What did you use in the last quarter, what did you use in the last year and projecting what next year’s need is based on what you need last year. And if you need more than that then you come back again. And that is completely gone. It seems to me a lot of justification for address that we currently use would be eliminated with this proposal.

And the way I read it is if you could base a request strictly on a future projection of need, as in I’m thinking about starting an ISP at my house and I’d like a /8 please.

I don’t think this is a move in the right direction. It also completely removes the section about how to judge utilization for Web hosting, which I admit is kind of vague, but now it would be non‑existent. So I think it takes away a lot of the good advice to ARIN staff on how to judge need and utilization.

So these are things that I think really need to stay in the policy as we run out of the approach runout and even in the transfer market, because I think the needs bases that we’ve been using until now is fair and should be continued.

There’s a bunch of other things. Removes the non‑guaranteeability of routability, removes reference to 2050, there’s a big long list, but I hit the major ones.

Paul Andersen: Thank you very much, Jason. The last comment, sir.

Dan Alexander: Dan Alexander, ARIN AC. There are two problems that were both in staff comments, the feedback presentations at prior meetings and just conversations coming up in the Mailing List and so forth. As we go into depletion, we’re already seeing cases where people are gaming the definition saying I’m not an end‑user, I’m an ISP or I’m not an ISP, I’m an end‑user, in order to either save money on fees or to meet certain requirements to obtain resources via transfer from the free pool. So these, the split requirements is already showing signs of issues, which is one of the reasons why this attempted to do away with some of those to prevent all the confusion that staff has to deal with, with a potential to move to a cleaner model.

There’s also real‑world cases where network operators, when ARIN’s free pool runs out, are not going to be able to get addresses from ARIN. They’re not going to be able to get addresses from their upstream ISP, and they’re not going to meet the requirements for a transfer.

So there’s a large policy hole that currently exists as the policy manual’s currently written that’s going to potentially leave a lot of people with no options. Which is something that this also attempted to address.

The comments about that this ‑‑ and I was kind of struck because it’s hard to thread the needle where you both get the comments this is an omnibus proposal and there’s too many changes, but at the same time it doesn’t address v6, so it’s incomplete. I don’t know how you can satisfy both of those criticisms.

This was trying to deal with a certain set of criteria without making it overly complex, including v6. So we’ll have to keep working on the language.

Mike Joseph: I resemble those comments, could I respond to that? I think the way you deal with that is you implement, as Louie pointed out, a policy or three policies or four policies or however many policies that deal with v4 and v6 on a particular topic. So you tackle the minimum initial allocation and assignment size for v4 and v6. There’s ways to do this in the standard incremental model that we typically use to make policy changes that don’t involve a wholesale rewrite of the entire v4 and v6 sections of the NRPM.

Paul Andersen: Does the AC chair have any thoughts on exploding into about 12 different policies at one time?

John Sweeting: We welcome the work ‑‑ I said we welcome the work that will keep us employed at our current wage.

(Laughter.)

Paul Andersen: Zero. Last comment, Dan.

Dan Alexander: Just to respond to that, having done this for a little while, it’s six and one‑half dozen of the other because in doing so we quickly go down to the argument of, well, I hesitate on accepting or passing this one without the other one, or we need three of the 12 approved in order for me to really feel good. So it’s a difficult road no matter which direction we head.

Paul Andersen: Thank you, Dan. That brings us to the end of the discussion on this and all our policy proposals. I’d like to thank everyone. Been some great, vibrant discussion.

One last matter of business, but first I’d ask if everyone in the room could just raise one hand. Everybody. I’m going to wait until everybody ‑‑ I can see you. I’ve got all day. I see a bunch of you reading your email. Come on, even the workers, just raise your hand for a second, come on, just for one second.

CEO, too, you’ll hold out on me. I’d ask those who have their hands up to keep them up if they feel should the AC continue work on ARIN 2013‑7. Keep it up. Try new things. Up high. Sir, there, you need to ‑‑ no hanging chads, please. Didn’t work for Florida; it’s not going to work for us, unfortunately. Please keep them up I ask you until they’re counted. Counters, are we good? That was good. You can put them down. Thank you. Gentleman in the back, you can put ‑‑ thank you. We’re in the middle of a vote.

Drake Pallister: Will you give the option to abstain?

Paul Andersen: I can give an option ‑‑ we’re not done voting yet. All those opposed to the AC continuing work on 2013‑7, please raise your hand nice and high. You can put your hand down. We have a parliamentary enquiry here so I will refer to our resident parliamentariran

John Curran: It’s not a vote. It is literally a show of support supplied to the AC. As such, there’s no abstentions. Parties show support and that’s recorded. It goes to the AC as a non‑binding matter. If you don’t wish to raise your hand for yea or nay, then effectively you have abstained so we don’t call it separately.

Paul Andersen: Would you like your vote to be counted yea or nay, because it was half?

Drake Pallister: (Off microphone.)

Paul Andersen: Okay. That will be so noted. All right. Then with that resolved ‑‑ thank you, sir.

On our final one, on the Item 2013‑7: Merge IPv4 ISP and end‑user requirements, to continue work, those in favor, five; against, 11. In the room and on remote, 76. This feedback is being provided to the AC for their consideration.

And before I get the hook, I want to echo what I believe Mr. Sweeting said earlier, there are three elections going on now. I would ask you to please go to the website, read the statements. I believe there’s speeches later this week, and please vote.

With that, thank you very much for your participation today and I’ll turn it over to John for I guess final remarks. Thank you, John.

Closing Announcements and Adjournment

John Curran: Okay, that concludes our policy discussion. We’re actually done. I want to point out two things. One is later on this week it’s ARIN 32, taking place in Phoenix. For those of you who get done with NANOG and don’t fly out, I hope to see you here Thursday and Friday. We actually are going to go through these discussions again, along with all the typical reports that we do. And all of this will go to the AC for their consideration.

If I don’t have a chance to see you at the end of the week, please remember that we’re going to have ARIN 33. It’s in Chicago, Illinois, in April 2014. So keep that in mind. That’s it. Thank you, everyone. Have a good day.

(Meeting adjourned 12:10 p.m.)